Quando este modelo ajuda
- Você entrega uma funcionalidade e precisa demonstrar os cenários combinados.
- Um cliente deve decidir o aceite com falhas e limites visíveis.
- Correções foram feitas e é necessário ligar reteste à versão nova.
Defina o resultado antes de executar
Um cenário de teste tem condição inicial, ação e resultado esperado. “Testar cadastro” não descreve o que comprovar. Escreva: com uma conta de teste sem cadastro prévio, enviar os campos válidos; o sistema deve criar uma conta e apresentar a confirmação definida. Se a regra não está combinada, a execução pode provar um comportamento sem mostrar se ele está correto.
Inclua casos que distinguem sucesso de erro relevante: campo obrigatório ausente, repetição de envio, formato inválido ou falta de permissão, conforme a funcionalidade. Não adicione dezenas de variações decorativas. Escolha os cenários que podem mudar a decisão sobre aquela entrega.
Versão e ambiente fazem parte da prova
Registre versão, ambiente, navegador ou dispositivo quando influírem no resultado. Um teste no ambiente local não comprova que a mesma função esteja operando no endereço público; um cenário em desktop não estabelece funcionamento no celular. Não esconda essas camadas num rótulo geral “aprovado”.
Use dados fictícios ou um conjunto de teste autorizado e mantenha a referência da evidência. A captura deve mostrar o comportamento necessário sem expor senhas ou informações pessoais. Um vídeo ou log pode ser melhor que imagem para uma sequência, mas a escolha depende do que precisa ser demonstrado.
Falha, impedimento e não execução são estados diferentes
Falha significa que a execução ocorreu e divergiu do esperado. Impedimento significa que uma condição necessária faltou, como acesso ao ambiente. Não executado significa que o teste não foi realizado. Separar esses estados evita atribuir aprovação ao que ficou fora da cobertura.
Um cenário pode passar e outro falhar na mesma funcionalidade. Registre cada resultado e o efeito prático da falha. “Problema no formulário” não informa se todos os usuários estão bloqueados ou se um formato específico produz uma mensagem incorreta. Essa diferença ajuda a priorizar a correção e decidir o aceite.
O reteste deve demonstrar a correção na versão certa
Ligue o defeito ao cenário, à evidência original e à versão corrigida. Repita o cenário afetado e os vizinhos que possam ter sido alterados pela solução. Não é necessário repetir todo o sistema por hábito, mas também não basta clicar uma vez num caminho que não exercita o defeito.
Mantenha os resultados anteriores identificáveis. Trocar um “falhou” por “passou” sem versão nem data apaga a sequência e pode fazer alguém acreditar que a primeira entrega já estava correta. Registre uma nova execução e a relação com a correção.
Exemplo fictício: cadastro com e-mail duplicado
Cenário T-03: enviar um e-mail já usado. Esperado: impedir a segunda conta e orientar o usuário conforme a regra. Observado na versão A: a tela aceita e cria duplicidade. Resultado: falhou, com evidência E-03. Na versão B, o cenário foi reexecutado e o bloqueio ocorreu; o cadastro com e-mail novo também foi conferido por ser vizinho da mudança.
O reteste prova esses comportamentos nessa versão e ambiente. Ele não autoriza declarar que o software inteiro está “sem bugs”. O resumo de cobertura deve mostrar o conjunto executado e as lacunas materiais que continuam abertas.
Aceite precisa de critério e de quem decide
No fechamento, apresente os critérios atendidos, as pendências e as condições propostas. A pessoa autorizada pode aceitar integralmente, aceitar com condições realmente combinadas ou recusar, conforme o instrumento da entrega. O responsável pelo teste não deve preencher o aceite do cliente como se a decisão já tivesse sido dada.
Se existe aceitação parcial, descreva exatamente a parte utilizável e o destino das falhas restantes, com responsável e prazo. “Aceito com ressalvas” sem enumerar as ressalvas pode criar uma disputa sobre o que ficou prometido. Registre a decisão pela forma prevista no relacionamento, sem supor que o modelo estabelece sozinho seus efeitos jurídicos.
Edição ativa
Relatório de testes e decisão de aceite
Edite e personalize o texto abaixo. Compartilhe o modelo editado pelo WhatsApp, baixe em PDF, Word ou TXT, ou imprima.
Como adaptar
- Escreva os resultados esperados antes do teste e vincule à regra da entrega.
- Use versões e estados distintos para execuções e retestes.
- Preencha a decisão de aceite somente quando ela tiver ocorrido pelo responsável.
Erros que enfraquecem
- Registrar passou em um cenário não executado.
- Declarar funcionamento público a partir de teste local.
- Apagar falha anterior ao inserir o reteste.
- Prometer ausência de bugs com uma cobertura limitada.
- Inventar aceite do cliente a partir do resultado dos testes.
