AGENTIC QA · WORKFLOW SKILL

/sprint-testing

QA manual por ticket dentro del sprint: Planning → Execution → Reporting, con gates humanos en cada checkpoint.

Stages 1-3 del pipeline QA Story · Bug · Batch sprint Jira = fuente de verdad

Deck del skill /sprint-testing: cómo la IA conduce el QA manual de un ticket durante el sprint. → para avanzar, S modo presentador, O overview, F pantalla completa.

El mapa completo · índice del deck

Un pipeline, gates en cada paso

Entrada Story en Ready For QA Bug desplegado en staging Batch «process sprint N» ← viene de /shift-left-testing (label shift-left-reviewed acorta el Planning)

Gate 0

Preflight

Probar env, creds, tools, TMS

RED bloqueante → STOP

→

Phase 0

Resume

Lee progress.md

resume / restart / abort

→

Entry

Session Start

Sync ticket · carpeta PBI · plan

⏸ explica la Story y ESPERA tu OK

→

Stage 1

Planning

Triage · doctrina · ATP + ATR

bug: veto SKIP → solo Code Review

→

Stage 2

Execution

Smoke · trifuerza UI/API/DB

smoke No-Go → STOP · bug bloqueante → ⏸

→

Stage 3

Reporting

ATR · QA comment · transición

bug solo con tu confirmación

Salida

Tres formas de entrar, el mismo pipeline

Modo	Entra	Sale
Single — User Story	Un ID de Story en Ready For QA	ATP + ATR + QA comment · ticket transicionado a QA approved · TC outlines (native) o Tests ejecutados (xray)
Single — Bug	Un ID de Bug con fix en staging	Decisión de triage → solo Code Review, O verificación completa con ATP + ATR (sin TCs en el sprint)
Batch sprint	El framework SPRINT-N-TESTING.md	Artefactos por ticket + framework actualizado + resumen · con soporte de interrupción y resume

Regla de selección

Story → story run · Bug → bug run · «process sprint 5» → batch. Si el sprint file no existe, se genera primero desde el backlog del sprint.

Misma cadencia siempre

Ambos modos pagan los mismos 4 despachos por ticket: Session Start → Stage 1 → 2 → 3. Batch solo los repite por ticket.

No hay un camino "inline" para un solo ticket: single y batch corren la misma secuencia de 4 subagentes para que el comportamiento sea uniforme y auditable.

Gate 0 · corre ANTES que todo

Readiness Preflight — probar, no asumir

Ley 1 · args-as-answers

«QA UPEX-123 on staging» ya responde env y alcance. Solo se preguntan los huecos, en un único checklist.

Ley 2 · probe, don't assume

Un MCP configurado sigue en RED hasta que responde de verdad. Se sondea cada capacidad antes de usarla.

Capacidad	Sonda
Env alcanzable (REQUIRED)	curl -sI {{WEB_URL}} + API root — 2xx/3xx pasa; env muerto → STOP antes de escribir un solo plan
Credenciales + roles (REQUIRED)	.env por entorno · un token por rol vía bun run api:login
Jira + modalidad TMS (REQUIRED)	carga /acli · resuelve jira-xray vs jira-native · carga /xray-cli si aplica
Por superficie (según alcance)	OpenAPI MCP (solo schema) · DBHub MCP · Playwright · inbox que pueda recibir (magic-link)

Framework aún genérico (URLs null) → STOP: correr antes /project-discovery → /adapt-framework. Las superficies UI/API/DB las decide el triage de Stage 1, nunca se le preguntan al usuario.

El gate más pesado del repo porque Stage 2 ejercita UI + API + DB en vivo. Autorar un ATP contra un entorno muerto es el desperdicio más caro de un run — se atrapa aquí, a t=0.

Phase 0 · nunca empieces a ciegas

¿Ya había una sesión? — resume / restart / abort

Calcula el <scope>: UPEX-123 o sprint-7/UPEX-123 (batch).
Lee progress.md: última etapa completada, BUG_FOUND o TOOL FAILURE pendientes.
Ofrece resume / restart / abort — en restart, primero archiva la sesión abortada.
En batch corre una vez por ticket al entrar al loop, no una vez por sprint.

