AGENTIC QA · WORKFLOW SKILL

/test-documentation

El puente entre la QA manual y la automatización: analiza, prioriza con ROI y documenta test cases en el TMS con trazabilidad completa.

Stage 4 — TMS docs + ROI Analyze → Prioritize → Document US↔ATP↔ATR↔TC Candidate · Manual · Deferred

Deck del workflow del skill /test-documentation. Regla de la casa: la mayoría de los escenarios NO se automatizan — el veredicto por defecto es Deferred. Navegación: → avanzar, S presentador, O vista general, N notas.

el mapa completo — índice mental del deck

Del comportamiento validado al repositorio de regression

ENTRADA Story QA Approved (desde /sprint-testing) Bug cerrado con fix verificado Módulo explorado end-to-end Sesión exploratoria terminada (ad-hoc)

Preflight Gate

/acli + [TMS_TOOL] operativos

RED bloqueante → STOP

→

-1

Resume check

.session/…/progress.md

resume · restart · abort

→

Modalidad TMS

gate: ¿Xray licenciado?

jira-xray | jira-native

→

Alcance

module · ticket · bug · ad-hoc

plan.md escrito

→

Analyze

escenarios reales + código

1 (pre+acción) = 1 TC

→

Prioritize

3 filtros + fórmula ROI

C · M · D

→

Document

crear / promover + enlazar

>10 TCs → paralelo

→

✓

Nada se documenta sin pasar los gates

Prerrequisito duro

Solo comportamiento ya validado: Story QA Approved, bug cerrado, o sesión exploratoria terminada. El TMS documenta y protege regression — no es una herramienta de exploración (explorar es de /sprint-testing).

Preflight Gate

REQUIRED: issue-tracker operativo (/acli, valida con bun run jira:check) + modalidad TMS resoluble (jira-xray → /xray-cli + creds XRAY_*). OPTIONAL: repos fuente legibles. No toca entorno vivo → sin probes de DB/API/browser. Gaps → UNA checklist; RED bloqueante → STOP.

Fase -1 · Resume check

Lee .session/test-documentation/<scope>/progress.md. Si existe: muestra scope, modalidad, última fase completada y chunks pendientes → ofrece resume / restart / abort (restart archiva primero).

El caso de resume que más importa

Bulk create de la Fase 3 interrumpido a mitad de lote: progress.md registra cada chunk completado (uno por subagente), así que resume salta los TCs ya creados y despacha solo los chunks faltantes.

Los tres candados corren en orden: prerequisito de comportamiento validado (conceptual), preflight de capacidades (mecánico: acli + TMS), y resume de sesión. El skill no ejecuta contra un sistema vivo — su gate se centra en poder ESCRIBIR en el TMS.

fase 0 — gate obligatorio, se resuelve UNA vez

¿Xray licenciado? Mismos conceptos, distintos contenedores

Config

{{TMS_CLI}} = bun xray → jira-xray; acli-solo o sin definir → jira-native.

Master Test Plan

Línea TMS: Xray on Jira o TMS: Jira native en .context/master-test-plan.md.

Issue types

¿Existen Test Plan / Test Execution / Test Set / Pre-Condition? Sí → jira-xray; no → jira-native.

Preguntar

Solo si los tres sondeos fallan. Persistir en plan.md; sticky — drift a mitad de sesión → STOP y pregunta.

Artefacto	jira-xray	jira-native (sin Xray)
ATP	Issue Test Plan «ATP: {STORY}: {título}»	Mismo issue Test Plan por excelencia; fallback: campo de la Story → comment
ATR	Issue Test Execution con Test Runs por TC	Mismo issue Test Execution; fallback: campo de la Story → comment
TC	Xray Test (Manual / Cucumber / Generic)	Issue type Test nativo; la Description lleva el template completo
Test Set / Pre-Condition	First-class	No existen → labels + agrupación por Epic
Result sync (CI)	Import Results JUnit/Cucumber → runs auto	Script actualiza Test Status + comment por build

