Terminou sábado (7/2) a última aula do curso de teste. Após este curso uma grande mudança ocorreu em minhas concepções de teste. Sempre achava chato efetuar testes , não acho mais.

Até hoje eu fazia o teste de meus sistemas de uma forma ad-hoc . Após o curso compreendi quais os trade-offs envolvidos para obter as qualidades desejadas do sistema.

Para ter um visão ampla do processo deve-se compreender apenas os principais aspectos. Para listar os principais aspectos deste processo eu diria:

• Planejamento por meio do Plano de Testes
• Casos de Testes
• Mentalidade de Teste

O plano de testes permite você planejar seus planos de testes ele responde as perguntas de quando e quem vai executar o processo de teste e é claro o que esperar do resultado deste processo. Um bom template do processo de teste é fornecido pelo IEEE 829-1998

Os casos de teste é o cavalo de batalha do processo de teste ele é o principal artefato deste processo . Por outro lado ele é um elemento muito simples. Podemos definir um bom template com os seguintes elementos:

1. Identificador do teste (Ex: TC-001)
2. Descrição
3. Pré-condição
4. Pós-condições
5. Passos e Resultado esperados

Simples e bastante efetivo. Onde está a dificuldade? A dificuldade antes de mais nada é que um bom caso de teste deve antes de mais nada FALHAR , ou seja, um bom caso de teste é aquele que encontra um defeito no sistema. Para encontrar uma sequência de passos que realmente faça o sistema falhar não é trivial. Por outro lado bons casos de teste mesmo quando não falham permite que você ganhe confiança que o sistema dentro das especificações , por outro lado eles permitem apenas verificar o sistema e não validar o sistema, para tanto deve-se usar outras técnicas.

A mentalidade de teste pode ser resumida em uma palavra: destruir. Destruir é o propósito que o responsável pelos testes deve ter em mente.

No final parece simples e assim que deve ser. Efetuar testes é simples como programar também . Entretanto, para efetuar testes deve-se compreender as pequenas e inúmeras nuances existentes no processo o que define se estamos fazendo um sistema com as qualidades desejadas ou não.