.session/sprint-testing/<scope>/ plan.md ← índice de la sesión progress.md ← checkpoint por etapa .context/PBI/.../STORY-<KEY>-<slug>/ test-session-memory.md ↑ payload de dominio compartido entre los 4 subagentes

Dos memorias, dos preguntas. progress.md decide «¿qué etapa sigue?» · test-session-memory.md lleva la modalidad TMS + contexto del ticket que cada subagente lee. Ambas se consultan al retomar.

El contrato de resume viene de session-management.md §4. Interrumpir una sesión no pierde nada: el próximo run detecta el estado y retoma exactamente donde quedó.

Entrada universal · prepara la mesa

Session Start — sync, contexto, carpeta PBI

Resuelve la modalidad TMS. Por excelencia ATP = issue Test Plan y ATR = Test Execution; el custom field de la Story es solo fallback.
Trae el ticket: bun run jira:sync-issues get <KEY> --include-comments → lee los .md sincronizados. NUNCA acli view para custom fields (devuelve null).
Extrae el Team Discussion de comments.md: decisiones, edge cases, bloqueos.
Carga contexto + código: business maps, master test plan, repos backend/frontend, datos candidatos vía DBHub.

.context/PBI/epics/EPIC-<KEY>-<slug>/ stories/STORY-<KEY>-<slug>/ story.md, acceptance-criteria.md [SYNC] acceptance-test-plan.md [SYNC] context.md ← a mano test-session-memory.md ← a mano evidence/ ← capturas

⏸ El gate del hand-off (S10). Escribe la Story Explanation en lenguaje llano y SE DETIENE: nada transiciona a In Testing sin tu OK explícito. Carpeta PBI nueva por ticket, nunca reusada (S9); los [SYNC] jamás se escriben a mano (S14).

Session Start es una puerta, no una formalidad: sincroniza el ticket, arma la carpeta PBI con los dos archivos hand-authored, escribe el plan.md de sesión, explica la Story y espera confirmación humana antes de continuar.

Stage 1 · Planning — de los ACs a un plan ejecutable

Siete fases, del triage al ATP en Jira

Fase	Qué produce
0 · Triage	Short-circuit si hay label shift-left-reviewed <30 días (salta fases 1-3) · veto · risk score · factibilidad de datos: Discover / Modify / Generate por AC
1-2 · Análisis	Contexto de negocio + técnico · ambigüedades y gaps marcados NEEDS PO/DEV CONFIRMATION
3 · ACs refinadas	Cada AC reescrita Given/When/Then con datos específicos
4-5 · Test outlines	Derivación por técnica (1:N) · nombre Should <BEHAVIOR> <CONDITION> · edge cases + estrategia de datos
6 · Trazabilidad	ATP + ATR creados en Jira: ATP: {KEY}: {título} (Test Plan → epic QA Master Test Plan) · ATR: {KEY}: Story Testing (Test Execution → epic QA Test Artifacts)

Verificación de traza antes de tocar un browser (Gotcha 9). Story ↔ ATP y Story ↔ ATR («is tested by») · cada TC ↔ ATP (designed-by) y TC ↔ ATR (executed-by). Los TCs NO se linkean directo a la Story — agregan vía ATP/ATR.

El ATP es la spec del testing. Vive en Jira (S14): se escribe en el issue Test Plan (o en el custom field como fallback), se sincroniza hacia abajo y se relee — nunca se autora el .md local a mano.

Stage 1 · la doctrina que gobierna el plan

Verificar ACs es el piso, no el testing

Piso, no techo

Cobertura = conformidad-AC + riesgo más allá del AC (límites, errores, estados, anomalías). Nunca reportar «% de ACs verificados» como completitud.

1 : N por defecto

Cada AC no trivial explota en varios casos. Colapsar a uno exige justificación escrita trivially atomic.

Criterio ≠ caso

Un criterio es una afirmación de negocio; un caso es una exploración concreta de cómo se cumple o se rompe.