Items-first en AMBAS modalidades: Test Plan y Test Execution son work types nativos de Jira, independientes de Xray — el campo de la Story es un fallback degradado solo cuando el work type no existe en la instancia. Nunca mezclar modalidades dentro de una misma Story (anti-patrón D5).

elige el alcance por la ENTRADA, no por la salida

Cuatro alcances, un solo pipeline

Alcance	Entrada	Volumen típico	Sesgo por defecto
Module-driven	un módulo explorado de punta a punta	20-100+ escenarios	la mayoría terminará Deferred
Ticket-driven	una Story QA Approved del sprint	3-8 escenarios	ATP/ATR por Story
Bug-driven	un bug cerrado con fix verificado	0-2 escenarios	ROI sesgado ARRIBA — «falló una vez, puede fallar de nuevo»
Ad-hoc / Exploratory	escenarios nuevos de exploración	1-10 escenarios	aplica los 3 filtros con dureza

Al confirmar el alcance, la IA escribe el plan

<scope> = <JIRA-KEY> (ticket/bug) · <module-slug> · <YYYY-MM-DD>-adhoc. Escribe .session/test-documentation/<scope>/plan.md: goal (scope + modalidad + nº de TCs esperados), inputs (PBI, ATP, bugs previos), fases, riesgos y checklist de verificación — y registra el checkpoint en progress.md.

Un ID de Story → ticket-driven · un ID de bug → bug-driven · un nombre de módulo → module-driven · notas de sesión → ad-hoc.

Los cuatro alcances comparten el pipeline Analyze → Prioritize → Document; solo cambian la fuente de entrada y los defaults. El plan-first es obligatorio (contrato de sesión): nada se crea en el TMS sin plan.md escrito.

alcance bug-driven — la regla que vale oro

Un bug importante DEBE terminar con un Test

¿Es candidato de regression?

Aplica los filtros de la Fase 0 + ROI (el bug previo sesga hacia arriba). NO → trátalo como un test fallido: el fix ya se verificó en sprint-testing → Deferred, sin Test nuevo. SÍ → paso 2.

¿Vino de un Test ya ejecutado que falló?

SÍ → REUTILIZA ese Test: enlázalo al bug (tests / is tested by) y promuévelo a regression — nunca dupliques. NO → CREA + diseña el Test (native: issue Test; xray: Xray Test + Test Plan / Test Set).

Anula «el bug es el test case»

Esa frase de /sprint-testing cubre solo el retest inmediato del sprint — NO la regression futura. Esta regla decide si debe existir un Test persistente para que el bug nunca regrese en silencio.

Nunca reabras un bug cerrado (D8)

La historia del bug es inmutable. Crea el TC nuevo y enlázalo vía tests / is tested by — no adjuntes regression reabriendo el issue.

Un bug cerrado es evidencia empírica fuerte de que el área regresa: la mayoría califica y se inclina a Candidate — pero no todos (un typo puntual en un área estable se difiere). La decisión reuse-or-create evita duplicar Tests que ya existen en el set.

fase 1 — analyze · qué entra

Reúne las fuentes — y luego lee el código

Fuente	Qué se lee	Por qué
Story / Epic	carpeta sincronizada completa: story.md, acceptance-criteria.md, scope, business rules, comments.md	identificar escenarios + señales de riesgo
Bugs cerrados enlazados	summary, causa raíz, área del fix	regla de priorización por bug previo
ATP / ATR existentes	lectura modality-aware vía bun run jira:sync-issues get <KEY> --include-comments → leer el .md sincronizado	escenarios y resultados que ya existen — no reinventar ni re-ejecutar
Implementation plan + código	archivos reales, APIs, test IDs	validar diseño vs implementación
domain-glossary.md	nombres canónicos de entidades y procesos	vocabulario de títulos, pasos y precondiciones

Validación contra código fuente — obligatoria antes de documentar

El ATP se escribió ANTES de que el código existiera. Grep a data-testid=, route handlers, rutas de API y formatos de texto; toda divergencia va a una sección Refinement Notes del TC. Saltarse este paso es la causa nº1 de tests automatizados inválidos después.

