Pruebas de software autónomas: cuatro niveles, descritos con honestidad

Los cuatro niveles de las pruebas de software autónomas

• 1. Escritura asistida. Tú dices qué probar y la herramienta escribe el código. Ahorra tiempo de verdad. Tú sigues decidiendo todo.

• 2. Cobertura generada. Propone qué probar a partir de una especificación o de la aplicación en ejecución. Tú revisas el plan. Es donde están realmente la mayoría de los productos.

• 3. Automantenimiento. La cobertura se adapta a medida que el producto cambia, sin que nadie tenga que repararla. Exige distinguir un cambio intencionado de una regresión.

El cuarto es el ciclo cerrado: detecta un fallo, entrega la evidencia a un agente de código y verifica la corrección. Hoy existe en una forma acotada, para defectos de comportamiento con una reproducción clara, y no llega a nada que requiera una decisión de producto.

Qué te exige cada nivel

• Nivel uno: saber qué probar. Todo el criterio sigue siendo tuyo.

• Nivel dos: revisar un plan. Es más rápido que escribirlo, pero no es gratis, y saltárselo es la forma de acabar con una cobertura que nadie entiende.

• Nivel tres: decidir qué cuenta como cambio intencionado. La herramienta no puede saber que un flujo se rediseñó a propósito.

• Nivel cuatro: definir qué es correcto con la precisión suficiente para que una corrección pueda verificarse sin ti.

Fíjate en que el trabajo humano no desaparece a medida que subes. Se desplaza hacia arriba, de teclear a decidir, que es a la vez más valioso y más difícil de delegar.

El techo que nadie promociona

Ningún nivel elimina la necesidad de decidir qué significa correcto. Una herramienta puede deducir que un endpoint existe y que un campo es una cadena. No puede deducir que dos descuentos no deberían acumularse, porque esa es una regla de negocio que vive en una decisión que tomó alguien.

Cualquier producto que insinúe lo contrario está describiendo el nivel dos y llamándolo nivel cuatro.

Preguntas que sitúan a un producto en la escalera

Los proveedores se describen en el peldaño más alto que puedan defender, así que conviene tener preguntas que los ubiquen con precisión.

Quién decide qué se prueba. Si la respuesta es que lo decides tú, es nivel uno, sin importar cómo se escriba la prueba.

Qué pasa cuando cambia la interfaz pero no el comportamiento. Si una persona repara la prueba, es nivel dos. Si la prueba sobrevive, tres. Si sobrevive y aun así falla cuando el comportamiento sí cambió, es nivel tres bien hecho, que es más raro.

Y qué pasa después de un fallo. Si el resultado va a un panel para que lo lea una persona, ahí se acaba. Nivel cuatro significa que ese resultado lo puede consumir aquello que arregla el problema, y que la corrección se verifica sin que nadie tenga que transmitir nada. Hacer estas tres preguntas en orden lleva cinco minutos y ubica al producto de forma mucho más honesta que cualquier lista de funciones.

Primeros pasos

Si prefieres no instalar nada, el panel hace lo mismo. Todo lo demás que puede hacer la línea de comandos está en el repositorio de la CLI.

Si el pipeline pertenece a otro equipo, la GitHub App es el camino de menor resistencia: es un webhook, no cambia nada en tu repositorio y se dispara cuando tu build avisa de que la nueva versión está publicada. Si prefieres que la comprobación se vea en el repositorio, un paso de GitHub Actions lo hace.

Dónde se sitúa TestSprite en la escalera

Nivel dos en todo, nivel tres para los cambios de comportamiento y nivel cuatro en su forma acotada: un fallo vuelve como algo sobre lo que un agente de código puede actuar, y la corrección se verifica con la misma comprobación y no con el razonamiento que la produjo.

En concreto: la cobertura se genera a partir de tu producto y se refina en lenguaje natural, los pasos son intenciones, así que un cambio cosmético no los rompe, y la skill de verificación se instala en el agente de código que ya usas, de modo que el ciclo ocurre donde está el trabajo.

Lo que sigue siendo tuyo es el techo descrito arriba: decidir qué significa correcto en una regla ambigua. Todo lo que hay por debajo se mueve, y la ventaja es que la cobertura deja de estar limitada por cuánto alcanza a escribir alguien.