Estratégia de testes por risco

Escolher o que precisa de prova

Testar é produzir informação sobre um comportamento, comparando o observado com um resultado esperado. A estratégia organiza onde buscar essa informação primeiro. Na Oficina Caracol, listar serviços ativos e esconder registros inativos são compromissos diferentes: a primeira falha prejudica a utilidade; a segunda pode publicar conteúdo retirado de circulação. Contar testes sem distinguir essas consequências esconde a prioridade. O resultado esperado, também chamado oráculo do teste, precisa estar definido antes de interpretar a execução.

Risco combina uma consequência indesejada com a possibilidade de ela ocorrer. Para este exercício, usamos impacto e possibilidade em escalas de um a três. O produto dos números serve para ordenar a conversa, sem representar uma probabilidade científica. A equipe pode escolher outro modelo, desde que explique os critérios e trate consequências graves mesmo quando sua ocorrência pareça rara. O capítulo sobre testes do CTFL distingue risco de produto e decisões de teste orientadas por risco [S16, seção sobre gestão de riscos].

Construir uma matriz utilizável

• Identifique o fluxo, a pessoa afetada e a consequência da falha. Escreva uma frase concreta, como publicar um caso inativo, em lugar de sistema inseguro.
• Atribua impacto e possibilidade com justificativa. Registre quem participou da decisão e quais incertezas permanecem.
• Escolha a menor combinação de testes que consiga revelar o problema: regra isolada, fronteira real, fluxo completo e, quando aplicável, avaliação manual.
• Defina entradas, ambiente e resultado esperado. Reserve dados de exemplo e estabeleça como reconhecer uma falha.
• Execute as verificações aplicáveis, guarde os resultados e decida sobre lacunas. Uma linha sem evidência continua pendente, mesmo que a tabela esteja completa.

Ler a matriz como decisão

A primeira linha começa com dois registros conceituais: A está ativo e B está inativo. A consulta pública deve apresentar A e omitir B. O teste da regra localiza um possível erro de filtragem; o teste HTTP verifica se a rota usa a regra correta. Se a regra passar e a resposta revelar B, a integração permanece reprovada. O número seis explica a prioridade atribuída ao caso; ele não demonstra que a proteção funciona. Essa demonstração exige o resultado das duas verificações.

Uma execução de exemplo pode ser registrada com requisito, versão, ambiente, entrada, esperado, observado e veredito. No material de trabalho, os campos observado e veredito devem permanecer pendentes até a execução. Quando alguém aceita uma lacuna, registra também consequência, justificativa, autoridade e condição de reavaliação. O perfil Essencial reduz a documentação ao necessário, preservando essa decisão. O perfil Crítico acrescenta profundidade e independência conforme os riscos do projeto.

Erros e reparos

Condição de avanço

A estratégia pode avançar quando os riscos obrigatórios explicitamente escolhidos têm verificações adequadas, resultados aceitáveis e evidências identificadas; lacunas restantes estão classificadas e são não impeditivas, com aceitação registrada. Um risco crítico sem informação suficiente impede a liberação. A matriz será reaberta quando mudar uma regra, fronteira ou consequência relevante.

Exercício com dados fornecidos e solução

Considere três riscos: publicação de inativo, impacto três e possibilidade dois; título com erro de digitação, impacto um e possibilidade três; reserva duplicada, impacto três e possibilidade dois. Há tempo para investigar dois riscos hoje. Ordene-os, proponha uma verificação para cada escolhido e indique o que fica pendente.