paulasilvatech ASP Personas del SDLC Agéntico v1.0.0
EN PT ES
13 quality · Verification

Ingeniero QA

Estrategia de tests y cobertura.

Actualizado: 2026-04-24 14 secciones Descargar .zip

El QA Engineer es la persona que diseña, ejecuta y evoluciona la estrategia de tests para todo el producto. En un SDLC AI-native, el QA Engineer opera un agente Test Strategist, un banco de slash prompts y un catálogo de MCPs validados — no una consola manual de tests.

Resumen ejecutivo

El QA Engineer es dueño de la fase de Verification. Su trabajo es probar que el código entregado por los Developers realmente satisface los requisitos EARS y los criterios de aceptación Given-When-Then bloqueados en SPECIFICATION.md. En un SDLC AI-native, esa prueba la produce un agente Test Strategist, cuatro slash prompts, instrucciones con alcance y un pequeño set de MCPs validados que llegan a Azure DevOps Test Plans, GitHub Actions y Playwright.

Las salidas principales son una matriz de tests viva, una suite con mutation testing, un registro de flakes con causas raíz y reportes de coverage gaps que se enrutan de regreso a los Developers como issues frescos. El QA Engineer no compite con los Developers en tests unitarios; orquesta el portafolio de verificación más amplio: integración, contrato, end-to-end, resiliencia y testing exploratorio asistido por IA.

El QA Engineer no reemplaza los tests unitarios escritos por los Developers; garantiza que la unión de todas las capas de verificación realmente demuestre que el producto cumple su contrato. Son el último defensor con principios del invariante: ningún comportamiento no documentado llega a producción.

Rol y responsabilidades

Piense en el QA Engineer como un ingeniero de pruebas de vuelo. Los pilotos vuelan, los mecánicos construyen, pero alguien tiene que diseñar el plan de expansión de envolvente que prueba que la aeronave es segura en cada régimen que verá. En un SDLC AI-native, el QA Engineer es responsable de la envolvente de evidencia automatizada y exploratoria que permite al equipo entregar cada día con confianza.

Responsabilidades principales:

  • Traducir cada requisito EARS en al menos un test ejecutable y un charter exploratorio manual
  • Ser dueño de la matriz de tests entre los carriles unit, contract, integration, end-to-end, performance y accessibility
  • Ejecutar mutation testing en módulos críticos y enrutar los survivors de regreso como issues
  • Hacer triage de tests flaky en 24 horas, nunca silenciarlos
  • Mantener los fixtures de Playwright MCP para cobertura end-to-end y visual
  • Operar el agente Test Strategist y los prompts /test-plan, /mutation-scan, /flake-triage, /coverage-gap
  • Publicar dashboards semanales de verificación desde datos de Azure Monitor y GitHub Actions
  • Acompañar a los Developers en el diseño de tests durante sesiones pair y reviews de PR

Jobs to be done

  1. Como QA Engineer, quiero un plan de tests generado para cada feature que enlace de regreso a IDs de spec, para que ningún criterio de aceptación llegue sin verificar.
  2. Como QA Engineer, quiero scores de mutation por módulo, para saber dónde las aserciones son débiles antes de que el incidente lo descubra.
  3. Como QA Engineer, quiero los tests flaky triagados dentro de un día laboral, para que la señal se mantenga confiable.
  4. Como QA Engineer, quiero los coverage gaps enrutados como issues con tests sugeridos, para que los Developers los cierren en el mismo sprint.
  5. Como QA Engineer, quiero que las ejecuciones de Playwright queden grabadas e indexadas, para que el análisis post-incidente sea una query, no una expedición arqueológica.
  6. Como QA Engineer, quiero la matriz de tests exportada a Azure DevOps Test Plans, para que stakeholders no técnicos puedan navegar la evidencia de verificación.
  7. Como QA Engineer, quiero chequeos de accesibilidad embebidos en cada ejecución end-to-end, para que las regresiones WCAG se atrapen en merge time.
  8. Como QA Engineer, quiero un resumen semanal publicado en Microsoft Teams, para que toda la organización vea las tendencias de calidad del producto.

Puntos de dolor antes de la era AI-native

  • Los tests van detrás de las features. QA escribe tests después de que el código se entrega; el alcance hace drift y las regresiones se filtran al backlog.
  • Amnesia de flakes. Los tests flaky se ponen en cuarentena y se olvidan. La misma race condition muerde dos veces por trimestre, y el equipo pierde confianza en builds rojos.
  • Teatro de coverage. Line coverage llega a 80 por ciento mientras ramas críticas nunca se ejercitan; las auditorías pasan y los incidentes siguen sucediendo.
  • Trabajo exploratorio sin documentar. Los charters viven en cuadernos; los aprendizajes nunca se vuelven regresión automatizada, así que el mismo bug regresa en otra pantalla.
  • Los hand-offs pierden contexto. El Developer arregla un bug, QA re-prueba, pero el escenario fallido que probó el fix no se adjunta al PR, así que la regresión futura queda desprotegida.
  • Sin dashboard compartido. El estado de verificación vive en cinco herramientas; el liderazgo no tiene una vista única y actual de la calidad del producto.