Lecturas detalladas SIEMPRE por el script de sync (acli view devuelve null en custom fields). Discrepancias típicas: una API asumida que en realidad es SSR/DB directa; "based on N reviews" vs el real "(N reviews)"; IDs hardcodeados vs patrón de variable.

fase 1 — analyze · las dos reglas portantes

Una (Precondición + Acción) = un TC

✓ MISMO TC — 5 aserciones

pre credenciales válidas, acción enviar login
redirección + token + perfil vía /auth/me + cookie + bienvenida
todas las validaciones viven en UN TC — dividir «panel A / B / C» es el antipatrón más diagnosticado

≠

✓ TC DISTINTOS — la precondición difiere

credenciales válidas → éxito (TC-A)
cuenta bloqueada → 423 (TC-B)
credenciales inválidas → 401 (TC-C)

Cross-cutting (NO es un TC)	Se valida…
Responsive · XSS · performance · a11y · contrato de API · «manejo de errores» genérico	dentro de cada test (viewport móvil, datos con caracteres especiales, aserciones de tiempo/a11y/schema) o en una suite a nivel de app
Deferral ≠ omission	mover un rasgo transversal fuera del alcance es un handoff explícito: nombra la suite receptora o registra el gap (TC Deferred o nota en el ATR) — nunca se evapora

Un escenario real es un flujo de usuario: objetivo de negocio claro, precondición + acción concretas, resultado verificable. Los rasgos transversales se prueban DENTRO de otros tests o en suites app-level — promover "prevención XSS" a TC propio es error clásico.

fase 1 — analyze · doctrina de diseño (test-design-doctrine.md)

Un AC → N candidatos, elegidos por la forma del AC

Disparador en el AC	Técnica (obligatoria)	Qué produce
Cualquier input (siempre)	Equivalence Partitioning	mismo output → UN TC parametrizado (Scenario Outline + Examples); output distinto → TCs separados
Rango / límite / longitud / ventana de fecha	Boundary Value Analysis	min-1 · min · min+1 … max-1 · max · max+1 + cero / vacío / null / overflow
Campo de estado / ciclo de vida	State-Transition	un TC por transición válida + por transición inválida
2+ condiciones que interactúan	Decision Table	enumera combos, colapsa equivalentes, un TC por regla sobreviviente
3+ factores combinables	Pairwise	conjunto all-pairs (registra la reducción)

Candidatos ≠ items del TMS

Derivar amplio es gratis; persistir está gateado por ROI (Fase 2). Colapsar un AC a un solo TC exige justificación escrita «trivially atomic». El mapa AC→TC es el piso, no la cobertura.

Improvement bridge

Un test-beyond-AC expone un gap porque el AC estaba infra-especificado → el artefacto correcto es un issue Improvement (doctrina de defect-management) — NO un TC de regression ni ensanchar los ACs de la Story después del hecho.

EP sin BVA pierde el off-by-one. La regla de identidad (pre+acción) solo fusiona DENTRO de una partición — nunca a través de particiones, límites o estados. Canon: agentic-qa-core/references/test-design-doctrine.md.

fase 2 — prioritize · el gate que nunca se salta

Tres filtros, luego la fórmula

¿Protege contra regressions futuras?

Typo puntual en un área estable → No → Deferred.

¿Bugs previos en esta área?

Sí → prioriza aun con ROI moderado: «falló una vez, puede fallar de nuevo».

¿Nivel de app o de feature?

XSS / a11y / perf / responsive → suites APP-level → Deferred desde este alcance.

Falla cualquier filtro → Deferred

Los tres filtros matan a la mayoría antes de hacer aritmética.

ROI = (Frequency × Impact × Stability) ───────────────────────────────── (Effort × Dependencies) Component Value = ROI × (1 + 0.2 × N) N = flujos E2E que reutilizan el TC

Factor (1-5)	1	5
Frequency	anual	cada PR / commit
Impact	cosmético	ingresos / core
Stability	muy volátil	meses sin cambios
Effort (÷)	trivial	semana+
Dependencies (÷)	ninguna	externos complejos

