Agentic QA

Test Management Architecture

Cuatro altitudes, un plan y un corredor en cada una.

Cómo este repositorio organiza la gestión de pruebas: la escalera MTP → FTP → STP → ATP con sus corredores STR y ATR, los cuatro epics de proceso que los sostienen en Jira, qué skill produce cada artefacto y cómo bajan todos al caché local. Todo lo que sigue está verificado contra el código, no contra la intención.

01 · altitudes

La escalera

La gramática de títulos es {ACRONYM}: {scope}: {desc}, elegida para que la altitud se lea en el primer token. Antes de esa regla, el mismo tipo de issue Test Plan se titulaba de tres formas distintas y nadie podía saber, mirando un título, si era el plan de un sprint o el de una historia.

Escalera de artefactos QA por altitud Cuatro bandas apiladas de alcance más amplio a más puntual: Master con el MTP, Feature con el FTP, Sprint con el STP y el STR, y Story con el ATP, el ATS y el ATR. Cada banda muestra su tipo de issue en Jira y quién lo produce. AMPLIO PUNTUAL MASTER MTP Epic — no es un Test Plan sin corredor project-context 1 por proyecto FEATURE FTP Test Plan — 1 por epic FTR retirado se leen en los ATR, sin agregación sprint-testing SPRINT STP Test Plan — vivo desde el 1er ticket STR Test Execution — recap al cierre 1 por sprint STORY ATP + ATS Test Plan + Test Set — el ATS da la cobertura ATR Test Execution — siempre con environment 1 por historia LEYENDA la altitud donde se ejecuta el trabajo diario Todo plan cuelga del epic QA Master Test Plan. Todo corredor, de QA Test Artifacts.

Fig. 1 — un plan por altitud, un corredor arriba del Master. El FTR fue cortado a propósito: en el lado de resultados no hay agregación estructural, así que los de feature se leen en el ATR de cada historia y se revisan juntos al cierre del sprint.

Un plan describe lo que se va a probar. Un corredor registra lo que efectivamente pasó. Emparejarlos por altitud es lo que hace que la trazabilidad no dependa de la memoria de nadie.

02 · topología en Jira

Cuatro epics de proceso, y ningún artefacto de QA en un epic de producto

El modelo de tres ejes es la regla que evita que la trazabilidad se convierta en una sola jerarquía sobrecargada. El padre dice en qué balde de QA vive el artefacto. El link dice de qué historia salió. Los components dicen qué módulo del producto toca. Nunca se mezclan, y por eso el roadmap de producto no se contamina con artefactos de prueba.

Los cuatro epics de proceso QA en Jira Cuadrícula de cuatro contenedores: QA Master Test Plan agrupa los Test Plan de toda altitud, QA Test Repository agrupa los Test, QA Test Artifacts agrupa Test Execution, Test Set y Precondition, y QA Defect Management agrupa bugs, defectos y mejoras. Abajo, los tres ejes de trazabilidad. QA MASTER TEST PLAN Todo Test Plan, de cualquier altitud FTP: {EPIC}: {feature} STP: Sprint#{N}: {objective} ATP: {STORY}: {title} El epic mismo ES el MTP. QA TEST REPOSITORY Todo Test — el caso de prueba Test · should … Entran por el gate de ROI, no por defecto: analizados 80 → documentados 12 → automatizados 8 Un verdicto Deferred nunca persiste un Test. QA TEST ARTIFACTS Corredores, sets y precondiciones ATR: {STORY}: Story Testing STR: Sprint#{N}: Regression Testing ATS: {STORY}: {title} El ATS es obligatorio aunque haya un solo caso. QA DEFECT MANAGEMENT Todo reporte de calidad Bug · Defect · Improvement Se clasifican por la etapa de vida de la FEATURE, no por dónde apareció el problema. La historia de origen viaja por link, no por padre. LOS TRES EJES, NUNCA MEZCLADOS padre el balde de QA donde vive link la historia de la que salió components el módulo del producto afectado COBERTURA: la llena el link ATS→Story, o un link directo Test→Story. ATP→Story y ATR→Story dan CERO.

Fig. 2 — verificado en vivo contra Xray: una historia enlazada solo a su Test Plan y su Test Execution aparece como UNCOVERED, 0 tests.

03 · productores

Qué skill crea cada artefacto, y cuándo

El traspaso que define la metodología es el primero. Antes del sprint, el plan de aceptación vive solo en un campo de la historia; el issue de Jira recién nace cuando la historia entra al sprint. Una historia que muere en el backlog no consume ni un artefacto.

Skills productoras de artefactos a lo largo del ciclo Cinco carriles horizontales, uno por skill, sobre un eje que va de pre-sprint al cierre del sprint. Shift-left escribe el plan de aceptación en el campo de la historia; sprint-testing crea los issues en Stage 1, los llena en Stage 3 y cierra el sprint; test-documentation filtra casos por ROI; test-automation escribe los decoradores; regression-testing comparte la creación del recap. PRE-SPRINT STAGE 1 STAGE 2-3 STAGE 4-5 CIERRE shift-left -testing ATP en el campo sin issue de Jira sprint -testing ATS · Test · ATP · ATR orden Set-first ATR lleno con environment STR recap del sprint test-doc umentation Test por ROI 80 → 12 → 8 test-auto mation @atc('KEY') decorador, no issue regression -testing STR el que llegue primero