Flujo diario AI-native

El QA Engineer trabaja desde Visual Studio Code con GitHub Copilot y desde la terminal con Claude Code, invocando al agente Test Strategist a lo largo del día.

Setup de la mañana

  1. Hacer pull a main, abrir el repo en VS Code, dejar que Copilot Chat cargue AGENTS.md y el .github/instructions/tests.instructions.md con alcance.
  2. Ejecutar /test-plan --since=yesterday para escanear los PRs mergeados y producir un plan delta: qué nuevos requisitos EARS necesitan cobertura hoy.
  3. Abrir Azure DevOps Test Plans y los dashboards de GitHub Actions para revisar las ejecuciones nocturnas; encolar candidatos a flake.
  4. Revisar la salida del mutation scan nocturno publicada en el canal de Verification en Microsoft Teams; pinear los tres top survivors como prioridad del día.
  5. Sincronizar con el SRE de guardia por cualquier incidente de producción que deba alimentar un nuevo charter exploratorio.

Ejecución al mediodía

  1. Para cada PR de feature, invocar /test-plan con la sección de spec vinculada. El Test Strategist propone carriles faltantes y escribe esqueletos de tests.
  2. Ejecutar /mutation-scan en los módulos cambiados en las últimas 24 horas. Los survivors se vuelven issues con la etiqueta verification/weak-assertion.
  3. Conducir sesiones exploratorias con el Playwright MCP. Cada hallazgo que se reproduzca se vuelve un Playwright spec versionado.
  4. Hacer pair con el Developer en tests rojos; nunca aprobar un PR donde un test fue eliminado sin un reemplazo equivalente.

Revisión al final de la tarde

  1. Ejecutar /flake-triage contra los logs diarios de Actions. El agente agrupa fallas, propone causas raíz y abre issues con un sugerido owner del fix.
  2. Publicar el dashboard de verificación: cobertura por módulo, score de mutation, tasa de flake, charters exploratorios abiertos.
  3. Actualizar la trazabilidad de SPECIFICATION.md: cada ID de requisito se enlaza con al menos un test pasando.

Primitivas recomendadas

Agente

AgenteArchivoPropósito
test-strategist.github/agents/test-strategist.agent.mdDiseña planes de tests, ejecuta mutation scans, hace triage de flakes, enruta coverage gaps

El Test Strategist corre sobre claude-sonnet-4-6 con herramientas read, grep, bash, edit. El extended thinking está habilitado solo para análisis de mutation.

Slash prompts

ComandoArchivoPropósito
/test-plan.github/prompts/test-plan.prompt.mdGenerar o actualizar el plan de tests para una feature, vinculado a IDs EARS
/mutation-scan.github/prompts/mutation-scan.prompt.mdEjecutar mutation testing en módulos cambiados y enrutar survivors
/flake-triage.github/prompts/flake-triage.prompt.mdAgrupar ejecuciones fallidas de Actions, proponer causas raíz, abrir issues
/coverage-gap.github/prompts/coverage-gap.prompt.mdMapear ramas no probadas a secciones específicas de spec y sugerir tests

Instructions con alcance

Alcance (applyTo)ArchivoPropósito
tests/**/*.github/instructions/tests.instructions.mdPatrón AAA, fixtures determinísticos, sin sleeps escondidos
tests/e2e/**/*.github/instructions/playwright.instructions.mdLocators de Playwright, captura de trace, política de retry
docs/specs/**/*.md.github/instructions/traceability.instructions.mdCada requisito enlaza con al menos un ID de test

Hooks

  • pre-push: ejecutar el carril rápido de tests; bloquear el push en falla
  • post-merge: regenerar la matriz de tests y publicarla en Azure DevOps Test Plans
  • nightly: ejecutar el mutation scan en los módulos cambiados ese día
  • pre-release: aplicar umbrales mínimos de score de mutation y de cobertura de trazabilidad
  • on-flake: abrir un issue de GitHub automáticamente cuando un test falla dos veces en siete días

MCPs validados

MCPPropósitoDueño
GitHub MCP ServerLeer PRs, ejecuciones de Actions, anotar issuesGitHub
Azure DevOps MCP ServerSincronizar la matriz de tests en Azure DevOps Test PlansMicrosoft
Playwright MCPConducir sesiones exploratorias y ejecuciones end-to-end grabadasMicrosoft
Azure MCP ServerConsultar Azure Monitor y Application Insights por telemetría de fallasMicrosoft
Microsoft Learn Docs MCPBuscar guía actual de tests para servicios Azure bajo pruebaMicrosoft

Ejemplos reales

Ejemplo 1: los survivors de mutation se vuelven PRs

Ejecutar /mutation-scan src/billing/ regresa 7 survivors en invoice-total.ts. El Test Strategist redacta 7 nuevos casos de test y abre un único issue titulado verification/weak-assertion: billing invoice-total. Un Developer lo toma, escribe los tests y la próxima ejecución de mutation regresa cero survivors en ese módulo. El dashboard de KPI muestra el score de mutation del módulo subir de 58 a 94 por ciento.

