Agentic testing: el ciclo de QA visto desde el agente

El contrato de cada stage

Un tester humano cierra un ticket cuando siente que terminó. Un agente no tiene ese criterio, y si se lo dejas a él va a cerrar en cuanto su subagente devuelva algo. Por eso el repo define dos cosas para cada stage. La primera es el Definition of Done: una lista de condiciones observables (un archivo existe, un link resuelve, una línea tiene SÍ o un N/A con motivo). La segunda es el contrato agéntico, que responde cinco preguntas: qué hace el agente, qué firma la persona, qué evidencia debe sobrevivir, cuánta autonomía tiene el agente y si otro agente revisa al primero.

La lista de stages con nombre, su orden y el skill dueño de cada uno viven en .agents/skills/agentic-qa-core/references/stage-gates.md; la tabla de abajo recorre cada uno. Observation está declarado pero no tiene skill ni checklist, y así lo dice el propio archivo: una checklist vacía parecería un gate que alguien podría marcar. El cierre de sprint tampoco es un stage; es el límite del lote donde se cierran el STP y el STR.

Fíjate en que la persona casi nunca firma el trabajo operativo. Firma decisiones: qué entra, qué se registra como bug, qué merece automatizarse, cuándo se libera. El agente redacta, ejecuta y enlaza.

La columna "The person signs" decide además qué se pregunta y qué no. Una decisión técnica dentro de un plan ya aprobado la toma el agente y la deja en el reporte como decidida, con la opción que descartó. Solo se escala lo que pertenece a una persona: el comportamiento esperado del producto, una postura de seguridad nueva, una acción irreversible o que sale hacia afuera, y lo que esa columna reserva para el stage en curso. La regla completa está en .agents/skills/agentic-qa-core/references/decision-protocol.md.

Autonomía 0-5 y el techo en 3

La escala tiene seis niveles. En 0 la persona hace el trabajo; en 1 aprueba cada acción; en 2 aprueba un plan o un lote; en 3 el agente decide dentro de límites escritos y escala lo que queda fuera; en 4 la supervisión es por monitoreo; en 5 no hay intervención humana de rutina. El repo fija que ningún stage pasa de 3, y esa es la decisión detrás de que las skills no corran de punta a punta sin nadie mirando.

La excepción de Regression es deliberada y está documentada como tal en el contrato: ningún stage supera 3, salvo Regression, que llega a 4 solo con un GO limpio. Un GO sin fallos puede avanzar sin que nadie lo apruebe; CAUTION y NO-GO siempre los firma una persona.

Cada stage se gobierna por dos caminos. El feedforward condiciona el trabajo antes de que ocurra: la skill con sus referencias, las reglas compactas que viajan en el briefing y el plan aprobado primero (el ATP, spec.md, automation-plan.md). El feedback corrige después: las checklists, los gates ejecutables, la suite de regresión y el verificador separado. Automation es el único stage que llega a 3 y también el único con verificador obligatorio. Más margen al entrar se paga con un control más duro al salir.

El verificador light al cerrar cada stage

Un DoD puede quedar marcado mientras el artefacto sigue en el status donde Jira lo dejó al crearlo. El verificador light existe para atrapar lo que se saltó en silencio. Sus líneas son las de la sección "Light stage verifier" de .agents/skills/agentic-qa-core/references/artifact-lifecycle.md, y el agente las responde con lo que ya hizo en el stage, más una sola lectura extra (un Get Issue sobre la clave principal) para confirmar el status.

Light stage verifier: <Stage>
[ ] Artifacts exist: cada artefacto del stage, por KEY
[ ] Links present
[ ] Statuses: cada artefacto en su status esperado (transición disparada o motivo)
[ ] Assignee puesto en cada artefacto CREADO en el stage
[ ] Parent = el epic de proceso QA correcto; components puestos
[ ] Jira fields / comments escritos (el cuerpo llegó, no solo el item)
[ ] progress.md checkpoint agregado
[ ] Session footer impreso en el chat

Cada línea lleva SÍ o un N/A con su motivo. Una línea en blanco es un verificador fallido, y cualquier NO deja el stage en NEEDS REVISION. Esto se apoya en la regla 16 de AGENTS.md: un código de éxito describe la llamada y no el resultado. Un ok: true o un id devuelto prueban que la petición estaba bien formada. Para saber que la transición ocurrió, el agente vuelve a leer el status del issue.

