APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Riscos de produto dizem respeito a possíveis problemas do produto, como débitos duplicados ou acesso indevido. Riscos de projeto ameaçam a execução do trabalho, como falta de ambiente, pessoas ou tempo. O plano de testes deve explicitar objetivos, âmbito, abordagem, recursos e critérios. Critérios de entrada ajudam a avaliar preparação; critérios de saída permitem avaliar conclusão. Priorizar por risco procura evidência sobre impacto e probabilidade, considerando dependências. A gestão acompanha resultados e ajusta trabalho; um relatório deve mostrar cobertura, defeitos e risco remanescente de forma adequada ao destinatário.
Aplicação guiada
Antes de uma release, uma percentagem elevada de aprovação não compensa automaticamente um defeito crítico. Explica quais os critérios não cumpridos e as opções à autoridade definida. Não alteres severidade apenas para passar um gate. Para cada defeito, guarda versão, ambiente, condições, passos, esperado, observado e evidência sem dados sensíveis desnecessários. Identifica também versões do testware e dados usados. Isso permite reproduzir diferenças entre execuções e distinguir uma regressão real de mudanças no ambiente ou nos próprios testes.
98 de 100 testes passam, mas os dois restantes revelam dados de outro cliente. O relatório deve destacar este impacto e o critério de saída não cumprido.
Armadilhas comuns
Confundir prioridade com severidade; esconder casos não executados; perder a configuração usada; deixar o calendário redefinir resultados.
Tópicos relacionados: Ferramentas e confiança no sinal · Evidência, defeitos e objetivos de teste
A recomendação de release deve tornar visível a evidência e o risco que ainda precisa de decisão.
Referência: ISTQB CTFL syllabus v4.0.1 · CTFL v4.0; syllabus v4.0.1 (2024-09-15)