Mid-Game: detección

La fase en una tabla

Los stages de esta fase

Los dos stages del Mid-Game ocurren en el cierre y release del sprint, con nivel L3 · Continuous Detection. Documentation empieza en el Early-Game (step 4) y termina aquí. Automation es el único stage del IQL con verificación separada obligatoria. 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.

Documentation

Sobre comportamiento ya validado, cada escenario recibe exactamente un veredicto y solo se persisten los que demostraron valor de regresión. La mayoría tiene que caer en Deferred.

Automation

Solo entran los Candidate. Primero el plan, después el código, y tres verificadores en verde antes del pull request.

El gate de ROI: Candidate, Manual o Deferred

El veredicto de ROI se decide en el step 4, sobre escenarios que ya se ejecutaron y se reportaron. Solo lo que demostró valor de regresión llega al TMS.

Veredicto y estado comparten nombre (Candidate y MANUAL en el TC, Deferred en el Bug), pero el veredicto es la decisión de ROI y el estado es dónde está el ticket.

Los 5 steps del Mid-Game

El Mid-Game cierra el TMLC (Test Manual Life Cycle) con su 4ª etapa y recorre entero el TALC (Test Automation Life Cycle): Evaluación, Automatización, Verificación CI y PR Review.

Step 5 depende de la modalidad del TMS

El verbo del step 5 cambia con la modalidad. En jira-native aquí se crean los TC, porque un issue Test nativo ya es documentación y por eso espera al gate de ROI. En jira-xray (la instancia de UPEX) los Test existen desde Planning y aquí se enriquecen y promueven: Gherkin rico, label regression-candidate, Test Set de la feature y Regression Test Plan. En los dos casos la documentación es asíncrona a propósito: va después de ejecutar y reportar, nunca antes.

El TC es el caso individual y vive en el TMS. Un ATC es lo que un TC es cuando nace de un criterio de aceptación. Los casos de la historia se agrupan en su ATS (Acceptance Test Set), obligatorio incluso con un solo caso, porque la cobertura la da el enlace del ATS a la historia.

Herramientas por step

Los casos primero, el plan después

El set de casos de la historia se crea antes que su plan y que su ejecución, porque los dos derivan su lista de él. Y la cobertura en Jira la da el enlace del set a la historia, no el del plan. El orden set-first es TC → ATS → ATP → ATR, y el diagrama muestra cómo lo aplica /sprint-testing en la modalidad jira-xray.

1. Crear los Test (TC) de la historia

   Al detalle ejecutable.

2. Crear el ATS con todos ellos

   Título ATS: {STORY-KEY}: {TITLE}.

3. Enlazar el ATS a la historia

   Enlace Test · is tested by. Es la arista que da cobertura; el enlace directo de un caso a la historia también cubre, pero solo como último recurso.

4. Recién ahí, el ATP

   Se crea desde el custom field de la historia. Su lista de casos deriva del ATS.

5. El ATR, con su Test Environment

   Sin entorno no pasa el Definition of Done. Su lista también deriva del ATS.

6. Execution: smoke primero, después exploración

   Go/No-Go del entorno y luego la Trifuerza UI · API · DB, más allá de lo planificado.

7. Reporting: completar el ATR y comentar

   Resultado por caso, comentario de QA y transición del ticket, con defectos si los hubo.

KATA (Komponent Action Test Architecture)

El step 7 implementa los casos candidatos sobre una arquitectura por capas: cuatro capas nombradas, más Steps como capa opcional, con una sola dirección de dependencia. Una capa puede usar las de abajo y nunca al revés. Dos advertencias: las letras del acrónimo no son las capas, y el decorador @atc no crea un artefacto nuevo. Nombra la representación en código del mismo caso que ya existía en el gestor de pruebas.

Contar los archivos de test como una capa más es el origen de los conteos de cinco y seis capas que circulan. Un ejemplo de decorador es @atc('PROJ-101'): ata el método a su caso en Jira.

Dónde conviene poner el esfuerzo

Automatizar todo al nivel de interfaz es la forma más cara de tener una suite frágil. La pirámide reparte el esfuerzo: mucha prueba barata abajo, poca prueba cara arriba y, en el medio, lo que verifica que las piezas se hablen.

Enfoques y herramientas de la fase

Continuous Testing

Testing automatizado integrado en la pipeline, que corre con cada cambio.

Agile Testing

Ciclos de prueba que caben dentro del sprint y no lo empujan hacia adelante.

AI-Driven

IA aplicada a acelerar el análisis, la documentación y la cobertura.

En este repo

La frontera entre los dos stages es el veredicto estampado con approve to automate (In Review → Candidate). El registro de componentes y ATCs que existen es kata-manifest.json, en la raíz del repo, y el DoD de cada stage está en .agents/skills/agentic-qa-core/references/stage-gates.md. Más detalle en El IQL en este repo.