Effort y Dependencies son DIVISORES: un "flujo crítico" caro y acoplado DEBE puntuar bajo — es la fórmula funcionando, no un bug. Component Value rescata átomos reutilizables: authenticateSuccessfully con ROI 1.5 reutilizado en 5 flujos → 1.5 × 2.0 = 3.0 → Candidate.

fase 2 — prioritize · exactamente uno de tres, no hay cuarto

Candidate · Manual · Deferred — la modalidad cambia el verbo

Veredicto	Lo dispara	A dónde va	Fase 3: jira-native	Fase 3: jira-xray
Candidate	ROI > 3.0 · O 1.5-3.0 + bug previo · O happy path crítico	alimenta /test-automation	se CREA el work item Test (solo C + M)	el Test ya existe (Stage 1 de sprint-testing) → se PROMUEVE al Regression Test Plan + Test Set, label regression-candidate, y se ENRIQUECE (Gherkin rico, parametrización, edge cases)
Manual	ROI 0.5-1.5 y no automatizable, o solo-manual explícito	suite de regression manual (terminal)	se CREA el work item Test (solo C + M)
Deferred	ROI < 0.5 · O falló un filtro · O validación one-time	fuera de regression (terminal, revisitable)	NO se crea — queda solo en el reporte	el Test de sprint queda sin promover — no se borra

Tres capas, tres conteos — la forma saludable

analizados 80 → documentados 12 → automatizados 8. Un test entra al repositorio porque será re-ejecutado, nunca para alcanzar un conteo. Si >50% termina Candidate/Manual → reaplica los filtros con más rigor: la mayoría debe ser Deferred.

El veredicto (aritmética) es idéntico en ambas modalidades; lo que cambia es el verbo de la Fase 3: CREAR (native) vs PROMOVER + ENRIQUECER (xray). Deferred nunca es un borrado. Anti-patrón D4: nunca saltarse el scoring de ROI.

fase 3 — document · preflight de contenedores

Epic · Test Set · Test Plan — tres cosas distintas

Regression Epic

= el epic de proceso «QA Test Repository». Resolver found-or-created por JQL (type = Epic AND summary ~ "QA Test Repository"); si falta, pregunta antes de crear y cachea la key en .agents/project.yaml. Todo TC documentado se parenta aquí — nunca a un epic de producto.

paraguas del repositorio

Test Set solo xray

Agrupación por feature, 1:1 con el Epic: Test Set: <EPIC_KEY> <feature>. Se crea lazy en esta fase solo si una promoción lo necesita — preguntando primero. Solo entran los Tests promovidos (C/M). Native: no existe → label de feature/Epic (epic-<KEY>).

feature

Test Plan

Alcance de ejecución / regression — el conjunto de Tests que corre para un release o ciclo. El ATP en jira-xray ES un issue Test Plan (parent: epic «QA Master Test Plan»).

ejecución

Modelo de tres ejes (defect-management-doctrine.md)

Parent = bucket de proceso QA (Test → «QA Test Repository» · ATP → «QA Master Test Plan» · ATR → «QA Test Artifacts») · issue-link = la Story origen · components = el módulo de producto afectado. Tres ejes separados — el parent nunca lleva la traza de producto.

La gente fusiona estos contenedores rutinariamente. Epic = repositorio completo; Test Set = los Tests de regression de UNA feature; Test Plan = alcance de ejecución. En jira-native no hay entidad Test Set: la misma agrupación se logra con el Regression Epic + un label.

fase 3 — document · el orden no es opcional

ATP → ATR → enlazar → recién entonces cada TC

1 Create ATP → link a la US («is tested by») 2 Create ATR → link a la US («is tested by») 3 Update ATP → link al ATR (plan/results, 1:1) 4 por cada TC: Create TC → «is designed by» ATP → «is executed by» ATR xray: el TC NO se enlaza a la Story (agrega vía ATP/ATR; evita ruido) native: Story↔TC es el edge disponible 5 por cada TC PROMOVIDO: xray → Test Set + Regression Test Plan + label regression-candidate native→ label de feature/Epic

