Pular para o conteúdo

Fases 6–7 — Qualidade e homologação (S)

As Fases 6 (Qualidade) e 7 (Homologação) operam em paralelo ao desenvolvimento. A IA gera testes, calcula cobertura e media o UAT; o time de QA e o Validador de Negócio confirmam cada resultado.

Acionamento: histórias publicadas (Fase 2) e SRS (Fase 3).

O que a IA faz:

  1. Toma as histórias em formato BDD e o SRS.
  2. Gera testes unitários (pytest, jest, etc.) para regras de negócio.
  3. Gera testes de integração para APIs e mensageria.
  4. Gera testes E2E (Cypress, Playwright) para os fluxos principais.
  5. Cria dados de teste realistas (faker) sem dados pessoais reais.
  6. Tudo já vinculado ao critério BDD original (rastreabilidade direta requisito → teste).

Validação humana obrigatória: QA Lead revisa cada teste gerado antes de incluir no pipeline; testes errados podem dar falsa segurança. Testes que envolvem dados pessoais ou fluxos de privacidade passam pelo Encarregado de Dados.

Ganho típico: 6–8 horas em escrita de testes; testes já mapeados a requisitos.

Acionamento: testes rodando no CI/CD.

O que a IA faz:

  1. Calcula cobertura por requisito, não apenas por linhas de código.
  2. Identifica requisitos sem testes correspondentes.
  3. Sugere casos de borda faltantes.
  4. Alerta quando a cobertura cai entre sprints.
RequisitoCoberturaStatusAção sugerida
REQ-001 (Enviar para aprovação)100%OK
REQ-002 (Email de notificação)95%OK
REQ-003 (Rejeitar com feedback)65%GapAdicionar teste de rejeição sem feedback
REQ-004 (Escalação automática)100%OK
REQ-005 (Limite de reabertura)0%Não implementadoConfirmar adiamento ou priorizar

Validação humana obrigatória: o QA Lead revisa cada gap e decide entre “adicionar teste agora”, “adiar para próxima sprint” ou “aceitar risco com registro”. Decisões de “aceitar risco” exigem aprovação do Validador Técnico e do PO.

Ganho típico: 1–2 horas em análise de gaps; cobertura por requisito torna explícito o que falta — não fica escondido em “70% do código está testado”.

O que a IA faz:

  1. Toma o resultado dos testes a cada execução.
  2. Gera relatório de cobertura versionado.
  3. Cria matriz requisito → teste → resultado.
  4. Identifica testes que falharam com causa-raiz inicial sugerida.

Validação humana obrigatória: o QA Lead aprova a causa-raiz antes de virar bug formal; “causa-raiz por IA” é hipótese, não diagnóstico.

Ganho típico: 2–3 horas em relatório de QA por sprint; rastreabilidade 100% (qual teste valida qual requisito).

O que a IA faz:

  1. Gera roteiro de teste baseado nas histórias (caminho feliz + casos de borda + escalações).
  2. Prepara dados de teste realistas (sem dados pessoais reais).
  3. Cria guia do usuário passo a passo (como executar cada cenário).
  4. Identifica cenários críticos que precisam de validação especial.
  5. Configura formulário de feedback estruturado (severidade, descrição, evidência).

Validação humana obrigatória: o PO + Validador de Negócio aprovam o roteiro e o guia; usuário não pode receber roteiro inadequado.

Ganho típico: 3–4 horas em preparação de UAT.

Quando: o usuário testa o sistema em ambiente de homologação.

O que a IA faz:

  1. Transcreve o feedback do usuário (verbal e escrito).
  2. Diferencia bug (algo não funciona como o requisito) de mal-entendido (“achei que fosse diferente”).
  3. Categoriza issues por severidade (bloqueante, crítica, menor).
  4. Atualiza o roadmap em tempo real (drafts).
  5. Gera ata automática.

Usuário: “Quando rejeito um documento, não vejo em lugar nenhum que foi rejeitado. Fico sem saber.”

IA analisa: “Achado: feedback de rejeição não aparece para o solicitante. Requisito relacionado: REQ-003 (Rejeitar com feedback). Categoria: crítica (bloqueia aceitação). Sugestão: adicionar tela de status ou notificação de rejeição.”

Analista: “Confirmado. Severidade?”

IA: “Crítica — impede uso normal. Estimativa: 4 SP (1–2 dias).”

Usuário: “Queremos correção agora.”

IA cria ação atribuída ao desenvolvedor responsável com prazo.

Validação humana obrigatória: o Validador de Negócio classifica cada achado entre “bug confirmado”, “mal-entendido a esclarecer” ou “nova história a planejar”; o Fiscal técnico confirma a severidade quando há impacto contratual.

Ganho típico: 2–3 horas em triagem de issues; nada importante esquecido; severidade discutida com base em critério (não em sentimento).

ItemCritério
Cobertura por requisito100% dos requisitos com pelo menos um teste passando
Cobertura geralAcima da meta (ex.: ≥ 80%) — ou risco aceito com registro
Bugs críticosZero em aberto antes do encerramento da Fase 7
Roteiro de UATAprovado por PO e Validador de Negócio
Issues pós-UATTriadas, classificadas e com responsável
Ata e roadmapAtualizados após cada sessão de UAT

A Fase 8 só é iniciada quando as Fases 6 e 7 estão encerradas com aprovação dupla (QA Lead + Validador de Negócio).


Anterior: 7 · Fase 5 — Desenvolvimento assistido · Próximo: 9 · Fase 8 — Deploy e operação