Disparador en el AC	Técnica obligatoria
Cualquier input — siempre	Equivalence Partitioning · un caso por clase válida + inválida
Rango / límite / longitud / ventana de fecha	BVA · min−1 · min · min+1 … max−1 · max · max+1 · cero/vacío/null
Campo de estado / ciclo de vida	State-Transition · cada transición válida + cada inválida
2+ condiciones que interactúan · 3+ factores	Decision Table · Pairwise (registrando la reducción) · charters de Error-Guessing

Canon: agentic-qa-core/references/test-design-doctrine.md — carga obligatoria antes de derivar cobertura. EP sin BVA pierde el off-by-one; un campo de estado sin transición inválida es un plan incompleto.

Stage 1 · la regla que define la forma del skill

¿Cuándo un TC se vuelve work item?

	Modality jira-native	Modality jira-xray (bun xray)
Stage 1	Solo outlines en el ATP (nombre + 1 línea). Sin issues Test: un Test nativo es documentación y espera al gate de Stage 4.	Crea + ejecuta issues Test para los outlines, a detalle ejecutable, vía un Test Execution — el Test ES la unidad de ejecución de Xray.
Stage 2	Corre los outlines + explora más allá; PASS/FAIL en la memoria de sesión.	Ejecuta los Tests + explora. Una sonda exploratoria se vuelve Test solo si halló un defecto o vale repetirla.
Stage 4	Crea Tests solo para lo regression-worthy, tras el ROI.	Selecciona + promueve al Regression Test Plan + Test Set, y los enriquece.

Pregunta única por batch (xray)

Antes de crear los Tests: ¿formato Manual o Gherkin/Cucumber? Se sugiere (Gherkin si es candidato a automatizar), tú eliges, y aplica a todo el batch.

Manual = creación en dos pasos

Xray Cloud descarta en silencio los steps inline: crear el Test sin steps y agregarlos uno a uno vía Add Test Step.

Principio rector: un test se persiste al repositorio de REGRESIÓN porque se va a re-ejecutar, nunca para inflar un conteo. El artefacto de ejecución del sprint no es el repositorio curado — ese lo decide el ROI en Stage 4.

Stage 1 · rama Bug — triage antes que plan

El veto le gana al risk score, siempre

Veredicto	Disparadores
SKIP — solo Code Review	texto/label puro, CSS/visual, docs, config/infra, refactor sin cambio de comportamiento — Stages 2-3 colapsan al comentario + transición
REQUIRE — test completo	dinero/billing, integridad de datos, auth/autorización, integraciones externas, máquinas de estado, cálculos — sin importar el score

Sin veto → risk score

Feature nueva +3 · datos dinámicos +3 · ACs explícitas +2 · user-facing +2 · esfuerzo >4h +2 · prioridad alta +1 · multi-componente +1 → 0-3 LOW (Code Review) · 4-7 MEDIUM (ATP completo) · 8+ HIGH (ATP + edges extendidos). El resultado se presenta al usuario.

Reglas del bug run

ATP + ATR pero sin TCs en el sprint: el bug ES el retest inmediato. Ejecuta: reproducir el original → verificar el fix → regresión en áreas adyacentes → DB si es de integridad. Regla de oro: si amerita regresión, Stage 4 termina con un Test persistente — reusar el fallido o crear uno.

Anti-patrón S5: ninguna falla se salta el árbol veto → risk-score → severidad + root cause. Un typo hardcodeado hace SKIP; cualquier cosa que toque dinero, datos o auth se prueba aunque el diff luzca trivial.

Stage 2 · Execution — primera acción obligatoria

Smoke test: una puerta Go / No-Go de ≤10 min

