Early-Game: prevención

La fase en una tabla

Los stages de esta fase

El stage es lo que se ejecuta y lo que se gatea. Tiene nombre y nunca número. Cada stage declara qué hace el agente, qué firma la persona, qué evidencia exige y con cuánta autonomía trabaja (escala 0-5). Los steps quedan dentro del stage como su desglose. Ninguno de los cuatro stages del Early-Game necesita un verificador separado, y en los cuatro el rol es QA Analyst como executor. Los niveles de autonomía y los nombres de transición de las tablas de abajo son una copia para enseñar. La fuente vigente es .agents/skills/agentic-qa-core/references/stage-gates.md para el contrato y la autonomía, y .agents/jira-workflows.json para las transiciones.

Shift-Left (antes del sprint)

La historia se analiza antes de que exista una línea de código, en lote y sin crear ninguna entidad en el TMS. De aquí salen el ATP, guardado en un campo de la historia, y las preguntas que el equipo todavía puede contestar barato.

Planning (dentro del sprint)

Con la historia ya en sprint, su plan se convierte en ítems: primero el ATS, después el ATP y el ATR. La cobertura se arma en dos ejes, y el ATR no existe sin un entorno declarado.

Execution (dentro del sprint)

Son dos movimientos y van en este orden: el smoke valida el entorno y la Trifuerza valida la feature. Lo que aparece fuera del plan vuelve al set en lugar de descartarse.

Reporting (dentro del sprint)

La corrida queda registrada: se llena el ATR, el comentario de QA cuenta lo que pasó y los enlaces se verifican en su dirección. Sin eso la historia no se firma.

Los 4 steps del Early-Game

Los steps del Early-Game recorren el TMLC (Test Manual Life Cycle), cuyas cuatro etapas son Análisis, Exploración, Priorización y Documentación. El step 2 es la excepción: es un evento del SDLC, no trabajo de QA.

Step 1: Análisis de Requerimientos

El análisis del Epic y el de cada Story ocurren antes del sprint. Pre-sprint, el ATP de la historia vive solo en el campo acceptance_test_plan, todavía sin ítem Test Plan. El ítem FTP tampoco nace aquí: se crea o se refina dentro de /sprint-testing, al cargar el contexto del Epic, ya en sprint. El FTP es un documento vivo que se escribe una vez por épica y se refina a lo largo de ella, porque el equipo aprende con cada historia que entrega.

La historia tampoco se analiza aislada. Se miran sus hermanas de la misma épica (las ya desarrolladas, las que están en desarrollo y las que solo están definidas), y esa vista completa de la feature es la que hace que los ATPs salgan mejores.

1. 1a. Análisis de Epic → FTP

   Contexto macro. Documento vivo que se refina durante toda la épica.

2. 1b. Análisis de las historias hermanas

   Entregadas, en desarrollo y solo definidas: la foto completa de la feature.

3. 1c. Análisis de Story → ATP

   Uno por Story, citando el FTP en vez de volver a derivarlo.

Step 2: Desarrollo e Implementación

Es el punto de sincronización con el SDLC: el período en que desarrollo construye mientras QA trabaja en paralelo. No es tarea directa de QA. Se cuenta entre los 15 steps para que el ciclo se lea completo, y el sitio oficial lo dibuja distinto. La herramienta es el repositorio del cliente (GitHub / GitLab), y el estándar exige una rama por historia y un PR revisado.

Step 3: Pruebas Exploratorias Tempranas

La US se valida en dos movimientos y en este orden. Primero el smoke test de Go/No-Go, que valida el entorno. Después la exploración por Trifuerza (UI · API · DB), que valida la feature ejecutando lo planificado en el ATP y en el FTP. Saltarse el smoke es el anti-patrón clásico.

Los hallazgos se reportan en el momento, porque el reporte de defectos vive dentro de la exploración y no es un step aparte. Antes de filear se clasifica cada hallazgo como Bug, Defect o Improvement, y la clasificación sigue la etapa de vida de la feature, no el entorno donde apareció. Cada uno se documenta con información clara y reproducible. La altitud Feature no tiene ejecución propia: el FTP se consume como contexto y no genera resultados.