Entidad	Naming
ATP	ATP: {STORY-KEY}: {story title}
ATR	ATR: {STORY-KEY}: Story Testing
TC	{US_ID}: TC#: should <outcome> [when <condition>] [given <pre>] — prefijo SIEMPRE el US key, en toda modalidad
Agrupación	Validate <feature> reservado para el nivel de grupo (Test Set / describe())

Crear TCs primero = huérfanos

Si el TC nace antes del ATP/ATR quedan referencias rotas y /fix-traceability es la única salida. D7: un ATR nunca se enlaza a dos ATPs (1:1). Rechaza títulos «Login test», «Login - error», «TC1: Test form».

El modelo de trazabilidad jira-xray: la Story se enlaza SOLO a su ATP y ATR; los TCs agregan a través de ellos (el ATP "diseña" los TCs, el ATR los "ejecuta"). La cobertura AC→TC se registra en la matriz del ATP, no como issuelink Story↔TC. En native, sin issue ATP/ATR de por medio, Story↔TC sí es el edge de trazabilidad.

fase 3 — document · el verbo por modalidad, TC por TC

Crear los TCs — matriz por modalidad

Stack	Test manual	Candidate (automatizable)
Xray on Jira	Dos pasos: (1) Create Test type=Manual SIN steps inline — Xray Cloud los descarta en silencio — (2) Add Test Step uno a uno (verifica con Get Test), luego Update Issue con la Description completa	Create Test type=Cucumber gherkin=… + Update Issue con el template de Description
Jira native	Create Issue issueType=Test, Description = tabla de pasos	Create Issue issueType=Test, Description = Gherkin + template completo

La regla de las dos llamadas de Xray

Una Create Test (registra en Xray) + una Update Issue (pega la Description). Saltarse la segunda deja un TC sin documentación legible en Jira — el fallo silencioso más común.

Anti-patrones D1 · D6

Nunca escribas ADF JSON a mano (usa la ruta md→ADF de /acli). Nunca fabriques customfield_NNNNN: corre bun run jira:sync-fields --force y resuelve por {{jira.<slug>}}.

Description siempre con el template completo: Related Story · Priority · ROI · Prior bugs · Test Design (gherkin/steps) · Variables · Implementation Code · Architecture · Test IDs · Preconditions · Expected Results.

La dispatch de esta fase es la única paralela: N > 10 TCs → subagentes en chunks de 5-10 (ver slide de orquestación). Cada subagente carga /xray-cli o /acli según modalidad y corre este flujo serial para su chunk.

fase 3 — document · el artefacto que viaja a automatización

Gherkin de alta calidad: variables, nunca datos duros

TC — UPEX-101.feature

@critical @regression @automation-candidate @UPEX-101
Scenario Outline: should show auth error when password is incorrect
  """  Bugs covered: UPEX-202 · Related Story: UPEX-101 · ROI: 4.0  """
  # === PRECONDITIONS ===
  Given a verified user exists with {email}
  # === ACTION ===
  When the user submits login with {email} and {wrong_password}
  # === VALIDATIONS ===
  Then a 401 error is returned with "<message>"
  # === EQUIVALENT PARTITIONS ===
  Examples: Wrong password | Empty password | Unknown email

Variables, nunca hardcode. {mentor_id}, no 550e8400-…. Tabla de Variables con cómo obtener cada valor en runtime.
Tags siempre: prioridad (@critical…@low) + suite (@regression, @smoke si ruta crítica) + @automation-candidate + @{US_ID}.
Comentarios estructurados — PRECONDITIONS / ACTION / VALIDATIONS / EQUIVALENT PARTITIONS.
Docstring con metadata: story, bugs cubiertos, ROI.
Parametriza por partición: variantes de mismo comportamiento → UN Test con Examples, no N Tests.

Los datos de staging cambian con los años: un UUID o email literal pudre el test. Cada variable lleva su query de obtención ({email} → SELECT email FROM users WHERE active=true LIMIT 1). Este Gherkin es exactamente lo que /test-automation consumirá.

fase 3 — document · workflow del TC y cierre limpio

Cómo un TC recorre su vida — sin saltarse estados

