Neste módulo, o profissional de testes demonstra suas habilidades de comunicação e organização para garantir que os defeitos descobertos sejam corrigidos e que o software atinja os Critérios de Término definidos no planejamento.
Após a execução dos casos de teste, o profissional deve iniciar o processo de validação e comparação de resultados de testes.
A avaliação é um passo crítico onde se determina se a execução foi um Sucesso ou uma Falha.
Lembrando do Plano de Teste (Módulo 2), os testes só podem ser declarados como "concluídos" quando os critérios de término são alcançados. Exemplos incluem:
Um defeito só pode ser corrigido se for bem documentado. O testador é responsável por documentar testes em conformidade com as especificações técnicas.
É essencial empregar ferramenta de documentação de teste para registro do resultado obtido. Ferramentas de gestão de defeitos (Bug Trackers ou Test Management Tools) como Jira, Azure DevOps ou Mantis são utilizadas para formalizar o relatório.
O relatório de defeito deve ser um documento completo, claro e conciso, permitindo ao desenvolvedor reproduzir o problema de forma rápida, sem a necessidade de intervenção do testador.
| Seção do Relatório | Importância |
|---|---|
| Título/Resumo | Deve ser direto e descrever a falha em uma frase (Ex: O botão 'Comprar' não está ativo com o carrinho vazio). |
| Prioridade (P) | Define a ordem em que o defeito deve ser corrigido (Ex: Alta, Média). |
| Severidade (S) | Define o impacto do defeito no sistema (Ex: Bloqueador, Crítico, Maior, Menor). |
| Passos para Reproduzir | O coração do relatório. Uma lista numerada e clara de 3 a 5 passos para manifestar a Falha. |
| Resultado Esperado | O que o sistema deveria ter feito (conforme a especificação). |
| Resultado Obtido | O que o sistema fez (a manifestação da Falha). |
| Evidências | Logs, screenshots ou vídeos que comprovem a ocorrência da falha. |
| Ambiente | Onde o teste foi executado (SO, navegador, URL do ambiente de teste). |