Lifecycle de artefactos

Un artefacto creado y nunca movido no se distingue de uno que nadie trabajó. Sin un lifecycle declarado para cada tipo de trabajo, eso pasa: ATP congelados en Planning, Test Sets en Designing, Test Executions en ACTIVE. Cada fila dice dónde nace el artefacto, qué stage lo mueve y dónde termina; el canon es .agents/skills/agentic-qa-core/references/artifact-lifecycle.md.

Dos reglas acompañan la tabla. El assignee se pone al crear: Xray rechaza editar la membresía de un Test Plan que no es tuyo, y el bloqueo aparece mucho después. Y el parent es siempre un epic de proceso QA (por ejemplo, QA Defect Management para bugs), nunca un epic de producto. La historia de origen se enlaza con un issue link y el módulo afectado va en components.

Cuando el status no está mapeado

Cada proyecto nombra sus status a su manera. Si el slug de transición que el agente necesita no existe en el catálogo del proyecto, el protocolo es este:

1. Resolver el slug

   Si aparece en .agents/jira-workflows.json, el agente dispara la transición por id y sigue.

2. Listar las transiciones reales

   Si no aparece, pide a Jira las transiciones disponibles desde el status actual.

3. Hacer una sola pregunta

   Propone el candidato más parecido según una tabla de sinónimos (por ejemplo, "In QA" para in_test) y espera tu respuesta: sí, elegir otro o saltar.

4. Ejecutar con el id vivo y recomendar el resync

   Registra la transición en el checkpoint y te sugiere bun run jira:sync-workflows seguido de bun run jira:check, para que la próxima sesión la resuelva en el paso 1.

Un salto que tú elegiste queda como N/A con motivo en el verificador. Un salto que nadie vio es exactamente el defecto que este protocolo evita. Si la transición existe pero Jira la rechaza por un validador de campos, el agente reporta el error textual y no reintenta a ciegas.

Doctrina de diseño de tests

Un modelo de lenguaje tiende a generar un caso por criterio de aceptación y reportar "100% de ACs verificados". La doctrina del repo corrige ese sesgo con cinco principios. Los que más cambian el resultado son tres. Los ACs son el piso: la cobertura real es conformidad con los ACs más riesgo fuera de ellos (límites, errores, estados, anomalías). Un criterio describe una condición y un test case la explora con datos concretos. Y la relación es 1:N: por defecto el agente deriva varios casos por AC, y solo colapsa a uno cuando el AC es trivialmente atómico y lo justifica por escrito.

Cada técnica formal tiene su disparador:

Los stages de planificación cierran con la Test-Design Checklist, donde cada técnica recibe SÍ o un N/A declarado ("sin rangos en este AC, BVA N/A"). Lo mismo aplica a los defectos: el tipo se decide por la etapa de vida de la feature y no por el ambiente donde apareció. Un fallo en una feature que todavía no llegó a producción es un Defect aunque lo veas en qa; en una feature ya liberada es un Bug; si ningún AC se rompió y el hallazgo vino de un test más allá del AC, es una Improvement.

Así lo hace este repo

Todo lo anterior sale de archivos que el agente carga antes de actuar. Si quieres verificar una regla, léela en la fuente:

Los gates ejecutables del feedback son scripts reales de package.json: bun run test, bun run types:check y bun run lint:check, en ese orden. Para ver qué skill posee cada stage, qué artefactos deja y cómo se calcula el veredicto GO / CAUTION / NO-GO, consulta Metodología en este repo.

Para profundizar

• ISTQB Certified Tester Foundation Level v4.0: el syllabus define Equivalence Partitioning, BVA, Decision Tables y State-Transition, las mismas técnicas que usa la doctrina.
• Playwright Test Agents: los agentes planner, generator y healer de Playwright, con sus planes en Markdown versionados junto al código.
• Software Testing with Large Language Models: Survey, Landscape, and Vision (Wang et al., arXiv 2307.07221): revisión de cómo se usan los LLM en generación de tests, inputs y depuración.
• Humans and Agents in Software Engineering Loops (martinfowler.com): la diferencia entre revisar cada salida del agente y diseñar el harness que la controla.
• Flaky Tests at Google and How We Mitigate Them (Google Testing Blog): por qué clasificar un fallo como flaky exige historial y no una sola corrida.