Testes pós entrega

Você deve estar se perguntando ao ler o titulo Teste pós entrega: "Porque eu deveria testar a aplicação após a entrega, já que existe um período de testes e homologação para garantir a qualidade (ou parte dela) da minha aplicação"?

Bom, vou citar alguns pontos a favor:

• Achar aqueles bugs bem "tinhosos" (não é o foco, mas pode acontecer)
• Garantir, sob condições diversas vários critérios como usabilidade, performance, etc... (após a entrega e, provavelmente quando você estiver verificando a aplicação o cliente está usando)
• Verificar resultados esperados
• Continuar achando bugs

Pontos "contra":

• Pode aumentar o custo de teste
• Má organização e planejamento de testes
• Demanda tempo para testes que podem não estar alocados

Bom, eu fiz um processo aqui na empresa não por existir bugs em produção, mas para continuar garantindo a qualidade da aplicação.
A aplicação em questão é um site de serviços, sendo o mesmo para todos os clientes.

Criei uma Matriz de Ciclo Pós Entrega, que consiste em alocar pessoas por dia/semana para efetuar determinado teste na aplicação. Basicamente este matriz possui:

• Criar um calendário (pode ser agrupado por dias ou semanas)
• Lista de Recursos
• Grupos de Tarefas
  

No exemplo que será apresentado uma matriz com dias da semana (quase um calendário, os recursos e os grupos de funcionalidades para teste).

No caso do exemplo não cobrimos todos os grupos de funcionalidades já no primeiro dia de teste, efetuamos isso gradativamente, na apresentada, por possuir 13 grupos de funcionalidades ela vai iniciar novamente na 3° semana.

Este é um modelo que eu utilizo aqui, e que tem garantido nossa segurança em relação ao sistema, verificação de usabilidade e as demais questões citadas.

Algumas questões levantadas sobre este tema podem visualizadas na lista da QAI Brasil: http://br.groups.yahoo.com/group/qai-brasil/

Você pode visualizar e baixar o template que criei neste link.

Abraços!

Templates de documentos de Engenharia de Software

Existe um projeto do repositório Tigris.org chamado ReadySET cujo intuito é prover templates de documentos referente à Engenharia de Software.
Estes documentos podem servir como ponto de partida para a documentação de seu projeto.
Vejo em algumas listas o pessoal pedindo templates de documentos, em sua maioria de Plano de Testes que é facilmente confeccionado com base na norma IEEE 829...

O projeto ReadSET possui os seguintes documentos:

• Proposta do projeto
• Plano do Projeto
• Caso de Uso
• Plano de QA
• Casos de Teste
• Checklists

Você pode visualizar todos os templates neste link.

Vale a pena verificar estes templates mesmo se você já possui um modelo bem definido.
Quando você efetua o download destes documentos ele já vem num formato HTML já padronizado e muito organizado.

Livro Automação e Gerenciamento de Testes

Dia 21/07/2007 foi lançado o livro "Automação e Gerenciamento de Testes:Aumentando a Produtividade com as Principais Soluções Open Source e Gratuitas" por Cristiano Caetano.

Este livro aborda as principais ferramentas OpenSource e gratuitas de Teste de Software apresentando um catálogo de ferramentas e seus principais recursos.

O livro está disponível a venda em ebook por este link.

Vale a pena conferir!

Resenha: http://www.linhadecodigo.com.br/Artigo.aspx?id=1392
Preview do livro: http://www.linhadecodigo.com.br/EBook.aspx?id=2951

Casos de Teste

Depois de um tempo sem blogar vou compartilhar minhas experiências sobre um documento muito utilizado por nós, profissionais de qualidade e teste de software: Casos de Teste.
Vamos fazer uma abordagem bem inicial:

O que é um Caso de Teste?
Basicamente um Caso de Teste é aquele documento que possui entradas dentro inseridas no sistema/programa e suas saidas esperadas.
Mostra os caminhos percorridos por um módulo, caso de uso ou funcionalidade dentro do projeto.
Servem como base para que os testadores possam executar os testes manualmente, mas podemos cria-los com o intuito de automatizar os casos e devem cobrir o máximo de situações possíveis.

Campos necessários para um Caso de Teste
Segunda a norma IEEE 829 um Caso de Teste deve possuir:

• Identificador do Caso de Teste
• Itens de teste
• Especificações de entrada
• Especificações de Saida
• Ambiente necessário
• Exigências especiais
• Interdependências

Identificador do Caso de Teste
Devemos criar um identificador para o documento. Podemos colocar informações sobre o tipo de caso, revisão, numero do caso de teste entre outros itens.

Itens de teste
Breve descrição dos itens, funcionalidades, módulos, etc. que será descrito no caso de teste.

Especificações de entrada
Especifica todas as entradas necessárias para executar o caso de teste. Podemos colocar qualquer tipo de entrada no caso de teste, o que melhor se adequar a sua realidade.
Ex: dados na tela, comandos SQL, mensagens, etc...

Especificações de Saida
Especificar todas as saidas e particularidades depois de executada uma determinada entrada. Procure explicar claramente o que deve ser exibido para não haver erros de entendimento.

Ambiente necessário
Especifica ambientes como hardware e software necessários para a execução do caso de teste, bem como qualquer configuração que externa (fora da aplicação).

Exigências especiais
Descreve qualquer caso especial de inicialização, configuração, etc que seja necessário aplicar no caso de teste.

Interdependências
Relacionar todos os documentos necessários para a execução do caso de teste. Procure sumarizar os documentos.


Ao longo do tempo vou postar alguns modelos de casos de teste.
Quem tiver algum modelo que queira compartilhar envie um email ou poste um comentário aí!

Abraços!


Referências:
http://en.wikipedia.org/wiki/Test_case
http://standards.ieee.org/reading/ieee/std_public/description/se/829-1983_desc.html

Novos blogs sobre Qualidade e Teste de Softtware

Seguem mais blogs sobre Qualidade e Teste de Software:

José Papo Weblog
http://josepaulopapo.blogspot.com/

Diário da Qualidade
http://diariodaqualidade.blogspot.com/

Abraços