QA EngineerEngenheiro de QAIngeniero QA
Test strategy and coverage.Estratégia de testes e cobertura.Estrategia de tests y cobertura.
The QA Engineer is the persona that designs, runs, and evolves the test strategy for the whole product. In an AI-native SDLC, the QA Engineer operates a Test Strategist agent, a bank of slash prompts, and a validated MCP catalog — not a manual test console.
Executive summary
The QA Engineer owns the Verification phase. Their job is to prove that the code shipped by Developers actually satisfies the EARS requirements and Given-When-Then acceptance criteria locked into SPECIFICATION.md. In an AI-native SDLC, that proof is produced by a Test Strategist agent, four slash prompts, scoped instructions, and a small set of validated MCPs that reach into Azure DevOps Test Plans, GitHub Actions, and Playwright.
The primary outputs are a living test matrix, a mutation-tested suite, a flake register with root causes, and coverage-gap reports that route back to Developers as fresh issues. The QA Engineer does not compete with Developers on unit tests; they orchestrate the broader verification portfolio: integration, contract, end-to-end, resilience, and exploratory testing supported by AI.
The QA Engineer does not replace Developer-written unit tests; they guarantee that the union of all verification layers actually demonstrates the product meets its contract. They are the last principled defender of the invariant: no undocumented behavior reaches production.
Role and responsibilities
Think of the QA Engineer like a flight-test engineer. The pilots fly, the mechanics build, but someone has to design the envelope-expansion plan that proves the aircraft safe across every regime it will ever see. In an AI-native SDLC, the QA Engineer is accountable for the envelope of automated and exploratory evidence that lets the team ship every day with confidence.
Primary responsibilities:
- Translate each EARS requirement into at least one executable test and one manual exploratory charter
- Own the test matrix across unit, contract, integration, end-to-end, performance, and accessibility lanes
- Run mutation testing on critical modules and route survivors back as issues
- Triage flaky tests within 24 hours, never silence them
- Maintain the Playwright MCP fixtures for end-to-end and visual coverage
- Operate the Test Strategist agent and the
/test-plan,/mutation-scan,/flake-triage,/coverage-gapprompts - Publish weekly verification dashboards from Azure Monitor and GitHub Actions data
- Coach Developers on test design during pair sessions and PR reviews
Jobs to be done
- As a QA Engineer, I want a generated test plan for every feature that links back to spec IDs, so that no acceptance criterion ships unverified.
- As a QA Engineer, I want mutation scores per module, so that I know where assertions are weak before the incident finds out.
- As a QA Engineer, I want flaky tests triaged within one working day, so that the signal stays trustworthy.
- As a QA Engineer, I want coverage gaps routed as issues with suggested tests, so that Developers close them in the same sprint.
- As a QA Engineer, I want Playwright runs recorded and indexed, so that post-incident analysis is a query, not an archaeology expedition.
- As a QA Engineer, I want the test matrix exported to Azure DevOps Test Plans, so that non-engineering stakeholders can browse verification evidence.
- As a QA Engineer, I want accessibility checks embedded in every end-to-end run, so that WCAG regressions are caught at merge time.
- As a QA Engineer, I want a weekly summary posted to Microsoft Teams, so that the whole org sees product quality trend lines.
Pain points before AI-native
- Tests trail features. QA writes tests after code ships; scope drifts and regressions leak into the backlog.
- Flake amnesia. Flaky tests are quarantined and forgotten. The same race condition bites twice a quarter, and the team loses trust in red builds.
- Coverage theatre. Line coverage hits 80 percent while critical branches are never exercised; audits pass and incidents still happen.
- Exploratory work undocumented. Charters live in notebooks; learnings never become automated regression, so the same bug returns in a different screen.
- Handoffs lose context. Developer fixes a bug, QA re-tests, but the failing scenario that proved the fix is not attached to the PR, so future regression is unprotected.
- No shared dashboard. Verification status lives in five tools; leadership has no single, current view of product quality.
AI-native daily workflow
The QA Engineer works from Visual Studio Code with GitHub Copilot and from the terminal with Claude Code, invoking the Test Strategist agent throughout the day.
Morning setup
- Pull
main, open the repo in VS Code, let Copilot Chat loadAGENTS.mdand the scoped.github/instructions/tests.instructions.md. - Run
/test-plan --since=yesterdayto scan merged PRs and produce a delta plan: which new EARS requirements need coverage today. - Open Azure DevOps Test Plans and GitHub Actions dashboards to review overnight runs; queue flake candidates.
- Review the overnight mutation scan output posted to the Verification channel in Microsoft Teams; pin the top three survivors as today’s priority.
- Sync with the on-call SRE for any production incidents that should feed a new exploratory charter.
Midday execution
- For each feature PR, invoke
/test-planwith the linked spec section. The Test Strategist proposes missing lanes and writes skeleton tests. - Run
/mutation-scanon modules changed in the last 24 hours. Survivors become issues taggedverification/weak-assertion. - Drive exploratory sessions with the Playwright MCP. Every finding that reproduces becomes a committed Playwright spec.
- Pair with the Developer on red tests; never approve a PR where a test was deleted without an equivalent replacement.
Afternoon review
- Run
/flake-triageagainst the daily Actions logs. The agent clusters failures, proposes root causes, and opens issues with a suggested fix owner. - Publish the verification dashboard: coverage by module, mutation score, flake rate, open exploratory charters.
- Update
SPECIFICATION.mdtraceability: every requirement ID links to at least one passing test.
Recommended primitives
Agent
| Agent | File | Purpose |
|---|---|---|
test-strategist | .github/agents/test-strategist.agent.md | Designs test plans, runs mutation scans, triages flakes, routes coverage gaps |
The Test Strategist runs on claude-sonnet-4-6 with tools read, grep, bash, edit. Extended thinking is enabled for mutation analysis only.
Slash prompts
| Command | File | Purpose |
|---|---|---|
/test-plan | .github/prompts/test-plan.prompt.md | Generate or update the test plan for a feature, linked to EARS IDs |
/mutation-scan | .github/prompts/mutation-scan.prompt.md | Run mutation testing on changed modules and route survivors |
/flake-triage | .github/prompts/flake-triage.prompt.md | Cluster failing Actions runs, propose root causes, open issues |
/coverage-gap | .github/prompts/coverage-gap.prompt.md | Map untested branches to specific spec sections and suggest tests |
Instructions scoped
Scope (applyTo) | File | Purpose |
|---|---|---|
tests/**/* | .github/instructions/tests.instructions.md | AAA pattern, deterministic fixtures, no hidden sleeps |
tests/e2e/**/* | .github/instructions/playwright.instructions.md | Playwright locators, trace capture, retry policy |
docs/specs/**/*.md | .github/instructions/traceability.instructions.md | Every requirement links to at least one test ID |
Hooks
pre-push: run the fast test lane; block push on failurepost-merge: regenerate the test matrix and publish to Azure DevOps Test Plansnightly: run the mutation scan on modules changed that daypre-release: enforce minimum mutation score and traceability coverage thresholdson-flake: open a GitHub issue automatically when a test fails twice in seven days
Validated MCPs
| MCP | Purpose | Owner |
|---|---|---|
| GitHub MCP Server | Read PRs, Actions runs, annotate issues | GitHub |
| Azure DevOps MCP Server | Sync the test matrix into Azure DevOps Test Plans | Microsoft |
| Playwright MCP | Drive exploratory sessions and recorded end-to-end runs | Microsoft |
| Azure MCP Server | Query Azure Monitor and Application Insights for failure telemetry | Microsoft |
| Microsoft Learn Docs MCP | Look up current test guidance for Azure services under test | Microsoft |
Real examples
Example 1: mutation survivors become PRs
Running /mutation-scan src/billing/ returns 7 survivors in invoice-total.ts. The Test Strategist drafts 7 new test cases and opens a single issue titled verification/weak-assertion: billing invoice-total. A Developer picks it up, writes the tests, and the next mutation run returns zero survivors in that module. The KPI dashboard shows module mutation score climb from 58 to 94 percent.
Example 2: flake triage ends a six-month bug
/flake-triage clusters 14 failures in checkout.spec.ts from the last week and points to a race between a Playwright page.click and an inflight Azure Front Door cache revalidation. The Test Strategist proposes a fix: wait for the specific network response, not a timeout. The fix lands as a one-line change, the test stops flaking, and the Reliability KPI for that suite returns to 99.8 percent.
Example 3: coverage gap routed back to the Developer
/coverage-gap inspects the last merged PR against src/payments/refunds.ts and finds the partial_refund branch is unreachable by any current test. The Test Strategist opens an issue with a drafted Given-When-Then, links it to the spec requirement REQ-PAY-044, and assigns it to the original author. The issue closes within the same sprint, and the traceability matrix flips from 96 to 100 percent for the Payments module.
Anti-patterns
- Silencing flakes with retry counts. Retries hide the defect; the incident still ships.
- Chasing line coverage. Branches and mutants matter; lines are a vanity number.
- Manual regression packs. Every manual regression that finds a bug must become an automated test in the same week.
- Writing tests after merge. Verification work done post-merge loses leverage; design tests alongside the spec.
- End-to-end as the only net. End-to-end tests are slow and brittle; push shift-left into contract and unit layers.
- Unowned fixtures. Shared Playwright fixtures without a named owner rot silently; assign an owner and review every sprint.
- Treating agents as oracle. The Test Strategist proposes; the QA Engineer decides. Every AI-generated test is reviewed before merge.
KPIs and impact metrics
| Metric | Baseline (manual) | Target (agentic) | Source |
|---|---|---|---|
| Escape rate (bugs found post-release) | 12 per release | < 2 per release | Application Insights, GitHub issues |
| Mutation score on critical modules | Unknown | > 85 percent | Mutation runner in GitHub Actions |
| Test suite reliability | 88 percent | > 99.5 percent | Actions flake rate |
| Coverage gap closure time | 3 sprints | < 1 sprint | GitHub Projects |
| Requirements with linked test | 55 percent | 100 percent | Traceability check in CI |
| Accessibility violations per release | 18 | 0 critical | Playwright axe runs |
| Mean time to triage a flake | 5 days | < 24 hours | GitHub Actions logs |
Maturity in four levels
- L1 Manual: Spreadsheet test cases, no mutation testing, flake quarantine folder, no agent. Verification is a bottleneck after code-complete.
- L2 Assisted: Copilot autocomplete inside Playwright specs, test matrix in a wiki, manual flake triage, ad-hoc exploratory sessions.
- L3 Augmented: Test Strategist agent, four slash prompts, scoped instructions, Playwright MCP wired to GitHub Actions, mutation scans on demand.
- L4 Autonomous: Nightly mutation scan with auto-routed issues, flake triage closing root causes within 24 hours, requirements-to-tests traceability at 100 percent, verification dashboard published daily to Microsoft Teams.
Integration with other personas
- From Business Analyst: fresh EARS requirements with unique IDs for traceability.
- From Developer: merged PR with passing unit tests and a declared spec link.
- To Developer: coverage-gap and mutation-survivor issues with suggested test drafts.
- From Software Architect: architectural risk register that informs resilience test lanes.
- To SRE: verified deployment artifact and updated synthetic probes.
- To Compliance Auditor: traceability matrix linking requirements to evidence of test execution.
- With UAT Analyst: shared Playwright fixtures between system tests and acceptance tests.
Glossary
- Test matrix: the living table mapping requirements to test lanes, owners, and status.
- Mutation score: percentage of injected faults detected by the test suite.
- Flake: a test that passes and fails non-deterministically on unchanged code.
- Exploratory charter: a time-boxed investigation with a stated mission, not a script.
- Traceability: a verifiable link from requirement ID to test ID to PR.
- Verification lane: a category of automated checks (unit, contract, integration, end-to-end, performance, accessibility, resilience) with its own SLA and runner.
- Escape rate: bugs discovered in production that should have been caught before release.
References
- Testing guidance on Microsoft Learn — Azure DevOps Test Plans and strategy
- GitHub Actions testing docs — CI patterns for verification
- Playwright MCP — Microsoft-maintained MCP for browser automation
- Application Insights availability tests — synthetic monitoring
- GitHub Copilot for test generation — agent-assisted test authoring
- GitHub Advanced Security — CodeQL and secret scanning signals fed into the test plan
- Azure Load Testing — performance and resilience lane
- Azure Application Insights smart detection — anomaly signals for exploratory charters
O Engenheiro de QA é a persona que projeta, executa e evolui a estratégia de testes para todo o produto. Em um SDLC AI-nativo, o Engenheiro de QA opera um agente Test Strategist, um banco de slash prompts e um catálogo validado de MCPs — não um console de testes manual.
Resumo executivo
O Engenheiro de QA é dono da fase de Verificação. Seu trabalho é provar que o código entregue pelos Developers realmente satisfaz os requisitos EARS e os critérios de aceitação Given-When-Then fixados no SPECIFICATION.md. Em um SDLC AI-nativo, essa prova é produzida por um agente Test Strategist, quatro slash prompts, instruções com escopo e um pequeno conjunto de MCPs validados que alcançam Azure DevOps Test Plans, GitHub Actions e Playwright.
As saídas primárias são uma matriz de testes viva, uma suíte testada por mutação, um registro de flakes com causas-raiz e relatórios de lacunas de cobertura que retornam aos Developers como novas issues. O Engenheiro de QA não compete com Developers em testes unitários; ele orquestra o portfólio de verificação mais amplo: integração, contrato, ponta a ponta, resiliência e testes exploratórios apoiados por IA.
O Engenheiro de QA não substitui os testes unitários escritos pelo Developer; ele garante que a união de todas as camadas de verificação realmente demonstre que o produto cumpre seu contrato. Ele é o último defensor de princípios do invariante: nenhum comportamento não documentado chega à produção.
Papel e responsabilidades
Pense no Engenheiro de QA como um engenheiro de ensaios de voo. Os pilotos voam, os mecânicos constroem, mas alguém precisa projetar o plano de expansão de envelope que prove a aeronave segura em cada regime que ela vai enfrentar. Em um SDLC AI-nativo, o Engenheiro de QA é responsável pelo envelope de evidências automatizadas e exploratórias que permite ao time entregar todo dia com confiança.
Responsabilidades primárias:
- Traduzir cada requisito EARS em pelo menos um teste executável e um charter exploratório manual
- Ser dono da matriz de testes em todas as lanes: unitário, contrato, integração, ponta a ponta, performance e acessibilidade
- Executar testes de mutação em módulos críticos e encaminhar sobreviventes como issues
- Triar testes flaky em até 24 horas, nunca silenciá-los
- Manter os fixtures do Playwright MCP para cobertura ponta a ponta e visual
- Operar o agente Test Strategist e os prompts
/test-plan,/mutation-scan,/flake-triage,/coverage-gap - Publicar dashboards semanais de verificação a partir de dados do Azure Monitor e GitHub Actions
- Mentorar Developers em design de testes durante sessões em par e revisões de PR
Jobs to be done
- Como Engenheiro de QA, eu quero um plano de testes gerado para cada feature que se liga aos IDs da spec, para que nenhum critério de aceitação seja entregue sem verificação.
- Como Engenheiro de QA, eu quero scores de mutação por módulo, para que eu saiba onde as asserções são fracas antes que o incidente descubra.
- Como Engenheiro de QA, eu quero testes flaky triados em um dia útil, para que o sinal continue confiável.
- Como Engenheiro de QA, eu quero lacunas de cobertura encaminhadas como issues com testes sugeridos, para que Developers as fechem na mesma sprint.
- Como Engenheiro de QA, eu quero execuções do Playwright gravadas e indexadas, para que a análise pós-incidente seja uma consulta, não uma expedição arqueológica.
- Como Engenheiro de QA, eu quero a matriz de testes exportada para o Azure DevOps Test Plans, para que stakeholders não técnicos possam navegar pelas evidências de verificação.
- Como Engenheiro de QA, eu quero verificações de acessibilidade embutidas em cada execução ponta a ponta, para que regressões WCAG sejam capturadas no momento do merge.
- Como Engenheiro de QA, eu quero um resumo semanal postado no Microsoft Teams, para que toda a organização veja as linhas de tendência de qualidade do produto.
Dores antes do AI-nativo
- Testes ficam atrás das features. QA escreve testes depois que o código é entregue; o escopo se distorce e regressões vazam para o backlog.
- Amnésia de flakes. Testes flaky são colocados em quarentena e esquecidos. A mesma race condition ataca duas vezes por trimestre, e o time perde confiança em builds vermelhos.
- Teatro de cobertura. Cobertura de linha atinge 80 por cento enquanto branches críticas nunca são exercitadas; auditorias passam e incidentes continuam acontecendo.
- Trabalho exploratório não documentado. Charters vivem em cadernos; aprendizados nunca se tornam regressão automatizada, então o mesmo bug retorna em uma tela diferente.
- Handoffs perdem contexto. Developer corrige um bug, QA retesta, mas o cenário em falha que provou a correção não está anexado ao PR, deixando a regressão futura desprotegida.
- Sem dashboard compartilhado. O status de verificação vive em cinco ferramentas; a liderança não tem uma visão única e atualizada da qualidade do produto.
Fluxo diário AI-nativo
O Engenheiro de QA trabalha a partir do Visual Studio Code com GitHub Copilot e do terminal com Claude Code, invocando o agente Test Strategist ao longo do dia.
Setup da manhã
- Puxe
main, abra o repo no VS Code, deixe o Copilot Chat carregarAGENTS.mde as instruções com escopo.github/instructions/tests.instructions.md. - Rode
/test-plan --since=yesterdaypara escanear PRs merged e produzir um plano delta: quais novos requisitos EARS precisam de cobertura hoje. - Abra os dashboards do Azure DevOps Test Plans e GitHub Actions para revisar as execuções noturnas; enfileire candidatos a flake.
- Revise a saída do scan de mutação noturno postada no canal de Verificação no Microsoft Teams; fixe os três principais sobreviventes como prioridade do dia.
- Sincronize com o SRE de plantão sobre quaisquer incidentes de produção que devam alimentar um novo charter exploratório.
Execução no meio do dia
- Para cada PR de feature, invoque
/test-plancom a seção da spec vinculada. O Test Strategist propõe lanes ausentes e escreve esqueletos de testes. - Rode
/mutation-scannos módulos alterados nas últimas 24 horas. Sobreviventes se tornam issues tagueadasverification/weak-assertion. - Conduza sessões exploratórias com o Playwright MCP. Todo achado que reproduz se torna uma spec Playwright commitada.
- Pareie com o Developer em testes vermelhos; nunca aprove um PR onde um teste foi deletado sem uma substituição equivalente.
Revisão no fim da tarde
- Rode
/flake-triagecontra os logs diários do Actions. O agente agrupa falhas, propõe causas-raiz e abre issues com um dono sugerido para a correção. - Publique o dashboard de verificação: cobertura por módulo, score de mutação, taxa de flake, charters exploratórios abertos.
- Atualize a rastreabilidade do
SPECIFICATION.md: cada ID de requisito deve estar linkado a pelo menos um teste passando.
Primitivas recomendadas
Agente
| Agente | Arquivo | Propósito |
|---|---|---|
test-strategist | .github/agents/test-strategist.agent.md | Projeta planos de teste, executa scans de mutação, tria flakes, encaminha lacunas de cobertura |
O Test Strategist roda com claude-sonnet-4-6 e ferramentas read, grep, bash, edit. Extended thinking é habilitado apenas para análise de mutação.
Slash prompts
| Comando | Arquivo | Propósito |
|---|---|---|
/test-plan | .github/prompts/test-plan.prompt.md | Gerar ou atualizar o plano de testes para uma feature, linkado aos IDs EARS |
/mutation-scan | .github/prompts/mutation-scan.prompt.md | Executar testes de mutação em módulos alterados e encaminhar sobreviventes |
/flake-triage | .github/prompts/flake-triage.prompt.md | Agrupar execuções falhando no Actions, propor causas-raiz, abrir issues |
/coverage-gap | .github/prompts/coverage-gap.prompt.md | Mapear branches não testadas a seções específicas da spec e sugerir testes |
Instruções com escopo
Escopo (applyTo) | Arquivo | Propósito |
|---|---|---|
tests/**/* | .github/instructions/tests.instructions.md | Padrão AAA, fixtures determinísticos, sem sleeps ocultos |
tests/e2e/**/* | .github/instructions/playwright.instructions.md | Locators do Playwright, captura de trace, política de retry |
docs/specs/**/*.md | .github/instructions/traceability.instructions.md | Cada requisito linkado a pelo menos um ID de teste |
Hooks
pre-push: rodar a fast test lane; bloquear push em falhapost-merge: regenerar a matriz de testes e publicar no Azure DevOps Test Plansnightly: rodar o scan de mutação nos módulos alterados naquele diapre-release: enforçar score mínimo de mutação e limiares de cobertura de rastreabilidadeon-flake: abrir uma issue no GitHub automaticamente quando um teste falha duas vezes em sete dias
MCPs validados
| MCP | Propósito | Dono |
|---|---|---|
| GitHub MCP Server | Ler PRs, execuções do Actions, anotar issues | GitHub |
| Azure DevOps MCP Server | Sincronizar a matriz de testes no Azure DevOps Test Plans | Microsoft |
| Playwright MCP | Conduzir sessões exploratórias e execuções ponta a ponta gravadas | Microsoft |
| Azure MCP Server | Consultar Azure Monitor e Application Insights para telemetria de falhas | Microsoft |
| Microsoft Learn Docs MCP | Consultar orientações de teste atualizadas para serviços Azure em teste | Microsoft |
Exemplos reais
Exemplo 1: sobreviventes de mutação viram PRs
Rodar /mutation-scan src/billing/ retorna 7 sobreviventes em invoice-total.ts. O Test Strategist elabora 7 novos casos de teste e abre uma única issue intitulada verification/weak-assertion: billing invoice-total. Um Developer assume, escreve os testes, e o próximo scan de mutação retorna zero sobreviventes naquele módulo. O dashboard de KPI mostra o score de mutação do módulo subindo de 58 para 94 por cento.
Exemplo 2: triagem de flake encerra um bug de seis meses
/flake-triage agrupa 14 falhas em checkout.spec.ts da última semana e aponta para uma race entre um page.click do Playwright e uma revalidação de cache do Azure Front Door em andamento. O Test Strategist propõe uma correção: esperar pela resposta de rede específica, não por um timeout. A correção aterrissa como uma mudança de uma linha, o teste para de flakar e o KPI de Confiabilidade daquela suíte retorna a 99,8 por cento.
Exemplo 3: lacuna de cobertura encaminhada ao Developer
/coverage-gap inspeciona o último PR merged contra src/payments/refunds.ts e descobre que a branch partial_refund é inalcançável por qualquer teste atual. O Test Strategist abre uma issue com um Given-When-Then rascunhado, a linka ao requisito da spec REQ-PAY-044 e a atribui ao autor original. A issue é fechada na mesma sprint, e a matriz de rastreabilidade salta de 96 para 100 por cento no módulo de Pagamentos.
Anti-padrões
- Silenciar flakes com contagens de retry. Retries escondem o defeito; o incidente continua sendo entregue.
- Perseguir cobertura de linha. Branches e mutantes importam; linhas são número de vaidade.
- Packs de regressão manual. Toda regressão manual que encontra um bug deve se tornar um teste automatizado na mesma semana.
- Escrever testes após o merge. Trabalho de verificação feito após o merge perde alavancagem; projete testes junto com a spec.
- Ponta a ponta como única rede. Testes ponta a ponta são lentos e frágeis; empurre shift-left para as camadas de contrato e unitário.
- Fixtures sem dono. Fixtures compartilhados do Playwright sem um dono nomeado apodrecem silenciosamente; atribua um dono e revise a cada sprint.
- Tratar agentes como oráculo. O Test Strategist propõe; o Engenheiro de QA decide. Todo teste gerado por IA é revisado antes do merge.
KPIs e métricas de impacto
| Métrica | Linha base (manual) | Meta (agêntico) | Fonte |
|---|---|---|---|
| Taxa de escape (bugs encontrados pós-release) | 12 por release | < 2 por release | Application Insights, issues do GitHub |
| Score de mutação em módulos críticos | Desconhecido | > 85 por cento | Runner de mutação no GitHub Actions |
| Confiabilidade da suíte de testes | 88 por cento | > 99,5 por cento | Taxa de flake do Actions |
| Tempo de fechamento de lacuna de cobertura | 3 sprints | < 1 sprint | GitHub Projects |
| Requisitos com teste linkado | 55 por cento | 100 por cento | Verificação de rastreabilidade no CI |
| Violações de acessibilidade por release | 18 | 0 críticas | Execuções do Playwright axe |
| Tempo médio para triar um flake | 5 dias | < 24 horas | Logs do GitHub Actions |
Maturidade em quatro níveis
- L1 Manual: Casos de teste em planilha, sem testes de mutação, pasta de quarentena de flakes, sem agente. Verificação é gargalo após o code-complete.
- L2 Assistido: Autocomplete do Copilot dentro de specs do Playwright, matriz de testes em wiki, triagem manual de flakes, sessões exploratórias ad hoc.
- L3 Aumentado: Agente Test Strategist, quatro slash prompts, instruções com escopo, Playwright MCP conectado ao GitHub Actions, scans de mutação sob demanda.
- L4 Autônomo: Scan de mutação noturno com issues encaminhadas automaticamente, triagem de flakes fechando causas-raiz em 24 horas, rastreabilidade de requisitos a testes em 100 por cento, dashboard de verificação publicado diariamente no Microsoft Teams.
Integração com outras personas
- Do Business Analyst: requisitos EARS frescos com IDs únicos para rastreabilidade.
- Do Developer: PR merged com testes unitários passando e um link de spec declarado.
- Para o Developer: issues de lacuna de cobertura e sobreviventes de mutação com rascunhos de testes sugeridos.
- Do Software Architect: registro de risco arquitetural que informa lanes de teste de resiliência.
- Para o SRE: artefato de deploy verificado e synthetic probes atualizados.
- Para o Compliance Auditor: matriz de rastreabilidade linkando requisitos a evidências de execução de testes.
- Com o UAT Analyst: fixtures Playwright compartilhados entre testes de sistema e testes de aceitação.
Glossário
- Matriz de testes: a tabela viva mapeando requisitos a lanes de teste, donos e status.
- Score de mutação: percentual de falhas injetadas detectadas pela suíte de testes.
- Flake: um teste que passa e falha de forma não determinística em código inalterado.
- Charter exploratório: uma investigação com tempo limitado e missão declarada, não um script.
- Rastreabilidade: um link verificável de ID de requisito a ID de teste a PR.
- Lane de verificação: uma categoria de verificações automatizadas (unitário, contrato, integração, ponta a ponta, performance, acessibilidade, resiliência) com seu próprio SLA e runner.
- Taxa de escape: bugs descobertos em produção que deveriam ter sido capturados antes do release.
Referências
- Orientação de testes no Microsoft Learn — Azure DevOps Test Plans e estratégia
- Documentação de testes do GitHub Actions — Padrões de CI para verificação
- Playwright MCP — MCP mantido pela Microsoft para automação de navegador
- Testes de disponibilidade do Application Insights — Monitoramento sintético
- GitHub Copilot para geração de testes — Autoria de testes assistida por agente
- GitHub Advanced Security — Sinais de CodeQL e secret scanning alimentando o plano de testes
- Azure Load Testing — Lane de performance e resiliência
- Detecção inteligente do Azure Application Insights — Sinais de anomalia para charters exploratórios
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
- 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.
- 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.
- Como QA Engineer, quiero los tests flaky triagados dentro de un día laboral, para que la señal se mantenga confiable.
- Como QA Engineer, quiero los coverage gaps enrutados como issues con tests sugeridos, para que los Developers los cierren en el mismo sprint.
- 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.
- 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.
- 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.
- 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
- Hacer pull a
main, abrir el repo en VS Code, dejar que Copilot Chat cargueAGENTS.mdy el.github/instructions/tests.instructions.mdcon alcance. - Ejecutar
/test-plan --since=yesterdaypara escanear los PRs mergeados y producir un plan delta: qué nuevos requisitos EARS necesitan cobertura hoy. - Abrir Azure DevOps Test Plans y los dashboards de GitHub Actions para revisar las ejecuciones nocturnas; encolar candidatos a flake.
- 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.
- Sincronizar con el SRE de guardia por cualquier incidente de producción que deba alimentar un nuevo charter exploratorio.
Ejecución al mediodía
- Para cada PR de feature, invocar
/test-plancon la sección de spec vinculada. El Test Strategist propone carriles faltantes y escribe esqueletos de tests. - Ejecutar
/mutation-scanen los módulos cambiados en las últimas 24 horas. Los survivors se vuelven issues con la etiquetaverification/weak-assertion. - Conducir sesiones exploratorias con el Playwright MCP. Cada hallazgo que se reproduzca se vuelve un Playwright spec versionado.
- 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
- Ejecutar
/flake-triagecontra los logs diarios de Actions. El agente agrupa fallas, propone causas raíz y abre issues con un sugerido owner del fix. - Publicar el dashboard de verificación: cobertura por módulo, score de mutation, tasa de flake, charters exploratorios abiertos.
- Actualizar la trazabilidad de
SPECIFICATION.md: cada ID de requisito se enlaza con al menos un test pasando.
Primitivas recomendadas
Agente
| Agente | Archivo | Propósito |
|---|---|---|
test-strategist | .github/agents/test-strategist.agent.md | Diseñ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
| Comando | Archivo | Propósito |
|---|---|---|
/test-plan | .github/prompts/test-plan.prompt.md | Generar o actualizar el plan de tests para una feature, vinculado a IDs EARS |
/mutation-scan | .github/prompts/mutation-scan.prompt.md | Ejecutar mutation testing en módulos cambiados y enrutar survivors |
/flake-triage | .github/prompts/flake-triage.prompt.md | Agrupar ejecuciones fallidas de Actions, proponer causas raíz, abrir issues |
/coverage-gap | .github/prompts/coverage-gap.prompt.md | Mapear ramas no probadas a secciones específicas de spec y sugerir tests |
Instructions con alcance
Alcance (applyTo) | Archivo | Propósito |
|---|---|---|
tests/**/* | .github/instructions/tests.instructions.md | Patrón AAA, fixtures determinísticos, sin sleeps escondidos |
tests/e2e/**/* | .github/instructions/playwright.instructions.md | Locators de Playwright, captura de trace, política de retry |
docs/specs/**/*.md | .github/instructions/traceability.instructions.md | Cada requisito enlaza con al menos un ID de test |
Hooks
pre-push: ejecutar el carril rápido de tests; bloquear el push en fallapost-merge: regenerar la matriz de tests y publicarla en Azure DevOps Test Plansnightly: ejecutar el mutation scan en los módulos cambiados ese díapre-release: aplicar umbrales mínimos de score de mutation y de cobertura de trazabilidadon-flake: abrir un issue de GitHub automáticamente cuando un test falla dos veces en siete días
MCPs validados
| MCP | Propósito | Dueño |
|---|---|---|
| GitHub MCP Server | Leer PRs, ejecuciones de Actions, anotar issues | GitHub |
| Azure DevOps MCP Server | Sincronizar la matriz de tests en Azure DevOps Test Plans | Microsoft |
| Playwright MCP | Conducir sesiones exploratorias y ejecuciones end-to-end grabadas | Microsoft |
| Azure MCP Server | Consultar Azure Monitor y Application Insights por telemetría de fallas | Microsoft |
| Microsoft Learn Docs MCP | Buscar guía actual de tests para servicios Azure bajo prueba | Microsoft |
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étrica | Línea base (manual) | Meta (agéntico) | Fuente |
|---|---|---|---|
| Tasa de escape (bugs encontrados post-release) | 12 por release | < 2 por release | Application Insights, GitHub issues |
| Score de mutation en módulos críticos | Desconocido | > 85 por ciento | Mutation runner en GitHub Actions |
| Confiabilidad de la suite de tests | 88 por ciento | > 99.5 por ciento | Tasa de flake de Actions |
| Tiempo de cierre de coverage gap | 3 sprints | < 1 sprint | GitHub Projects |
| Requisitos con test enlazado | 55 por ciento | 100 por ciento | Chequeo de trazabilidad en CI |
| Violaciones de accesibilidad por release | 18 | 0 críticas | Ejecuciones axe de Playwright |
| Mean time to triage de un flake | 5 días | < 24 horas | Logs 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
- Guía de testing en Microsoft Learn — Azure DevOps Test Plans y estrategia
- Docs de testing de GitHub Actions — patrones CI para verificación
- Playwright MCP — MCP mantenido por Microsoft para automatización de navegador
- Application Insights availability tests — monitoreo sintético
- GitHub Copilot para generación de tests — autoría de tests asistida por agente
- GitHub Advanced Security — señales de CodeQL y secret scanning alimentando el plan de tests
- Azure Load Testing — carril de performance y resiliencia
- Smart detection de Azure Application Insights — señales de anomalía para charters exploratorios