Fabio's blog

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.

Como desenvolvedor de software sempre fui do grupo que prefere construir a destruir logo nunca tive muito interesse a explorar a parte de testes de software. Com meus estudos de Arquitetura de Software , que possui uma atividade de Review da Arquitetura, percebi que precisa melhorar meus conhecimentos nesta área.

Entretanto , estudar Testes sempre ficou em segundo plano até agora. Surgiu uma boa oportunidade de estudar Teste de Software com o curso de Imersão de Testes oferecido pela Fuctura e apresentado por Roberto Alves.

Logo na primeira aula foi apresentado uma Taxonomia da Área de Testes e também processos de Teste de Software. Um importante aliado nesta aula é o syllabus da ISTQB .

Na segunda aula tivemos a apresentação do modelo de maturidade para testes TMM , as estratégias de testes e foi feita um exercício de construção de um Plano de Testes que foi o assunto mais interessante para min. Para esta segunda aula um excelente documento é a IEEE 829 que fala justamente sobre documentação de testes (plano de teste).

Próximo sábado teremos a terceira aula, sobre Ambiente de Testes, depois terei mais novidades.