Step 4: Priorización Risk-Based

Aquí se decide qué escenarios del ATP merecen un TC persistente en el TMS. La decisión corre después de ejecutar y reportar: el set de regresión se decide por ROI y nunca se asume al planificar. Los criterios son impacto potencial, probabilidad de defectos y valor-costo-riesgo. Cada escenario recibe uno de tres veredictos:

Candidate, MANUAL y Deferred también existen como estados de Jira (Candidate y MANUAL en el TC, Deferred en el Bug). El veredicto y el estado comparten nombre, pero son cosas distintas.

Herramientas por step

El sitio marca cada herramienta como adaptable (parte del estándar de implementación, se puede cambiar) o client-controlled (la trae el entorno del cliente).

Atributos de calidad por riesgo

El ATP de cada historia declara qué atributos aplican y por qué, a partir de su riesgo: impacto, probabilidad, datos que toca y superficie expuesta. Lo que no entra por riesgo no se prueba en esa historia. El FTP puede elevar un atributo a toda la feature, y funcionalidad aplica siempre.

El ATP antes del sprint vive en el campo de la historia

El Early-Game empieza antes que el sprint. En ese momento ya hay un plan por historia, pero todavía no hay ítem: el ATP está únicamente en el campo {{jira.acceptance_test_plan}} de la historia. La razón es práctica. Si el plan naciera como ítem durante el análisis, cada historia descartada en el backlog dejaría un Test Plan huérfano, sin nada que probar.

El ítem se crea en el primer stage del sprint (Planning), a partir de ese mismo campo. No existe un estado intermedio «ATP DRAFT». El paso previo se marca con etiquetas y una subtarea, visibles en el tablero:

Nombre completo

Acceptance Test Plan

Dónde vive

Antes del sprint, solo en el campo {{jira.acceptance_test_plan}} de la historia. Durante el sprint, en un ítem Test Plan.

Cuántos hay

Uno por historia

Título

ATP: {STORY-KEY}: {story title}

El FTP funciona distinto. Es de la altitud de la épica y se refina mientras la épica avanza. El ATP lo cita en vez de volver a derivarlo, y por eso el análisis de una historia empieza mirando a sus hermanas.

Ejecutar, después priorizar, después documentar

Lo intuitivo sería escribir los casos y después correrlos. El IQL invierte el orden porque el set de regresión persistente se decide por retorno, y el retorno solo se conoce después de haber probado. La secuencia cruza la frontera de fase: empieza en el Early-Game y termina en el Mid-Game.

1. Step 3 · Early-Game: Pruebas Exploratorias Tempranas

   Smoke de Go/No-Go, después Trifuerza. Los hallazgos se clasifican y se reportan en el momento.

2. Step 4 · Early-Game: Priorización Risk-Based

   Cada escenario recibe su veredicto de ROI: Candidate, Manual o Deferred.

3. Step 5 · Mid-Game: Documentación Asíncrona de Test Cases

   Solo los Candidate y Manual se formalizan en el TMS, y siempre después de ejecutar y reportar. Detalle en Mid-Game.

El workflow de la User Story en Jira

El Early-Game toma la historia en el backlog y la deja aprobada o con bugs reportados. El diagrama muestra el ciclo completo en la instancia real de Jira, con los nombres de estado exactos. Los cuatro steps de la fase caen en su primer tramo.

Enfoques y herramientas de la fase

Shift-Left

Mover las actividades de calidad más temprano, antes de que exista código que romper.

BDD

Especificación colaborativa en escenarios Given-When-Then, escritos con el equipo.

Risk-Based

Priorizar por impacto y probabilidad de fallo en lugar de cubrirlo todo por igual.

En este repo

Cada stage del Early-Game tiene un skill dueño en .agents/skills/:

El Definition of Done y el contrato de cada stage están en .agents/skills/agentic-qa-core/references/stage-gates.md. Cómo encaja todo el IQL con el repo se cuenta en El IQL en este repo.