Dicas para Escrita de Casos de Teste

Daniele Endler
4 min readJan 4, 2018

--

“Caso de Teste: conjunto de valores de entrada, pré-condições de execução, resultados esperados e pós-condições de execução, desenvolvidas para um determinado objetivo ou condição de teste.” (IEEE 610)

Um Caso de Teste mostra os caminhos percorridos por um módulo, Caso de Uso ou funcionalidade dentro do projeto. Serve como base para que os testadores possam executar os testes manualmente, mas pode ser criado, também, com o intuito de automatizar os testes. Além disso, os Casos de Teste devem cobrir o máximo de situações possíveis. Resumindo, um Caso de Teste é um conjunto de ações e os resultados esperados para elas.

As ações são os passos que serão executados pelo testador. Estas ações devem levar a um resultado esperado. Devem sempre iniciar com um verbo infinitivo — preencher, validar, clicar, acionar — ou imperativo — preencha, valide, verifique. Exemplos:

- Validar a máscara do campo “CPF”.

- Verificar se o registro foi salvo na base de dados.

- Clique no botão “Voltar”.

- Acessar o menu Administração Geral > Configurações.

Os resultados esperados são as respostas às ações realizadas pelo usuário. Cada ação deverá ter um resultado esperado. Exemplo:

Mas então, o que preciso ter para planejar os testes?

  • Ter consciência de que o objetivo do Caso de Teste é encontrar bugs;
  • Ser focado e pensar em diversas situações possíveis;
  • Ser detalhista (ou até perfeccionista);
  • Conhecer algumas técnicas de testes (não é obrigatório, mas sempre ajuda);
  • Ter visão de usuário;
  • Conhecer o negócio;
  • Ser crítico;
  • Ser proativo.

E quais as características de um bom caso de teste?

1. Possuir um título claro, objetivo, rastreável e autoexplicativo: o título do Caso de Teste deve permitir que ele seja facilmente encontrado e reconhecido, deve deixar claro qual o seu objetivo.

2. Seguir um padrão: seguir um padrão de escrita é ideal, principalmente quando existe mais um Analista de Testes na equipe. Exemplo: sempre colocar o menu entre colchetes no título do Caso de Teste, colocar campos e mensagens entre aspas.

3. Ser objetivo e não exaustivo: sempre evitar Casos de Teste com muitos passos (mais de 20, por exemplo). Nem sempre isto é possível, mas um Caso de Teste muito extenso se torna exaustivo e pode fazer com que não se preste atenção em todos os passos.

4. Tornar evidentes as situações de falha: o objetivo do Caso de Teste é encontrar bugs, portanto é necessário que o resultado esperado esteja claro. Desta forma, o testador saberá exatamente a resposta que o sistema deveria dar, deixando as falhas evidentes.

5. Ser autossuficiente: todas as informações necessárias para a realização do teste devem estar dentro do Caso de Teste, sejam os pré-requisitos, possíveis templates, etc.

6. Atingir a maior cobertura possível: os Casos de Teste devem cobrir o máximo de situações possíveis, ou seja, deve haver Caso de Teste para cada fluxo documentado.

7. Estar sempre atualizado: um Caso de Teste desatualizado irá confundir quem estiver testando, pois os resultados esperados já não estarão mais de acordo com o documentado.

8. Ser reutilizável: se um Caso de Teste será utilizado somente uma vez, talvez nem haja a necessidade de escrevê-lo. O ideal é que os Casos de Teste sejam escritos para serem atualizados e reutilizados, seja nas Sprints seguintes ou nas fases de integração/homologação do sistema.

Outras dicas:

  1. Planejar antes de escrever: em casos muito complexos, pode-se criar um documento para auxiliar o planejamento (pode ser uma tabela/matriz/fluxo, uma folha escrita à mão). Exemplo:
Tabela com as diversas combinações de login que devem ser testadas.

2. Inserir informações que pareçam óbvias: o que é óbvio para você, pode não ser óbvio para outra pessoa. Exemplo:

Pode parecer óbvio que, ao clicar em “Fechar” o sistema feche, ou que em “Logout” saia do sistema, mas muitas informações que podem ser óbvias para uma pessoa não necessariamente serão óbvias para todas.

3. Sempre informar o resultado esperado: um passo nunca pode ficar sem o resultado esperado. Se não existe resultado esperado, a ação não está completa. Neste caso, pode ser necessário escrever uma ação mais detalhada para que exista um resultado a ser esperado. Exemplo:

Deseja-se testar se o sistema exibe mensagem informando que o CPF é inválido ao retirar o foco do campo. No exemplo de cima, a ação não está completa, não existindo um resultado no primeiro passo (o que está incorreto). Já no segundo exemplo, o testador sabe exatamente o que precisa fazer para chegar ao resultado esperado (passo completo).

4. Cuidar ações muito extensas: assim como não deve haver uma ação sem resultado esperado, uma ação não pode ser extensa o suficiente para o testador se perder ao executá-la. Cada ação que gera um resultado, deve ser um passo. Exemplo:

Ação tão grande que chega a exibir a barra de rolagem…

5. Cuidar informações duplicadas e/ou contradizentes: é muito importante cuidar para que um passo (ou até um Caso de Teste) não invalide outro.

6. Cuidar a gramática: sempre, por favor! Colocar ponto final nas frases, acentuar as palavras corretamente.

7. Pode X Deve: nunca utilizar frases como “o sistema pode”, prefira a palavra deve, assim não se deixa dúvidas do resultado esperado para a ação.

8. Revisar os Casos de Teste ao final da escrita.

--

--