Ejemplo 2: el triage de flake termina un bug de seis meses

/flake-triage agrupa 14 fallas en checkout.spec.ts de la última semana y apunta a una race entre un page.click de Playwright y una revalidación de caché en vuelo de Azure Front Door. El Test Strategist propone un fix: esperar la respuesta de red específica, no un timeout. El fix aterriza como un cambio de una línea, el test deja de ser flaky y el KPI de Reliability para esa suite vuelve a 99.8 por ciento.

Ejemplo 3: coverage gap enrutado de regreso al Developer

/coverage-gap inspecciona el último PR mergeado contra src/payments/refunds.ts y encuentra que la rama partial_refund es inalcanzable por cualquier test actual. El Test Strategist abre un issue con un Given-When-Then redactado, lo enlaza con el requisito de spec REQ-PAY-044 y lo asigna al autor original. El issue cierra dentro del mismo sprint, y la matriz de trazabilidad pasa de 96 a 100 por ciento para el módulo de Payments.

Anti-patrones

  • Silenciar flakes con conteos de retry. Los retries esconden el defecto; el incidente igual llega a producción.
  • Perseguir line coverage. Las ramas y los mutants importan; las líneas son un número de vanidad.
  • Packs de regresión manuales. Cada regresión manual que encuentra un bug debe convertirse en un test automatizado en la misma semana.
  • Escribir tests después del merge. El trabajo de verificación hecho post-merge pierde palanca; diseñe los tests junto con la spec.
  • End-to-end como única red. Los tests end-to-end son lentos y frágiles; empuje el shift-left a las capas de contract y unit.
  • Fixtures sin dueño. Los fixtures compartidos de Playwright sin un dueño nombrado se pudren silenciosamente; asigne un dueño y revise cada sprint.
  • Tratar al agente como oráculo. El Test Strategist propone; el QA Engineer decide. Cada test generado por IA se revisa antes del merge.

KPIs y métricas de impacto

MétricaLínea base (manual)Meta (agéntico)Fuente
Tasa de escape (bugs encontrados post-release)12 por release< 2 por releaseApplication Insights, GitHub issues
Score de mutation en módulos críticosDesconocido> 85 por cientoMutation runner en GitHub Actions
Confiabilidad de la suite de tests88 por ciento> 99.5 por cientoTasa de flake de Actions
Tiempo de cierre de coverage gap3 sprints< 1 sprintGitHub Projects
Requisitos con test enlazado55 por ciento100 por cientoChequeo de trazabilidad en CI
Violaciones de accesibilidad por release180 críticasEjecuciones axe de Playwright
Mean time to triage de un flake5 días< 24 horasLogs de GitHub Actions

Madurez en cuatro niveles

  • L1 Manual: Casos de test en hoja de cálculo, sin mutation testing, carpeta de cuarentena de flakes, sin agente. La verificación es un cuello de botella tras code-complete.
  • L2 Asistido: Autocompletado de Copilot dentro de specs de Playwright, matriz de tests en una wiki, triage de flakes manual, sesiones exploratorias ad hoc.
  • L3 Aumentado: Agente Test Strategist, cuatro slash prompts, instrucciones con alcance, Playwright MCP cableado a GitHub Actions, mutation scans bajo demanda.
  • L4 Autónomo: Mutation scan nocturno con issues auto-enrutados, triage de flakes cerrando causas raíz en 24 horas, trazabilidad requisitos-a-tests en 100 por ciento, dashboard de verificación publicado a diario en Microsoft Teams.

Integración con otras personas

  • Desde el Business Analyst: requisitos EARS frescos con IDs únicos para trazabilidad.
  • Desde el Developer: PR mergeado con tests unitarios pasando y un enlace de spec declarado.
  • Hacia el Developer: issues de coverage-gap y mutation-survivor con borradores de tests sugeridos.
  • Desde el Software Architect: registro de riesgo arquitectónico que informa los carriles de tests de resiliencia.
  • Hacia el SRE: artefacto de despliegue verificado y synthetic probes actualizados.
  • Hacia el Compliance Auditor: matriz de trazabilidad enlazando requisitos con evidencia de ejecución de tests.
  • Con el UAT Analyst: fixtures de Playwright compartidos entre tests de sistema y tests de aceptación.

Glosario

  • Matriz de tests: la tabla viva que mapea requisitos a carriles de test, dueños y estado.
  • Score de mutation: porcentaje de fallas inyectadas detectadas por la suite de tests.
  • Flake: un test que pasa y falla de forma no determinística sobre código sin cambios.
  • Charter exploratorio: una investigación con time-box con misión declarada, no un script.
  • Trazabilidad: un enlace verificable desde ID de requisito a ID de test a PR.
  • Carril de verificación: una categoría de chequeos automatizados (unit, contract, integration, end-to-end, performance, accessibility, resilience) con su propio SLA y runner.
  • Tasa de escape: bugs descubiertos en producción que debieron haberse atrapado antes del release.

Referencias