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

Engenheiro de QA

Estratégia de testes e cobertura.

Atualizado: 2026-04-24 14 seções Baixar .zip

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

  1. 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.
  2. 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.
  3. Como Engenheiro de QA, eu quero testes flaky triados em um dia útil, para que o sinal continue confiável.
  4. Como Engenheiro de QA, eu quero lacunas de cobertura encaminhadas como issues com testes sugeridos, para que Developers as fechem na mesma sprint.
  5. 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.
  6. 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.
  7. 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.
  8. 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ã

  1. Puxe main, abra o repo no VS Code, deixe o Copilot Chat carregar AGENTS.md e as instruções com escopo .github/instructions/tests.instructions.md.
  2. Rode /test-plan --since=yesterday para escanear PRs merged e produzir um plano delta: quais novos requisitos EARS precisam de cobertura hoje.
  3. Abra os dashboards do Azure DevOps Test Plans e GitHub Actions para revisar as execuções noturnas; enfileire candidatos a flake.
  4. 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.
  5. 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

  1. Para cada PR de feature, invoque /test-plan com a seção da spec vinculada. O Test Strategist propõe lanes ausentes e escreve esqueletos de testes.
  2. Rode /mutation-scan nos módulos alterados nas últimas 24 horas. Sobreviventes se tornam issues tagueadas verification/weak-assertion.
  3. Conduza sessões exploratórias com o Playwright MCP. Todo achado que reproduz se torna uma spec Playwright commitada.
  4. 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

  1. Rode /flake-triage contra 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.
  2. Publique o dashboard de verificação: cobertura por módulo, score de mutação, taxa de flake, charters exploratórios abertos.
  3. Atualize a rastreabilidade do SPECIFICATION.md: cada ID de requisito deve estar linkado a pelo menos um teste passando.

Primitivas recomendadas

Agente

AgenteArquivoPropósito
test-strategist.github/agents/test-strategist.agent.mdProjeta 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

ComandoArquivoPropósito
/test-plan.github/prompts/test-plan.prompt.mdGerar ou atualizar o plano de testes para uma feature, linkado aos IDs EARS
/mutation-scan.github/prompts/mutation-scan.prompt.mdExecutar testes de mutação em módulos alterados e encaminhar sobreviventes
/flake-triage.github/prompts/flake-triage.prompt.mdAgrupar execuções falhando no Actions, propor causas-raiz, abrir issues
/coverage-gap.github/prompts/coverage-gap.prompt.mdMapear branches não testadas a seções específicas da spec e sugerir testes

Instruções com escopo

Escopo (applyTo)ArquivoPropósito
tests/**/*.github/instructions/tests.instructions.mdPadrão AAA, fixtures determinísticos, sem sleeps ocultos
tests/e2e/**/*.github/instructions/playwright.instructions.mdLocators do Playwright, captura de trace, política de retry
docs/specs/**/*.md.github/instructions/traceability.instructions.mdCada requisito linkado a pelo menos um ID de teste

Hooks

  • pre-push: rodar a fast test lane; bloquear push em falha
  • post-merge: regenerar a matriz de testes e publicar no Azure DevOps Test Plans
  • nightly: rodar o scan de mutação nos módulos alterados naquele dia
  • pre-release: enforçar score mínimo de mutação e limiares de cobertura de rastreabilidade
  • on-flake: abrir uma issue no GitHub automaticamente quando um teste falha duas vezes em sete dias

MCPs validados

MCPPropósitoDono
GitHub MCP ServerLer PRs, execuções do Actions, anotar issuesGitHub
Azure DevOps MCP ServerSincronizar a matriz de testes no Azure DevOps Test PlansMicrosoft
Playwright MCPConduzir sessões exploratórias e execuções ponta a ponta gravadasMicrosoft
Azure MCP ServerConsultar Azure Monitor e Application Insights para telemetria de falhasMicrosoft
Microsoft Learn Docs MCPConsultar orientações de teste atualizadas para serviços Azure em testeMicrosoft

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étricaLinha base (manual)Meta (agêntico)Fonte
Taxa de escape (bugs encontrados pós-release)12 por release< 2 por releaseApplication Insights, issues do GitHub
Score de mutação em módulos críticosDesconhecido> 85 por centoRunner de mutação no GitHub Actions
Confiabilidade da suíte de testes88 por cento> 99,5 por centoTaxa de flake do Actions
Tempo de fechamento de lacuna de cobertura3 sprints< 1 sprintGitHub Projects
Requisitos com teste linkado55 por cento100 por centoVerificação de rastreabilidade no CI
Violações de acessibilidade por release180 críticasExecuções do Playwright axe
Tempo médio para triar um flake5 dias< 24 horasLogs 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