AGENTIC QA · WORKFLOW SKILL
Exploración sin ticket de un flujo, un módulo o la app entera: Charter → Recon → Refute → Tie-break → Handoff.
El mapa completo · índice del deck
Planificar y desempatar nunca se delega. Lo paralelo es lo que no comparte estado: cada superficie en Recon y cada hallazgo en Refute.
Antes de empezar · el modo se pregunta
| Modo | Entra | Agentes |
|---|---|---|
| Critical-Flow-Targeted · flow | un journey de business-e2e-context o un flujo del Master Test Plan | uno por módulo que toca el flujo |
| Module-Targeted · module | un módulo: su Epic, su componente, sus secciones en los mapas | 1 a 3: DB + API, más UI si tiene pantalla |
| Whole-App Sweep · sweep | nada: una ronda periódica sobre todo el producto | uno por módulo, con tope en orchestration.max_workers |
Lo que dijiste es la respuesta
/exploratory-testing module orders ya trae el modo, y «explora el módulo de pedidos» también. Si el pedido no nombra un flujo, un módulo o un barrido, o puede leerse de dos formas, la skill pregunta.
Con clave de ticket, otra skill
Si nombras PROJ-7123, el trabajo es probar ese ticket contra sus ACs: eso es /sprint-testing. Esta skill existe para lo que ningún ticket describe.
Charter · una página, antes de despachar a nadie
Se presenta y se espera
Un barrido puede lanzar muchos agentes y tocar muchas tablas. Confirmar el charter cuesta segundos; descubrir a mitad de camino que el alcance estaba mal cuesta la ronda. Si tu pedido ya nombró el alcance y dijo «dale», esa es la confirmación.
El preflight se reusa
Entorno, roles con el login real de la app y la sonda de herramientas salen de preflight-gate.md. La sonda no se saltea: una capability faltante achica a todos los agentes a la vez.
Charter · lo que ya existe, antes de explorar
| Marca | Cuándo | Va a documentación |
|---|---|---|
| NEW | ningún test cuenta como cobertura de ese comportamiento | sí |
| WEAK | un test pasa por ahí, pero nada de lo que verifica fallaría si se rompe | sí, nombrando el test débil para decidir si se refuerza o se suma uno nuevo |
| COVERED | un test cuya aserción falla si el comportamiento se rompe | no: queda en el registro con la clave que lo cubre |
Con gap list
La de project-context coverage: su orden por riesgo es la cola, y tests[].covers es el dedupe. Una fila stale o sin verificar no cuenta.
Sin gap list
La skill arma coverage-view.json con kata-manifest.json y los Tests del módulo en el TMS, con la misma escala: exercises o weak, una línea de evidencia cada uno.
Recon · paralelo, un agente por superficie
El schema de cada agente
surface · deployed · checks_run · anomalies[] con su hipótesis de severidad y la consulta textual · observed[] con covered_by · fixtures_used · created_rows, aunque esté vacío.
La técnica ya existe
Cada agente explora con la trifuerza de sprint-testing: UI con playwright-cli, API con el schema del OpenAPI MCP más curl autenticado, DB leyendo el schema vivo antes de cualquier consulta.
Dos o tres filas, y un grupo de control
Una fila rara o un GROUP BY flojo es una pista. Antes de llamarlo anomalía, el agente busca más filas con la misma forma y mira si la "anomalía" también aparece donde todo debería estar bien.
deployed: false
Si la superficie no existe en ese entorno, es un bloqueo de entorno. Nunca se reporta como "probado, sin anomalías".
Refute · el verificador intenta tumbar el hallazgo
El propio invariante de la fila
Que dos filas difieran no prueba nada. La pregunta es si la fila cumple su propia fórmula, probada antes en una fila sin disputa, y si además coincide con algo con lo que no tendría por qué coincidir. Rompe su fórmula y copia otro valor: eso es un bug.
Ejecutar, no inferir
Cada hipótesis en competencia se corre y se pega con su salida, lado a lado. Un mecanismo inferido de la forma de una respuesta termina en un fix equivocado.
Tie-break · en el hilo principal
Consulta decisiva
Una consulta o llamada que separa las dos hipótesis. No se repite la de ningún verificador.
Código vivo
Lectura directa del camino que de verdad alcanza un usuario: ruta, handler, quién lo llama, entrada de navegación.
Sin tercer voto
Un tercer verificador suma ruido a dos opiniones inconclusas. Promediar tampoco vale.
Dos verificadores no coincidían sobre si un módulo con aritmética visiblemente mal estaba vivo. El desempate leyó el router y el menú: el módulo solo servía una ruta legacy sin enlace. El defecto era real y su severidad bajó a lo que de verdad alcanza un usuario. En integridad de datos, dinero o seguridad, el veredicto de un solo agente nunca queda en pie.
Handoff · lo observado no es lo esperado
La pregunta va a una persona
"Este comportamiento es el esperado?" es comportamiento de producto. Docs y código se muestran como evidencia junto a la pregunta, y la respuesta la da alguien: confirmed con quién, dónde y cuándo, o not intended, que lo convierte en un defecto propuesto.
PASSED solo si se observó
Un candidato es PASSED o FAILED solo cuando se vio en el entorno que nombra su precondición. Una lectura de código, un test unitario, un CI verde u otro entorno lo dejan en NOT RUN, con BLOCKED o DEFERRED (execution) y la escalera de desbloqueo.
| Estado del candidato | Qué sigue |
|---|---|
| observado en vivo, sin respuesta | va a documentación sin puntaje: no hay ROI sobre un oráculo sin confirmar |
| confirmado | PASSED contra el resultado confirmado; documentación lo puntúa |
| no previsto | FAILED y propuesta de bug, que firma una persona |
Handoff · un solo deck de decisiones
Un archivo por hallazgo
findings/FNN-*.md para los confirmados y también para los refutados: un falso positivo documentado le ahorra a la próxima ronda el mismo callejón.
candidate-scenarios.md
Cada candidato con su comportamiento, marca de cobertura, precondición, acción, lo observado, entorno, resultado, estado del oráculo, señal de riesgo y evidencia.
El deck de la ronda
Las respuestas del oráculo, qué hallazgo se reporta o se descarta, qué Tech Story se crea y con qué grano, y el harvest del module context van juntos en un deck de mkd. Una sola pregunta chica va por la herramienta de preguntas.
El ancla de cada Test
Un coverable que ya describe el comportamiento, la Tech Story de cobertura de un gap de la lista, o una propuesta nueva con los campos de la doctrina. Esta skill no crea Tests ni puntúa ROI.
Recon · lo que nunca se hace
Never-call
Ningún endpoint, job o comando que mande un email o una notificación real, empuje datos a otro sistema o dispare una operación masiva. Leer y previsualizar está bien. Un proyecto escribe su propia lista en agent-project.md y viaja literal en cada briefing.
Presupuesto de mutaciones
Solo para montar una precondición, y solo lo que el charter permitió. Cada fila creada entra en created_rows en el momento en que existe.
Limpieza releída
Antes de cerrar se vuelve a leer cada fila. Un DELETE con timeout puede haber hecho commit y uno con 200 puede no haberlo hecho: solo cuenta la relectura.
quién decide qué · Execution sin ticket
| El agente hace | La persona firma | Autonomía | Verificador separado |
|---|---|---|---|
| escribe el charter, reparte el recon por UI / API / DB, refuta cada anomalía Medium+, desempata en el hilo principal, marca cada candidato contra la cobertura, redacta bugs y propuestas de Tech Story | el charter · cada respuesta del oráculo · el alta de cada bug · cada Tech Story · cada escritura en el module context | 3 | ninguno: el paso Refute es un chequeo adversarial interno |
Execution sigue siendo un solo stage. /sprint-testing entra por el ticket y esta skill entra por el alcance; los dos usan las mismas palabras para los resultados y la misma regla de observación. Su DoD está en stage-gates.md, en el bloque de Execution sin ticket.
Para llevarte · handoffs y artefactos
Documentation
/test-documentation lee candidate-scenarios.md: NEW y WEAK, puntuados solo con el oráculo confirmado.
Bugs
Reportados con tu OK, bajo QA Defect Management; /sprint-testing los re-testea cuando llega el fix.
Cobertura
La próxima corrida de project-context coverage compara contra la anterior y muestra qué huecos se cerraron.
Lo que deja una ronda
charter.md, recon/, findings/, candidate-scenarios.md, session.md y evidence/ en .session/exploratory-testing/<scope>/; en Jira, solo lo que aprobaste.
Tres reglas de oro
1 Un cover débil no es cobertura. 2 Lo observado no es lo esperado hasta que alguien lo confirma. 3 Un hallazgo vale cuando quien intentó tumbarlo no pudo.
Pruébalo: /exploratory-testing module orders · ← → navegar · S presentador · O overview