Qué dejar a cargo de un agente de pruebas automatizadas de software
Crear casos a partir de un cambio. Tiene el contexto en el momento en que se escribe el código, que es cuando los detalles están más frescos.
Ejecutar y volver a ejecutar. Mecánico, y una persona en este bucle solo añade latencia.
Clasificar los fallos evidentes. Entorno caído, dependencia ausente, destino inalcanzable. No requieren criterio.
Escribir la reproducción de un error que encontró. El caso se escribe mientras el error está a la vista, y no en un ticket tres días después.
Qué conservar
Qué significa correcto
Un requisito ambiguo es una decisión de producto. Un agente elegirá algo plausible y lo dejará fijado para siempre.
Qué bloquea un lanzamiento
Saber qué fallos importan hoy requiere un contexto que no está en ningún documento.
Si la comprobación es honesta
Lee el plan. Si a un agente le pides verde, puede darte verde por el camino más corto.
El límite en una frase
Deja que decida cómo comprobar y sigue decidiendo tú qué debe ser cierto. Esa división es limpia, se corresponde con aquello en lo que cada parte es realmente mejor y sobrevive al contacto con un equipo real.
La salvaguarda que vale la pena tener
Cada comprobación debería nombrar un observable concreto, y deberías haberla visto fallar al menos una vez. Una comprobación vaga es una invitación a que el agente la satisfaga en lugar de arreglar el producto, y ese modo de fallo es silencioso por naturaleza.
Qué sale mal en el segundo mes
Las primeras semanas trabajando así van bien, y después llega un bajón predecible que conviene anticipar.
El agente ha creado cien casos. La mayoría son razonables, nadie los ha leído todos y dos o tres afirman algo sutilmente incorrecto. Esos dos o tres ahora fallan cada vez que el producto cambia correctamente, así que la gente empieza a tratar el rojo como algo ambiguo. A partir de ahí viene la caída de siempre: volver a ejecutar, luego saltar, luego ignorar.
La intervención es barata si la haces de forma planificada y no como reacción a una crisis. Una vez al mes, lee las aserciones de cada caso añadido desde la revisión anterior. No los pasos, solo las aserciones. Con este volumen lleva menos de una hora y detecta justamente los casos que, de otro modo, erosionarían la confianza en toda la suite.
Cómo configurarlo
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
La misma configuración está disponible en el panel de TestSprite si prefieres no instalar nada en local. El resto de la superficie del CLI está en el repositorio del CLI.
Conecta el repositorio desde el panel y las ejecuciones partirán del despliegue que ya generas, o bien añade un paso a tu propio flujo de trabajo.
De qué se encarga TestSprite y qué sigue siendo tuyo
Se encarga del cómo: crear casos a partir de un cambio, ejecutarlos contra la aplicación desplegada, volver a ejecutarlos y clasificar los fallos mecánicos. La configuración instala la skill de verificación en tu agente de programación para que todo eso ocurra donde está el trabajo.
Tú te quedas con el qué. Leer el plan, corregir las aserciones que serían ciertas en un producto roto y decidir qué fallos bloquean un lanzamiento. Con un volumen normal es una hora a la semana, y es ahí donde tu conocimiento del producto entra en la suite.
La ventaja de esta división es que los casos de reproducción se escriben mientras el error está a la vista, y no tres días después en un ticket, y que la cobertura de regresión crece a partir de lo que realmente falló y no de un ejercicio de planificación.
¿Puede el agente funcionar sin supervisión?
Para ejecutar y para la clasificación mecánica de fallos, sí. Para decidir qué debe ser cierto y qué bloquea un lanzamiento, la supervisión no es una carga: es justamente el punto.
¿Cómo evitamos la proliferación de pruebas?
Revisa los casos creados como si fueran código y elimina los duplicados. El volumen sin criterio es el principal modo de fallo.
¿Y si escribe una comprobación que no puede fallar?
Es lo bastante habitual como para preverlo. Rompe a propósito aquello que se comprueba y confirma que la comprobación se pone en rojo antes de confiar en ella.
¿Necesita acceso al repositorio?
Verifica la aplicación desplegada a través de su interfaz. Tu agente de programación ya tiene el código.
¿Cómo medimos si esto funciona?
Los defectos que se escapan y el tiempo desde el fallo hasta la corrección. El número de pruebas sube de inmediato y significa muy poco.
Decide el cómo. Tú decides el qué.
Un agente de pruebas automatizadas de software debería encargarse de crear, ejecutar y clasificar fallos. Tú conserva qué significa correcto, qué bloquea un lanzamiento y si la comprobación es honesta. Nombra un observable concreto en cada comprobación y confirma que puede fallar.