AGENTIC QA · WORKFLOW SKILL
Ejecuta la suite en CI, clasifica cada fallo con evidencia y convierte el resultado en un veredicto de release defendible: GO / CAUTION / NO-GO.
→ avanzar · O overview · S presentador · N notas · F pantalla completa
mapa completo — este es el índice del deck
antes de todo · preflight gate (obligatorio)
| Capacidad | Nivel | Por qué aquí |
|---|---|---|
| gh CLI autenticado | REQUIRED | Todo el pipeline vive en gh: trigger, watch, download. Sin auth → STOP, el usuario corre gh auth login. |
| Workflow files | REQUIRED | .github/workflows/ debe tener el YAML de la suite elegida con sus inputs. |
| GitHub Actions Secrets | REQUIRED | El runner usa secrets.<ENV>_USER_EMAIL/_PASSWORD + XRAY_*/ATLASSIAN_*. Verificar con gh secret list — el gap silencioso más común. |
| Allure 3 local | REQUIRED | bunx allure resuelve (devDep, sin install global) + allurerc.mjs presente para bun allure:agent. |
| Env activo confirmado | REQUIRED | Confirmar el target antes de un run de 20–60 min (default: staging). |
| [TMS_TOOL] · [ISSUE_TRACKER_TOOL] | OPTIONAL | /xray-cli solo si hay sync TMS; /acli solo si el veredicto obliga a abrir issues. |
args-as-answers — suite, env y grep/test_file ya vienen como argumentos: pregunta solo los huecos. probe, don't assume — cada capacidad se prueba con un comando real. Gaps + REDs se presentan en UNA checklist; cualquier RED bloqueante → STOP.
phase 0 · session resume check (obligatorio, inline)
Scope = <env>-<YYYY-MM-DD> (ej. staging-2026-07-06). Estado en .session/regression-testing/<scope>/{plan.md, progress.md}. Si progress.md no existe → sesión nueva. Si existe → ofrecer resume / restart / abort (restart archiva primero).
Si el Monitor murió a mitad del watch pero plan.md ya capturó el RUN_ID, la skill se re-engancha al run vivo en lugar de re-disparar el CI — ahorra 20–60 min de reloj.
# progress.md dice "Phase 1.Trigger completed" pero el Monitor no reportó: $ gh run view <RUN_ID> --json status,conclusion { "status": "in_progress" } → re-atacharse al watch, NO re-disparar
fase 1 · execute — elegir la suite
| Suite | Workflow | Duración | Usar cuando |
|---|---|---|---|
| regression | regression.yml | 20–60 min | Validación pre-release, corrida nocturna completa |
| smoke | smoke.yml | 2–5 min | Health check post-deploy, solo tests @critical |
| sanity | sanity.yml | 1–10 min | Una feature / un archivo / un patrón grep |
"run regression" pelado → regression en el env por defecto · "smoke" o "critical only" → smoke · un archivo o grep → sanity.
En sanity, grep y test_file son mutuamente excluyentes — pasar ambos hace que el workflow ignore uno en silencio. Elige uno.
fase 1 · execute — plan, trigger, RUN_ID
# 1 · preflight de fase (siempre) $ gh auth status && gh repo view --json name,owner && gh workflow list # 2 · escribir .session/regression-testing/<scope>/plan.md ANTES del trigger # 3 · disparar la suite con inputs explícitos $ gh workflow run regression.yml -f environment=staging -f video_record=false -f generate_allure=true # sanity: grep O test_file — nunca ambos $ gh workflow run sanity.yml -f environment=staging -f test_type=e2e -f grep="@auth" # 4 · capturar RUN_ID (esperar 3–5s: el run no es consultable al instante) $ RUN_ID=$(gh run list --workflow=regression.yml --limit=1 --json databaseId -q '.[0].databaseId')
El RUN_ID se añade a plan.md §Inputs + entrada en progress.md. Trigger sin RUN_ID persistido = resume sin re-attach.
Nunca disparar sin --ref <commit-sha> fijado — commit distinto = baseline distinta. Y el video (video_record=true) infla artefactos 5–10×: solo para debug.
fase 1 · execute — monitor (dispatch background)
$ gh run watch <RUN_ID> --exit-status # fallback si watch expira en suites largas: poll cada 60–90s $ gh run view <RUN_ID> --json status,conclusion status: queued | in_progress | completed conclusion: success | failure | cancelled | timed_out (solo al completar)
fase 2 · analyze — collect (dispatch parallel ×3)
# inline (hilo principal): contexto + SOLO logs fallidos (--log completo puede pasar 50MB) $ gh run view <RUN_ID> --log-failed # tres subagentes en paralelo, uno por artefacto (cap = 3) $ gh run download <RUN_ID> -n merged-allure-results-staging -D ./analysis/ # A $ gh run download <RUN_ID> -n e2e-failure-evidence -D ./analysis/evidence/ # B $ gh run download <RUN_ID> -n e2e-playwright-report -D ./analysis/playwright/ # C # run anterior → baseline de tendencia $ PREV=$(gh run list --workflow=regression.yml --limit=2 --json databaseId -q '.[1].databaseId') $ gh run download $PREV -n merged-allure-results-staging -D ./analysis/previous/
Nunca saltes la descarga de Allure en builds rojos — screenshots, traces y videos desaparecen al vencer la ventana de retención. Evidencia primero, análisis después.
fase 2 · analyze — parse + métricas
| Métrica | Fórmula |
|---|---|
| Pass Rate | Passed / Total × 100 |
| Pass Rate (gating) | sobre Total − KNOWN-BLOCKED |
| Duración | max(stop) − min(start) |
| Trend | pass rate actual − run previo |
Allure results JSON > Playwright report.json > logs crudos. Cada resultado trae status, statusDetails y labels[] (testId = ATC ID, suite, severity).
@smoke/@regression/@e2e/@integration/@critical es la única taxonomía: el suite que lees ES el scope que CI corrió. Nunca reconcilies contra otro set de labels.
CI corre con retries: 2 — un test que pasa al reintentar sigue siendo flaky. Inspecciona el conteo de retries en Allure, no solo el status final (anti-patrón R3: el reporte debe exponer los retries).
fase 2 · analyze — clasificar cada fallo (6 vías)
Test fallido ├─ ¿tag @blocked:{BUG-KEY}? ──────────────► KNOWN-BLOCKED (aparcado; fuera del gating) ├─ ¿un ticket conocido ya lo rastrea? ────► KNOWN ISSUE ├─ ¿patrón de error de entorno? ──────────► ENVIRONMENT │ ECONNREFUSED · ETIMEDOUT · net::ERR_ · Navigation timeout · browserType.launch · 502/503 ├─ ¿sin historial (primer run)? ──────────► NEW TEST ├─ ¿falla >20% en los últimos 10 runs? ───► FLAKY └─ ¿pasaba hace ≤5 runs y ahora falla? ───► REGRESSION ← bloquea el release
NUNCA marques REGRESSION sin revisar el historial primero. Y un primer fallo sin historia no es regresión: es NEW TEST — se verifica a mano una vez antes de clasificar.
>10 fallos → chunks de ~10 con un subagente clasificador por chunk (cap 10), merge de JSONs en el hilo principal. ≤10 → inline: el overhead no se justifica.
fase 2 · analyze — de la etiqueta a la acción
| Categoría | Impacto | Acción | ¿Issue en Jira? |
|---|---|---|---|
| KNOWN-BLOCKED | LOW | Excluir del gating, listar con su {BUG-KEY} | No — el marker ya nombra el bug abierto |
| REGRESSION | HIGH | Bloquea el release, archivar y asignar | Sí — Bug/Defect (Fase 3) |
| FLAKY | MEDIUM | Agendar estabilización, no bloquea | No |
| KNOWN ISSUE | LOW | Documentar contra el ticket existente | No |
| ENVIRONMENT | MEDIUM | Re-run tras revisar la infra | No |
| NEW TEST | LOW | Verificación manual primero | Solo si se confirma defecto real |
ECONNREFUSED a tu propia API suele significar que la app se cayó. Muchos tests sin relación rojos en el mismo host → ENVIRONMENT; UN test fallando en un endpoint que otros usan bien → probable REGRESSION disfrazada.
Solo en suites integration-trunk: un rojo clase ENVIRONMENT en Sanity-CI puede autorizar merge al trunk de integración (nunca al PR final a main) si el cambio pasó en local + staging y el rojo existe sin el cambio. REGRESSION jamás califica.
fase 2 · analyze — severidad por fallo
Un test FLAKY sobre el checkout sigue siendo CRITICAL. La clasificación responde por qué falló; la severidad, cuánto nos importa.
| Severidad | Criterio |
|---|---|
| CRITICAL | Flujo central del usuario (login, checkout, payment) — o cualquier test con tag @critical |
| HIGH | Feature mayor (search, profile, dashboard) |
| MEDIUM | Feature secundaria (filtros, preferencias) |
| LOW | Edge case o ruta solo-admin |
Bloque de análisis: tabla de métricas + delta de tendencia, una sección por categoría (Regressions primero), detalle por test fallido (nombre, ATC ID, suite, error, last-pass, screenshot) y un veredicto preliminar.
fase 3 · report & decide — el score de 9 puntos
| Factor | +3 | +1 | 0 | −1 | −2 | −3 |
|---|---|---|---|---|---|---|
| Pass Rate | ≥95% | 90–95% | — | — | <90% | — |
| Regressions | 0 | 1–2 Low | — | 1+ Medium | — | High/Critical |
| Tests @critical | Todos pasan | — | — | — | — | Cualquier fallo |
| Flaky | — | ≤3 | 4–5 | >5 | — | — |
Release aprobado; smoke post-deploy agendado.
Revisión manual; riesgos aceptados documentados.
Release bloqueado; fix + re-run planificados.
(1) falla cualquier test @critical · (2) existe cualquier REGRESSION HIGH/CRITICAL · (3) pass rate < 90%. Anulan cualquier score. R2: el gate es binario — REGRESSION conocida > 0 = no hay GO. R6: nunca mezclar smoke + regression en un solo pass-rate.
fase 3 · report & decide — archivar defectos (NO-GO / CAUTION con regressions)
Solo REGRESSION y NEW TEST confirmado llegan a Jira. Tipo según el ciclo de vida de la FEATURE, no dónde falló: ya live sobre Staging → Bug · pre-release → Defect · comportamiento deseable más allá del AC → Improvement.
severity → priority auto-derivada · components = módulo afectado · root_cause + error_type + test_environment · qa_assignee = uno mismo (read-before-write) · evidence = link Allure + ./analysis/evidence/.
Parent = epic QA Defect Management (nunca un epic de producto) · issue-link causal → la Story que cubre el ATC regresionado · components = módulo de producto.
Cargar /acli primero (auth + sintaxis). Crear con acli workitem create --from-json; customfields sobre issue existente vía REST PUT /rest/api/3/issue/{KEY}. Filing gate de la doctrina antes de enviar; guardar la key para el reporte.
agentic-qa-core/references/defect-management-doctrine.md — la misma autoridad que usa /sprint-testing. FLAKY, ENVIRONMENT y KNOWN ISSUE nunca generan bug nuevo.
fase 3 · report & decide — reporte, TMS sync, archive
# Regression Quality Report — staging — 2026-07-06 ## Executive Summary Verdict + score/9 + 1 línea ## Metrics Pass Rate·Regressions·Critical·Flaky vs umbral ## Release Blockers si NO-GO: regressions + owner + ETA ## Failure Details Regressions → Flaky → Known → Blocked → Env ## Trend últimos 5 runs · ## Links · ## Recommendations
STP = Test Plan STP: Sprint#{N}: Regression → epic QA Master Test Plan · STR = Test Execution STR: Sprint#{N}: Regression Testing → epic QA Test Artifacts. El update de resultados por ATC apunta al STR, vía /xray-cli (o /acli en jira-native).
GO → candidato aprobado + smoke post-deploy · CAUTION → revisión con el lead, riesgos por escrito · NO-GO → bloquear, asignar issues, planificar re-run.
Tras el veredicto: .session/…/<scope>/ → .session/.archive/ + resumen a memoria. Con NO-GO, el archive espera a que termine la creación de issues.
cierre — cómo se invoca y qué sigue
/regression-testing — o "run regression", "smoke suite", "analyze test results", "GO/NO-GO decision", "release readiness", "quality report".
Entra desde /test-automation (Stage 5: escribe los tests y el marker @blocked). Sale hacia /sprint-testing (verificar el fix a mano) y de vuelta a /test-automation (estabilizar flaky, nuevos tests).
plan.md + progress.md (sesión) · ./analysis/ (artefactos CI) · .context/reports/regression-<env>-<date>.md · issues Jira (Bug/Defect) · STP/STR en el TMS.
references/failure-classification.md (catálogo de patrones de error) · references/ci-cd-integration.md (workflows, sharding, secrets) · references/github-pages-setup.md (publicar los reportes Allure — correr antes el version-currency check).
Clasifica con honestidad, respeta los vetos, y el veredicto no lo discute nadie.