“Eu testei isso ontem.”
Na Cantina Horizonte, três pessoas ajudam na verificação final.
Uma testa quantidade. Outra olha o cupom. A terceira verifica estoque. No fim, alguém pergunta:
“A quantidade 10 foi testada? Em qual navegador? Passou? Temos alguma evidência?”
Ninguém lembra com certeza.
O problema agora não é falta de técnica. É falta de organização.
Documentar só faz sentido quando resolve um problema
Não queremos produzir papéis enormes apenas porque “processo de teste usa documentos”.
Queremos registrar o suficiente para responder perguntas simples:
O que vamos testar?
Quais áreas e regras estão dentro desta rodada?
O que não vamos testar agora?
Quais partes ficaram fora e por quê?
Como vamos executar?
Ambiente, dados, sequência e resultado esperado.
O que aconteceu?
Resultado obtido, situação do teste e evidência.
Plano de testes: combinar o trabalho antes de começar
Plano de testes
É um registro que organiza o objetivo, o escopo, o ambiente, as prioridades e a forma de execução de uma atividade de teste.
Escopo significa aquilo que faz parte do trabalho naquele momento. Também é importante registrar o que está fora do escopo para evitar falsas expectativas.
Para uma rodada da Cantina Horizonte, poderíamos ter:
| Item | Definição da rodada |
|---|---|
| Objetivo | Avaliar uma versão candidata antes do uso na cantina. |
| Dentro do escopo | Quantidade, estoque, cupom, total e finalização. |
| Fora do escopo | Pagamento, autenticação e testes especializados de segurança. |
| Ambiente | Navegador definido, aplicação local e banco de teste. |
| Prioridade | Estoque, total, quantidade e cupom recebem atenção primeiro. |
Versão candidata é uma versão que está sendo avaliada para uma possível liberação. Um plano pequeno e compreensível é melhor do que um documento enorme que ninguém usa.
O plano diz o rumo; o caso de teste diz como verificar
Na Etapa 6 já usamos a identificação CT, de Caso de Teste. Agora vamos estruturar um caso de forma um pouco mais completa.
CT-QTD-01 · Rejeitar quantidade zero
Requisito relacionado: RF-03
Pré-condição: produto disponível para venda.
Dados de entrada: quantidade 0.
Ação: tentar adicionar o produto ao pedido.
Resultado esperado: rejeitar a operação e informar o motivo.
Pré-condição é uma condição que precisa existir antes da execução do caso. Se o teste depende de um produto com estoque, por exemplo, isso deve estar preparado antes.
Depois da execução, o caso ganha novos campos
| Campo | Para que serve |
|---|---|
| Resultado obtido | Registra o que realmente aconteceu. |
| Situação | Indica se o caso ainda não foi executado, passou, falhou ou ficou bloqueado. |
| Evidência | Guarda informação que ajuda a comprovar e compreender o resultado. |
Quatro situações simples para acompanhar a execução
Não executado
O caso está planejado, mas ainda não foi realizado.
Passou
O resultado obtido correspondeu ao resultado esperado.
Falhou
O resultado obtido foi diferente do esperado e precisa ser investigado.
Bloqueado
O caso não pôde ser concluído porque alguma dependência ou condição impediu a execução.
“Bloqueado” não significa necessariamente que o software falhou. Pode significar, por exemplo, que o banco de teste não iniciou ou que os dados necessários não estavam disponíveis.
Evidência não é sinônimo de tirar print de tudo
Evidência de teste
É uma informação que ajuda outra pessoa a compreender ou confirmar o que ocorreu durante a execução.
Dependendo do caso, uma boa evidência pode ser:
- uma captura de tela;
- uma mensagem exibida pela aplicação;
- um trecho do registro técnico do sistema, chamado também de log;
- um valor salvo no banco;
- a saída de um teste automatizado.
O importante é guardar aquilo que realmente ajuda a sustentar o resultado.
Da regra até o resultado: rastreabilidade
Agora imagine encontrar um caso chamado CT-QTD-03. Meses depois, alguém pergunta:
Qual requisito esse caso protege?
Se não houver ligação entre requisito e teste, a resposta pode depender novamente da memória.
Rastreabilidade
É a capacidade de acompanhar a ligação entre elementos relacionados, como requisito, critério, caso de teste, execução, resultado e defeito.
Na Cantina Horizonte:
Se o caso falhar e um defeito for registrado, essa cadeia pode continuar até o registro do problema e sua correção.
Uma matriz simples ajuda a enxergar lacunas
| Requisito | Regra observada | Caso | Situação |
|---|---|---|---|
| RF-03 | Rejeitar quantidade 0 | CT-QTD-01 | Não executado |
| RF-03 | Aceitar quantidade 1 | CT-QTD-02 | Não executado |
| RF-03 | Aceitar quantidade 10 | CT-QTD-03 | Não executado |
| RF-03 | Rejeitar quantidade 11 | CT-QTD-04 | Não executado |
Se existe um requisito importante sem nenhum caso relacionado, encontramos uma possível lacuna antes mesmo de executar.
Planilha, documento ou ferramenta específica?
Para este projeto, uma planilha ou um documento simples já resolve boa parte do trabalho.
Mais importante que a ferramenta é manter informação clara, atualizada e fácil de consultar.
A ferramenta deve ajudar o processo. O processo não deve existir apenas para alimentar a ferramenta.
Abra o modelo da Cantina Horizonte
Preparei um modelo curto com plano, riscos, casos de teste, situação de execução e rastreabilidade.
Documento de apoio
Abrir modelo de plano e casos de teste →
Use como ponto de partida. Não transforme o modelo em burocracia: adapte ao que realmente precisa ser registrado.
Prática · planeje uma pequena rodada
- Escolha três áreas da Cantina Horizonte para testar.
- Defina o que está dentro e fora do escopo dessa rodada.
- Escreva pelo menos quatro casos de teste ligados a requisitos conhecidos.
- Indique o resultado esperado e a prioridade de cada caso.
- Execute os casos e registre Passou, Falhou ou Bloqueado.
- Guarde uma evidência apenas onde ela realmente ajudar a explicar o resultado.
Um caso falhou. Agora precisamos contar a história do problema
Suponha que CT-QTD-01 tenha falhado: quantidade 0 foi aceita.
Escrever apenas:
“Quantidade está bugada.”
não ajuda outra pessoa a reproduzir, investigar e corrigir.
Que informações um bom registro de defeito precisa ter para que outra pessoa consiga repetir exatamente o problema?
Antes de seguir
Você deve conseguir explicar:
- para que serve um plano de testes;
- quais informações tornam um caso de teste reproduzível;
- o que significa evidência de teste;
- como a rastreabilidade liga requisito, caso e resultado;
- por que documentação útil deve apoiar o trabalho, e não virar um fim em si mesma.