Fig. 3 — la flecha naranja es el traspaso campo → issue. La punteada marca el STR, que crea quien llegue primero entre el cierre de sprint y la corrida de regresión.

04 · caché local

Cómo bajan los artefactos al repositorio

Jira es la fuente de verdad; .context/PBI/ es un caché gitignoreado que bun run context:hydrate reconstruye en un comando. La regla de diseño es que el nombre del archivo en disco lleve el mismo acrónimo que el título en Jira, para que la altitud se lea igual de rápido en un ls que en el backlog. 

.context/PBI/
├─ epics/EPIC-<KEY>-<slug>/
│  ├─ epic.md · module-context.md
│  ├─ feature-test-plan.md          ← espejo del FTP
│  └─ stories/STORY-<KEY>-<slug>/
│     ├─ story.md · acceptance-criteria.md
│     ├─ acceptance-test-plan.md    ← espejo del ATP
│     ├─ acceptance-test-results.md ← espejo del ATR
│     └─ test-cases/                ← los Test, colocados por la cascade
│
├─ test-plans/       FTP-<KEY>-<slug>.md · STP-<KEY>-<slug>.md · ATP-<KEY>-<slug>.md
├─ test-executions/  STR-<KEY>-<slug>.md · ATR-<KEY>-<slug>.md · RETEST-<KEY>-<slug>.md
├─ test-sets/ · preconditions/
└─ qa-artifacts/_index.md    ← registro de los cuatro epics de proceso

El nombre dice la altitud

  • El prefijo sale del título, no del tipo de issue
  • Un ls test-plans/ muestra el estado de la escalera sin abrir nada
  • Un título que no sigue la gramática cae al prefijo genérico y sincroniza igual

Los epics son el índice

  • Las altitudes altas no cuelgan de ninguna historia, así que la caminata de links nunca las alcanza
  • pull barre los hijos de los cuatro epics de proceso
  • Cero configuración nueva: la estructura ya existía en Jira

Dos vistas del mismo dato

  • Dentro de la historia: el cuerpo del plan y del resultado, como los lee quien testea
  • En test-plans/: el issue completo, como lo ve quien audita
  • El item de Jira siempre gana sobre la copia del custom field

Un detalle que parece menor y no lo es: la guarda que impide que un FTP enlazado a una historia sea confundido con el plan de esa historia se queda igual. Materializar las altitudes altas es un camino aparte. Mezclar las dos cosas era lo que dejaba tres peldaños invisibles en disco.

05 · el circuito completo

Del criterio de aceptación al test automatizado

El circuito cierra cuando el resultado de una corrida automatizada vuelve al issue del que salió el caso. Ese retorno es la parte que más fácil se rompe, porque entre el código y Jira lo único que ata las dos puntas es que dos strings sean iguales.

Circuito del criterio de aceptación al resultado automatizado Cadena horizontal de seis etapas: criterio de aceptación, esquemas en el campo de la historia, Test más Test Set que aporta la cobertura, ejecución manual registrada en el resultado de aceptación, verdicto de ROI y decorador en el código, y el retorno de resultados a Jira. 1:N STAGE 1 STAGE 3 ROI SYNC Criterio campo de la historia Esquemas ATP, solo en el campo Test + Set aca nace la cobertura Ejecución ATR con environment Decorador @atc('PROJ-101') Resultados vuelven al Test El identificador del decorador ES la clave del issue de Jira. No hay traducción, no hay mapa: son el mismo string. Por eso el caso tiene que existir en el TMS antes de escribir el decorador — la sincronización no crea tickets.

Fig. 4 — el circuito. Los once primeros saltos son sólidos; el último, el retorno de resultados, es el que hay que mantener encendido.

06 · referencia

Artefacto por artefacto

Artefacto Productor Tipo en Jira Epic padre Cardinalidad
MTP Master Test Plan project-context Epic es uno de los cuatro 1 por proyecto
FTP Feature Test Plan sprint-testing Test Plan QA Master Test Plan 1 por feature
STP Sprint Test Plan sprint-testing §0.7 Test Plan QA Master Test Plan 1 por sprint
STR Sprint Test Results regression-testing o sprint-testing Test Execution QA Test Artifacts 1 por sprint
ATP Acceptance Test Plan shift-left al campo → sprint-testing al issue Test Plan QA Master Test Plan 1 por historia
ATS Acceptance Test Set sprint-testing Stage 1 Test Set QA Test Artifacts 1 por historia, obligatorio
ATR Acceptance Test Results sprint-testing S1 crea, S3 llena Test Execution QA Test Artifacts 1 por historia por sprint
Test el caso test-documentation, gate de ROI Test QA Test Repository N por historia
ATC el decorador test-automation no es issue — 1:1 con un Test