Ir para o conteúdo

Guia do QA Owner

Na Esteira de Qualidade, o QA não executa testes repetitivos — ele é o dono dos agentes de qualidade. O dev roda os gates; você garante que os gates são bons, melhoram a cada sprint e cobrem o que importa.

Ver primeiro: Quality Layer e a qa-policy.

O que muda no seu papel

Antes (executor) Agora (owner)
Executar CTs manualmente a cada ticket Curar os agentes/skills que executam
Escrever plano do zero por ticket Manter .speckit/quality/ (o "Features")
Validar na mão no fim Definir thresholds e revisar o que os gates pegam
Gargalo no fim do fluxo Multiplicador: melhora o sistema p/ todos os devs

Suas responsabilidades

1. Curar .speckit/quality/

A base de conhecimento de homologação (seletores, mensagens exatas, navegação, cenários Gherkin). O learning-agent propõe deltas pós-ticket; você revisa e consolida. - Texto de mensagem sempre literal (o Gate 3 compara exato). - Só entra o que foi validado com evidência — não suposição.

2. Definir e calibrar thresholds

Em .claude/.local-config.json → quality.coverageThresholds e o escopo do smoke por sistema. Ajuste conforme a maturidade do projeto (legado começa mais permissivo; aperta com o tempo).

3. Revisar o que o gate não pega

Flaky tests, edge cases, exploratório, UX e regra de negócio ambígua continuam com você. Os gates cobrem o determinístico/regressível; o julgamento é seu.

4. Promover regressivo

E2E estável (aprovado em 2+ sprints) vira cobertura permanente. Script com falha nunca é promovido.

5. Configurar os runners por stack

Preencha quality.stackCommands (test/coverage/smoke/e2e) e quality.e2e (engine, URLs HML, credenciais por env). Sem isso, os gates reportam "não configurado".

O loop de melhoria contínua

dev roda os gates → learning-agent grava métricas + propõe deltas em .speckit/quality/
        → VOCÊ (owner) revisa os deltas, calibra thresholds, promove regressivo
        → próximo ticket: gates mais precisos, menos flaky, mais cobertura

Cadência sugerida: revisão semanal dos deltas do metrics-feed.jsonl e das propostas em .speckit/quality/.

Métricas que você acompanha (metrics-feed.jsonl)

Campo O que observar
coverage_percent / coverage_delta cobertura do diff por ticket; tendência
smoke_passed / e2e_passed estabilidade dos gates 2 e 3
qa_gates_status onde os tickets mais bloqueiam (gate1/2/3)
rework_count retrabalho — sinal de critério de aceite fraco no discovery

Bloqueios recorrentes num gate → ajuste upstream (DoR-for-QA no discovery) ou o threshold.

Princípios

  • Gate é hard stop, não sugestão — não relaxe um gate para "destravar"; conserte a causa.
  • Sem credencial hardcoded — sempre env (quality.e2e.credentialsEnv); valores no .env local (a partir de .env.example). O qa-expert nunca digita senha: a sessão vem de um storageState gerado fora do agente (script de login lê o .env), então o segredo nunca passa pelo contexto do modelo.
  • O dev é autônomo nos gates; você é dono da régua. Sua alavanca é melhorar a régua, não executar por ele.

Referências

Voltar ao topo