Conceito e mecanismo
Prevenir defeitos começa por melhorar a compreensão partilhada das regras. Uma equipa descreve um pedido rejeitado como terminal; outra espera que possa ser corrigido e reenviado com o mesmo identificador. Escrever testes sem resolver a diferença pode cristalizar interpretações incompatíveis. Durante a revisão, percorre exemplos com negócio, desenvolvimento, suporte e testes. Procura estados sem saída necessária, ações sem autorização definida, mensagens sem tratamento de erro e condições sobrepostas. Uma observação de revisão deve identificar o problema e a consequência possível, permitindo ao autor responder. Contar comentários sem distinguir relevância incentiva volume e não compreensão. A prevenção é uma responsabilidade da equipa, não uma inspeção final delegada apenas ao tester.
Aplicação guiada
Usa perspetivas distintas para enriquecer a revisão: o operador procura recuperação compreensível, o programador verifica consistência das regras e APS considera diagnóstico e continuidade operacional. Num modelo de estados, uma seta para um estado sem saída pode ser correta se representar conclusão; só é defeito quando contraria a necessidade. Uma regra sem exemplo de fronteira é uma oportunidade de esclarecimento, não prova automática de implementação incorreta. Conserva decisões e atualiza a base de testes após a revisão para evitar que a discussão se perca. Quando um incidente revela um pressuposto falso, acrescenta esse padrão às futuras revisões e verifica se a ação melhora a deteção, em vez de apenas aumentar o número de itens da checklist.
Um estado terminal é válido quando corresponde ao comportamento requerido.
Armadilhas comuns
Comentário como defeito confirmado; sem saída como sempre errado; revisão sem atualizar a base.
Tópicos relacionados: Análise e evidência no processo de teste · Prioridade e risco residual · Domínios, fronteiras e combinações
Revê pressupostos e conserva decisões aplicáveis.
Referência: Cucumber introducing example mapping · CTAL-TA v4.0 (2025)