Projeto

Na fase de Projeto, o objetivo principal é a elaboração de casos de teste.

Para elaborar os casos de teste, geralmente partimos de um cenário de teste (um comportamento do sistema a ser testado). Um cenário de teste pode ter vários casos de teste associados. A diferença entre caso e cenário deve ficar evidente no exemplo abaixo:

• Cenário 1: Verificar o cadastro de um Cliente

  • Casos de teste associados:

    • Cadastro de um cliente pessoa física

    • Cadastro de um cliente pessoa física com informações obrigatórias faltando

    • Cadastro de um cliente pessoa física com CPF existente na base de dados

    • Cadastro de um cliente pessoa jurídica

Caso de teste

Um Caso de Teste é uma sequência de passos a serem executados para testar um sistema através de entradas pré-definidas e a comparação de seu resultado esperado após a execução. Um exemplo de um caso de teste pode ser encontrado abaixo:

Casos de teste estão relacionados a:

• Requisitos (o que motivou o teste)

• Configurações (o que deve ser testado)

• Iteração (quando deve ser testado)

• Implementação

Algumas características são desejáveis ao se produzir um caso de teste.

• Efetivo, para que se possa ser testado o que se planejou testar;

• Reutilizável, para que possa ser repetido quantas vezes forem necessárias;

• Rastreável, para que possamos identificar o requisito que está sendo testado;

• Autoexplicativo, para que possa ser testado por qualquer testador.

Roteiro de testes

Nessa fase pode também ser elaborado os roteiros de teste. Esse roteiro é uma especificação de um conjunto de casos de teste que serão executados, funcionand como um "agregador" para que várias funcionalidades que fazem sentido juntas ou que são interdependentes sejam testadas juntas. Abaixo um exemplo de um roteiro de teste, sendo que os únicos campos necessários são: (1) O nome/identificação do roteiro e (2) A lista dos casos a serem executados.

Técnicas para modelagem de testes

Partição por equivalência

Imagine que você tenha um campo que receba apenas números pares. É necessário validar que o tal campo não recebe todos os números ímpares? Segundo a técnica de partição de equivalência, não. Ela afirma que, sendo o resultado final correspondente para diferentes entradas, basta ordená-las em conjuntos e testar apenas um dado de cada.

No caso do cenário que formulamos, o número 5 e o número 11 possuem a mesma saída (são ímpares), logo, basta testar com um deles. Assim, ao invés de 2 testes com resultados equivalentes, teremos um contemplando a mesma saída. O mesmo seria feito com o conjunto dos pares para validar se o campo recebe os números pares, só precisariamos de um exemplo de número par.

Análise de valores limites

Consiste em testar os valores limites das partições identificadas. Ex.: Suponha que uma especificação de um módulo diga que uma entrada válida para um determinado campo seja de 1 até 499, nesse exemplo teriamos:

• Partição 1: número válido dentro do limite

  • No limite. Ex: 1, 499

• Partição 2: um número menor que 1

  • Logo abaixo do limite: 0

  • Bem abaixo do limite: -1000

• Partição 3: um número maior que 499

  • Logo acima do limite: 500

  • Bem acima do limite: 100000

Derivação de Caso de Uso

Consiste em extrair cenários de teste baseados nos casos de uso descritos para o sistema, caso os requisitos do sistema possam ser especificados como casos de uso. É uma boa técnica para encontrar defeitos do mundo real e é usada normalmente na fase de teste de sistema e aceitação.

Nenhuma técnica é melhor que a outra. Cada uma pode ser melhor utilizada em determinados contextos.