Qué hace distinto un agente de testing con IA
Deriva la cobertura de tu producto. A partir de una especificación, de un documento de requisitos o explorando la aplicación en ejecución, en lugar de partir de lo que alguien se acordó de escribir.
Expresa los pasos como intenciones. “Abrir la página de configuración” en lugar de una ruta por el DOM, y por eso los rediseños cosméticos no suelen romperlo.
Devuelve un fallo utilizable por quien lo corrige. Qué se intentó, qué ocurrió y dónde divergieron, en un formato sobre el que otro agente puede actuar.
Modo de fallo uno: satisfacer la comprobación
Cuando le pides que una prueba pase, un agente puede tomar el camino más corto, y a veces ajustar la comprobación es más corto que arreglar el producto. No es mala intención: es un objetivo mal especificado.
Protegerse sale barato. Nombra un observable concreto en cada comprobación y rompe algo a propósito para confirmar que la comprobación puede ponerse en rojo. Una comprobación que no puede fallar no está protegiendo nada.
Modo de fallo dos: cobertura confiada que nadie leyó
Un agente producirá doscientos casos sin despeinarse. El volumen parece progreso, y una cobertura que nadie revisó es una cobertura en la que nadie puede confiar, porque no sabes qué afirma.
Lee el plan, no el código. Elimina las rutas administrativas, añade las reglas de producto que no están escritas en ningún sitio y trátalo como un pull request.
Lo que sigue sin poder hacer
Conocer tus reglas de negocio
Qué debe pasar cuando se aplican dos descuentos es una decisión, no una deducción.
Inventar el caso de abuso
Comprobará la autorización. No se le ocurrirá el flujo de trabajo que alguien podría manipular a su favor.
Arreglar un entorno roto
La inestabilidad que viene de la infraestructura sigue siendo inestabilidad.
Cómo revisar un plan de forma eficiente
El principal costo continuo de trabajar así es leer cobertura que no escribiste tú, y hacerlo mal es lo que produce los dos modos de fallo anteriores. Hay un método rápido.
Lee solo las aserciones. Sáltate los pasos por completo en la primera pasada, porque los pasos son mecánicos y el criterio vive en las aserciones. Cualquier aserción que también sería cierta en un producto roto es lo que hay que corregir, y son fáciles de detectar cuando solo miras eso.
Después repasa la lista buscando lo que falta, no lo que está. Los planes generados son sistemáticamente completos en los endpoints que existen y sistemáticamente mudos sobre las reglas que viven en la cabeza de alguien. Añadir tres de esas vale más que corregir treinta pasos.
Cómo empezar
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.
El disparador importa más que el mecanismo. Apuntarlo a tu evento de despliegue hace que cada cambio se compruebe sin que nadie tenga que decidirlo; la GitHub App hace eso desde el panel, y un paso de GitHub Actions lo hace desde dentro de tu flujo de trabajo.
Qué hace TestSprite como agente
Deriva la cobertura de tus fuentes y de la aplicación en ejecución, expresa los pasos como intenciones para que un cambio cosmético no los rompa, se ejecuta contra la app desplegada y devuelve un fallo en forma de qué se intentó, qué ocurrió y dónde divergieron esas dos cosas.
La instalación añade la skill de verificación al agente de código que ya usas, así que todo eso ocurre dentro del bucle en el que se escribe el código y no como un paso aparte que alguien tiene que recordar.
El valor está en que el bucle se cierra. Un cambio se comprueba contra el producto en ejecución, un fallo vuelve en un formato sobre el que el agente puede actuar y la corrección la confirma algo distinto del razonamiento que la produjo. Lo que sigue siendo tuyo es leer el plan y decidir qué significa correcto, que es una hora a la semana, no un puesto.
¿En qué se diferencia esto de un generador de pruebas?
Un generador produce código que luego ejecutas y mantienes. Un agente además lo ejecuta, lee el resultado y puede iterar, que es lo que cierra el bucle.
¿Puede funcionar sin una especificación?
Sí, explorando la aplicación en ejecución, aunque una especificación o un documento de requisitos produce un mejor primer plan.
¿Cuánta revisión necesita?
Lee el plan antes de la primera ejecución y después de cualquier regeneración grande. Entre medias, revisa los casos nuevos como revisarías código.
¿Qué evita que dispare los costos?
Las ejecuciones consumen créditos, así que fija expectativas antes de una sesión larga. Un agente con una herramienta de verificación la va a usar: de eso se trata, y conviene presupuestarlo.
¿Sustituye a un ingeniero de QA?
Sustituye la mitad repetitiva. Definir qué es correcto y pensar de forma adversaria siguen siendo trabajo humano, y son de todos modos la mitad más valiosa.
Decide qué comprobar. Comprueba lo que decidió.
Un agente de testing con IA deriva la cobertura, expresa los pasos como intenciones y devuelve fallos utilizables. Protégete de las comprobaciones que no pueden fallar y de la cobertura que nadie leyó, y mantén las reglas de negocio y los casos de abuso en manos humanas.