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 · Sprint-wide 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 Sprint-wide «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 · ATS + 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-issue — User Story	Un ID de Story en Ready For QA	ATS + ATP + ATR + QA comment · ticket transicionado a QA approved · TC outlines (native) o Tests agrupados en el ATS y ejecutados (xray)
Single-issue — Bug	Un ID de Bug con fix en staging	Decisión de triage → solo Code Review, O verificación completa con ATP + ATR (xray: 1 Test de repro en-sprint · native: sin TCs, difiere a Stage 4)
Sprint-wide	Un número de sprint («process sprint 5») → JQL construido con los work types coverable que el proyecto declara	Artefactos por issue + STP actualizado en Jira + resumen · con soporte de interrupción y resume

Regla de selección

Story → story run · Bug → bug run · «process sprint 5» → sprint-wide. El alcance del sprint no es una lista fija de tipos: sale de una JQL construida con los work types coverable que el proyecto declara, resolviendo las alternativas A | B | C e intersectando con lo que la instancia realmente tiene. Un tipo declarado que la instancia no tiene se salta con una nota, nunca bloquea.

Misma cadencia siempre

Ambos modos pagan los mismos 4 despachos por issue: Session Start → Stage 1 → 2 → 3. Sprint-wide solo los repite por issue.

No hay un camino "inline" para un solo issue: single-issue y sprint-wide corren la misma secuencia de 4 subagentes para que el comportamiento sea uniforme y auditable. Se dice "issue" y no "story" porque bugs, defects, tech debt e improvements también son coverables.

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 (sprint-wide).
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 sprint-wide corre una vez por issue 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 test-session-memory.md ↑ payload de dominio compartido entre los 4 subagentes .context/PBI/.../STORY-<KEY>-<slug>/ context.md · evidence/ ← lo local del ticket

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. Las dos viven en .session/, nunca en la carpeta PBI: un re-sync del cache PBI destruiría el archivo.

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, ATR = Test Execution y ATS = Test Set per-Story (tercer artefacto canónico); el custom field de la Story es solo fallback.
STP find-or-create en el PRIMER ticket del sprint: STP: Sprint#{N}: {objetivo} — planificador vivo que cada ticket testeado actualiza (scope, progreso).
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 evidence/ ← capturas .session/sprint-testing/<scope>/ test-session-memory.md ← a mano

⏸ El gate del hand-off (S10). Escribe la Story Explanation en lenguaje llano y SE DETIENE: nada transiciona a In Test 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 (context.md + evidence/), escribe el plan.md y el test-session-memory.md de sesión bajo .session/, 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	Orden Set-first (xray): ATS: {KEY}: {título} (Test Set → epic QA Test Artifacts, components de la Story) con TODOS los TCs → ATP: {KEY}: {título} (Test Plan → epic QA Master Test Plan, creado desde el field del shift-left) → ATR: {KEY}: Story Testing (Test Execution → epic QA Test Artifacts) SIEMPRE con Test Environment (active_env) · listas de Plan/Exec derivadas de la membership del ATS

Verificación de traza antes de tocar un browser (Gotcha 9). El link ATS ↔ Story («is tested by») es el que llena el panel de coverage — verificado live. Los links ATP ↔ Story y ATR ↔ Story son administrativos: cero coverage. Cascade de resolución: TC → ATS → Story (primaria) · TC → ATP → Story (placement, sin coverage) · TC → Story directo (last resort) · si nada: orphan.

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, agrupados en el ATS (Test Set per-Story) y ejecutados 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 de retest. jira-xray: 1 Test de repro creado en-sprint al verificar el fix (1:N si el scope lo justifica), ejecutado en la Execution ReTest:. jira-native: sin TCs en el sprint — difiere a Stage 4, como siempre. 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 de repro 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 sprint-wide · procesar el sprint entero

El plan es local, el estado vive en Jira

El alcance sale de una JQL construida con los work types coverable que declara el proyecto — no de una lista fija de tipos.
Local: el par de sesión de siempre en .session/sprint-testing/sprint-<N>/ — plan.md (scope, waves, asignación) y progress.md (append-only, una entrada por issue cerrado).
Loop: primer issue PENDING de Wave 1 → los mismos 4 despachos → resumen por issue → tu OK para el siguiente.
STOP en TOOL FAILURE · ⏸ en BUG_FOUND bloqueante.
Cierre del sprint: se crea el STR: Sprint#{N}: Regression Testing como recap de resultados y el STP se cierra.

El estado que ve el equipo = el STP

La descripción del STP lleva el plan estable (un solo escritor, read-first); los comentarios llevan el progreso append-only, uno por issue cerrado. Si el log de comentarios y el ATR de una Story se contradicen, manda el ATR.

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 STP en Jira quedan: son los entregables.

El par plan.md + progress.md es el mismo convenio que ya usan otras seis skills — andamiaje local, no entregable: nunca viaja a otra máquina. Lo que el equipo consulta es el STP en Jira. Phase 0 corre por issue dentro del loop, así el resume de un sprint interrumpido es fino: retoma el issue 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

ATS + ATP + ATR en Jira · QA comment · ticket transicionado · bugs clasificados y linkeados · carpeta PBI con context.md y evidence/ · test-session-memory.md en .session/sprint-testing/<scope>/ · 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ó: la cascade TC→ATS→Story (el link ATS↔Story es el coverage; ATP/ATR son administrativos).

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.