Draft ──start_design──▶ In Design ──ready_to_run──▶ Ready ──┬── for_manual ─────────────────▶ Manual (terminal) └── automation_review_from_ready ▶ In Review ──approve_to_automate──▶ Candidate → /test-automation

Nunca saltes estados. Rework solo vía back_from_<state>. Slugs desde .agents/jira-workflows.json ({{jira.transition.test_case.<slug>}}) — nunca nombres literales hardcodeados.
Labels base por TC. alcance: regression casi siempre, smoke solo ruta crítica (10-20% de la suite), + e2e/integration/functional · estado: automation-candidate ↔ manual-only excluyentes; al mergear → automated.
Caché local (hand-authored, no synced). un md por TC en …/stories/STORY-<KEY>-<slug>/test-cases/{TC-ID}-{slug}.md — carpeta test-cases/, NO tests/ (esa la posee el sync). Evita releer el TMS y da handoff inmediato.
Checkpoint + Archive. cada fase (y cada chunk paralelo) apéndice en progress.md; tras el reporte final + coverage matrix → archivar a .session/.archive/… + mem_session_summary. Falla parcial (429s) → NO se archiva: resume retoma los chunks.

Dos campos independientes: Test Status (workflow — dónde está en su vida) vs Execution Status (la última run). "Candidate" con última run FAIL es una combinación válida. La coverage matrix queda en .context/reports/ como entregable comprometido.

quién hace qué — centro de comando + subagentes

El hilo principal decide; los subagentes escriben

Inline (orquestador)

Fases -1, 0, 1 y 2: resume, modalidad, análisis y veredictos viven en el hilo principal — planificar y decidir no se delega.

criterio

Paralelo (Fase 3, N > 10)

Chunks de ~5-10 TCs por subagente, cap = 10 subagentes (Jira/Xray throttlean ~10 writes/seg → 429s). Cada subagente carga /xray-cli o /acli. N ≤ 10 → inline.

fan-out

Error protocol

Fallo de subagente → STOP, reporta el estado parcial (qué TCs aterrizaron, cuáles no, con keys/errores) y ofrece retry / skip / abort. Sin auto-fix, sin rollback.

seguridad

Necesidad	Herramienta	Nota
Lecturas detalladas (custom fields, ACs, ATP/ATR, comments)	bun run jira:sync-issues get <KEY> --include-comments	leer el .md sincronizado — acli view devuelve null en custom fields
Escrituras TMS (Test / Plan / Execution / link / transición)	/xray-cli (jira-xray) · /acli (jira-native + Jira genérico)	cargar el skill ANTES de invocar el binario
IDs de campos / workflows	bun run jira:sync-fields + {{jira.<slug>}}	anti-patrón D6
Validación de código fuente	Grep / Read sobre el repo	sin entorno vivo — solo lectura de código

La división es deliberada: el criterio queda en el centro de comando; las escrituras crudas de API se reparten con tope de concurrencia. El enlazado de trazabilidad y la matriz de cobertura corren inline al final porque necesitan el estado agregado de todo lo creado.

todo el mapa, en una invocación bug-driven

Una corrida de documentación, de punta a punta

claude-code

> /test-documentation — turn closed bug UPEX-202 into a regression test

[Preflight] acli OK (bun run jira:check) · modalidad resoluble → GREEN
[Fase -1]   Sin sesión previa para UPEX-202 — empezando de cero.
[Fase 0]    Modalidad: jira-native (sin issue types de Xray). Sticky en plan.md.
[Alcance]   bug-driven · plan.md escrito en .session/test-documentation/UPEX-202/
[Fase 1]    jira:sync-issues get UPEX-202 + Story UPEX-101 (--include-comments).
            Grep: data-testid="login-error" confirmado · ruta /api/auth/login.
[Fase 2]    Filtro F2: bug previo = SÍ. ROI = (4×5×4)/(2×1) = 40 → CANDIDATE.
            Regla de oro: sin Test fallido de origen → CREAR uno.
[Fase 3]    Regression Epic «QA Test Repository» (UPEX-9) encontrado.
            Plan: crear UPEX-540 «UPEX-101: TC2: should show auth error when
            password is incorrect» · links is tested by → UPEX-101, tests → UPEX-202
            · labels regression, automation-candidate, epic-UPEX-3. ¿Procedo?