Acceso básico. La app carga, sin 500, consola sin errores rojos.
Authentication. Login, la sesión persiste al refrescar, logout.
Happy path. El flujo primario del ticket de punta a punta.
Integración backend. Llamadas /api/* en 2xx; los datos persisten tras F5.

Veredicto

PASS → continuar a la trifuerza · FAIL → STOP: blocker de nivel entorno, se reporta y no se explora nada.

Reachability ≠ smoke (S7)

El preflight preguntó «¿está levantado el env?»; el smoke pregunta «¿funciona la feature?». Ambos corren — saltarse el smoke produce bugs falso-positivo contra un entorno roto.

Sin edge cases, sin bugs menores, no más de 10 minutos. El smoke valida el entorno de la feature; la trifuerza valida la feature.

Stage 2 · exploración por capas

La trifuerza: UI · API · DB

playwright-cli — happy path + edges: vacío, largo máximo, 0/−1/MAX_INT, <script>, refresh a mitad de flujo, botón atrás. Screenshot en el estado FALLIDO, a evidence/ (configurar outputDir antes).

API

Maniobra de 3 herramientas: OpenAPI MCP solo schema → bun run api:login → curl autenticado. Matriz de status: 200 happy · 400 campo faltante · 401 sin auth · 403 otro tenant · 409 duplicado.

DBHub MCP — filas persistidas, triggers (total == SUM de items), sondas de constraint FK/CHECK/UNIQUE envueltas en transacción + ROLLBACK.

Orden según la feature

UI-céntrica: UI→API→DB · API-first: API→DB→UI · data-céntrica: DB→API→UI. Un no-2xx en la UI te escala a la capa API; datos raros en pantalla te mandan a la DB.

Sonda RLS (multi-tenant)

Con A y B del mismo rol: ¿A lista/lee/edita datos de B? Cualquier VULNERABLE = Critical y BLOQUEANTE — los bugs de autorización nunca afloran en el happy path.

Nunca ejecutar requests autenticadas por el OpenAPI MCP — es de lectura de schema. El token se acuña con api:login a .auth/tokens.env y se ejecuta con curl. Explorar SIEMPRE más allá de los outlines planeados.

Stage 2 · pausa graduada

Un FAIL no es auto-Critical — triage primero

Clase	Ejemplos	Acción
BLOCKING	smoke/env caído · corrupción de datos · explotable en seguridad (auth bypass, cross-tenant)	⏸ pausa YA — se presenta el bug y se espera tu decisión; no se despacha la siguiente etapa
NON-BLOCKING	cosmético · gap menor de validación · edge en TC no crítico · default de framework por recalibrar	se registra, TC FAILED, y se terminan los TCs restantes — todo se lleva al cierre de Stage 2
TOOL FAILURE	cualquier herramienta rota a mitad del pase	STOP — estado parcial reportado, tú eliges retry / skip / abort

Casos dependientes del tiempo

TTL, magic links, OTPs: elegir la opción más alta — TTL corto de test → clock-mock → defer explícito documentado. Nunca un «BLOCKED» a secas: al cierre todo TC está PASSED o FAILED.

Evidencia

Capturas, traces y logs bajo evidence/ del ticket (gitignored). Se captura el bug, no la navegación hacia él.

Esta regla protege la cobertura: pausar un pase de 17 TCs por un hallazgo cosmético desperdicia el run; un blocker genuino sí detiene al instante.

Stage 3 · Reporting — el veredicto auditable

ATR → QA comment → transición, en ese orden

Resultado	QA comment	Transición
Story PASSED	Template A	→ QA approved (vía qa_sign_off)
Story FAILED (defecto confirmado)	Template B + reporte de bug	→ blocked (+ issuelink is blocked by), o queda in_test con el bug linkeado
Bug VERIFIED	Template C	→ closed (vía retest_passed)
Bug NOT FIXED	Template D	queda ready_for_qa, se etiqueta al dev

ATR por modalidad

jira-xray: actualizar la descripción del Test Execution + status de cada Test Run. jira-native: custom field acceptance_test_results (o comentario fallback) → sync → releer. Sin snapshot de ATR no se reporta nada (S3).

Recalibración de severidad (§5.0)

FAIL de seguridad/auth que huele a default de framework (cookie flags, CSP/HSTS): hipótesis + un hecho de verificación + decisión humana → PASSED WITH ISSUES (GO-con-deuda), no un blocker.

El QA comment es un resumen; el ATR es el registro de auditoría — nunca duplicarlo en un segundo store (S4). Resultados mixtos usan PASSED WITH ISSUES y aún entregan los TCs en pass a Stage 4.

Stage 3 · doctrina de defect management

Clasifica antes de reportar — Bug ≠ Defect ≠ Improvement

Bug

La feature ya vive arriba de Staging (visible al usuario final).

Defect

Feature aún pre-release — la salida normal del sprint testing.

Improvement

No es un AC roto: mejora o AC sub-especificada hallada probando más allá.

Tres ejes, nunca mezclados

parent = epic de proceso «QA Defect Management» (jamás un epic de producto) · issue link = la Story origen · components = módulo de producto afectado. qa_assignee = tú mismo, nunca sobrescribiendo un owner existente.

Severidad → prioridad (lookup)

Critical→Highest · Major→High · Moderate→Medium · Minor→Low · Trivial→Lowest. Título: <EPIC>: <COMPONENT>: <resumen>.

Disciplina. Repro reproducible + evidencia o no hay ticket (S12) · una capa por bug, nunca UI+API+DB mezclados (S8) · buscar duplicados primero · borrador completo a la vista y tu confirmación antes de crear nada.

Canon: agentic-qa-core/references/defect-management-doctrine.md — carga obligatoria antes de reportar. La clasificación sigue el ciclo de vida de la FEATURE, no dónde se encontró el problema.

Modo batch · procesar el sprint entero

Un framework file conduce el loop

SPRINT-N-TESTING.md se genera del backlog si falta; se regenera si tiene >24h (con confirmación).
Loop: primer ticket PENDING de Wave 1 → los mismos 4 despachos → resumen por ticket → tu OK para el siguiente.
El framework file se actualiza SOLO después de que Stage 3 completa y verifica — nunca antes.
STOP en TOOL FAILURE · ⏸ en BUG_FOUND bloqueante.

Checkpoint por etapa (S11)

Tras cada subagente, el orquestador anota la etapa en progress.md — cada promote alimenta los Context docs del siguiente briefing.

Archive al cerrar

.session/… → .session/.archive/<fecha>-… + resumen a memoria persistente. Los artefactos PBI y el framework file quedan: son los entregables.

Phase 0 corre por ticket dentro del loop, así el resume de un sprint interrumpido es fino: retoma el ticket exacto y la etapa exacta.

Cómo lo invocas · lenguaje natural

Describe la tarea — la skill resuelve el resto

> test this ticket UPEX-277 > QA this user story > retest bug UPEX-445 / verify bug fix > run exploratory testing > process sprint 5 > next ticket in sprint > resume sprint testing

Auto-cargado al arrancar

.agents/project.yaml · catálogos Jira (jira-required.yaml, fields, workflows) · business maps + master test plan · el ticket vía jira:sync-issues · .env · kata-manifest.json.

El humano conserva los juicios

OK de la Story · resultado del triage · confirmación de cada bug · retry/skip/abort en fallas. La IA teclea; tú decides.

No se pegan instrucciones: cualquier frase de la lista dispara el skill, que resuelve modo, contexto y herramientas con el orden de lectura fijo de la sección Inputs.

Para llevarte · handoffs y artefactos

Stages 1-3 listos — el pipeline continúa

Stage 4

/test-documentation — ROI + veredictos Candidate / Manual / Deferred; crea o promueve los Tests de regresión.

Stage 5

/test-automation — Plan → Code → Review sobre KATA + Playwright (chequea kata-manifest.json antes de proponer ATCs).

Stage 6

/regression-testing — suites en CI + veredicto GO / CAUTION / NO-GO.

Artefactos que deja un run

ATP + ATR en Jira · QA comment · ticket transicionado · bugs clasificados y linkeados · carpeta PBI con context.md, test-session-memory.md y evidence/ · sesión archivada.

Tres reglas de oro

1 El orden es ley: smoke antes de trifuerza, comment antes de transición. 2 Triage de todo: el veto gana, un FAIL no es auto-Critical. 3 Trazable o no ocurrió: Story↔ATP↔ATR↔TC.

Pruébalo: «test UPEX-277» · ← → navegar · S presentador · O overview

Cierre: apuntar a las etapas downstream e invitar a correr un ticket real. Todo el contenido proviene del SKILL.md actual de sprint-testing y sus references — nada inventado.