> y
  Hecho. 1 Candidate · transiciones Draft→…→Candidate · caché test-cases/ escrito.

Cada regla del deck es visible aquí: preflight, resume, gate de modalidad, plan-first, lectura por sync script, grep de código, regla del bug previo, aritmética de ROI, regla de oro reuse-or-create, naming, parenting al Regression Epic, enlazado, labels y caché local — todo detrás de una confirmación antes de escribir.

cierre — dónde encaja y cómo se invoca

Deriva amplio · documenta lo repetible · automatiza los pocos

Cómo invocarlo

/test-documentation o frases naturales: «document tests», «ROI analysis», «which tests to automate», «Candidate vs Manual», «turn this bug into a regression test», «stage 4».

Handoffs en el pipeline

Entra desde /sprint-testing (Story QA Approved, bug cerrado). Sale hacia /test-automation, que re-alcanza los Candidates: module → Macro · ticket → Medium · bug → Micro (ad-hoc entra donde encaje). Manual y Deferred son terminales.

Artefactos que deja

TCs enlazados US↔ATP↔ATR↔TC en el TMS · Test Set / labels de feature · coverage matrix en .context/reports/ · un md por TC en test-cases/ · sesión archivada en .session/.archive/.

Las tres reglas para llevar

1. Por defecto, Deferred — 3 filtros + ROI = (F×I×S)/(E×D). 2. Una (precondición + acción) = un TC; los rasgos transversales viven dentro de los tests. 3. ATP → ATR → enlazar → TC, y un bug importante siempre termina con un Test.

Cierre: Stage 4 es el puente entre la QA manual (Stages 1-3) y la automatización (Stage 5). La IA acelera el oficio — el criterio y las confirmaciones siguen siendo del humano.

/test-documentation

Del comportamiento validado al repositorio de regression

Preflight Gate

Resume check

Modalidad TMS

Alcance

Analyze

Prioritize

Document

Archive

Nada se documenta sin pasar los gates

Prerrequisito duro

Preflight Gate

Fase -1 · Resume check

El caso de resume que más importa

¿Xray licenciado? Mismos conceptos, distintos contenedores

Config

Master Test Plan

Issue types

Preguntar

Cuatro alcances, un solo pipeline

Al confirmar el alcance, la IA escribe el plan

Un bug importante DEBE terminar con un Test

¿Es candidato de regression?

¿Vino de un Test ya ejecutado que falló?

Anula «el bug es el test case»

Nunca reabras un bug cerrado (D8)

Reúne las fuentes — y luego lee el código

Validación contra código fuente — obligatoria antes de documentar

Una (Precondición + Acción) = un TC

✓ MISMO TC — 5 aserciones

✓ TC DISTINTOS — la precondición difiere

Un AC → N candidatos, elegidos por la forma del AC

Candidatos ≠ items del TMS

Improvement bridge

Tres filtros, luego la fórmula

¿Protege contra regressions futuras?

¿Bugs previos en esta área?

¿Nivel de app o de feature?

Falla cualquier filtro → Deferred

Candidate · Manual · Deferred — la modalidad cambia el verbo

Tres capas, tres conteos — la forma saludable

Epic · Test Set · Test Plan — tres cosas distintas

Regression Epic

Test Set solo xray

Test Plan

Modelo de tres ejes (defect-management-doctrine.md)

ATP → ATR → enlazar → recién entonces cada TC

Crear TCs primero = huérfanos

Crear los TCs — matriz por modalidad

La regla de las dos llamadas de Xray

Anti-patrones D1 · D6

Gherkin de alta calidad: variables, nunca datos duros

Cómo un TC recorre su vida — sin saltarse estados

El hilo principal decide; los subagentes escriben

Inline (orquestador)

Paralelo (Fase 3, N > 10)

Error protocol

Una corrida de documentación, de punta a punta

Deriva amplio · documenta lo repetible · automatiza los pocos

Cómo invocarlo

Handoffs en el pipeline

Artefactos que deja

Las tres reglas para llevar