wiki:ExpressoTestCenter/testlink

Version 15 (modified by luiz-fernando, 14 years ago) (diff)

--

Guia de Utilização do Testlink

Esta seção tem por objetivo guiar as pessoas que desejam contribuir no projeto Expresso através da criação e execução de testes.

A Ferramenta

O Testlink é uma ferramenta open source para o gerenciamento de testes. Ele permite os cadastros de planos e casos de testes e o controle de execução dos testes.

Com o Testlink é possível que equipes de testes trabalhem de forma sincronizada mesmo em locais diferentes. Por ter uma interface Web e permitir níveis de acesso diferenciados, analistas de testes podem gerar as especificações de testes que outras equipes poderão executar. Outra característica interessante é o controle de execuções, gerando uma base histórica dos testes aos quais a aplicação foi submetida.

Possui integração com o Trac - ferramenta para gestão de defeitos - possibilitando cadastrar defeitos e associar ao caso de teste. Um exemplo de utilização do Testlink integrado ao Trac pode ser encontrado neste teste piloto.

Padronização

O principal objetivo é evitar termos diversos documentos relativos a teste espalhados em .DOCs, .ODTs e etc. A ideia é utilizar o próprio Testlink como centralizador dessas informações. Para isso foi definido um padrão que deve ser seguido por todos que irão cadastrar casos de teste. A padronização sugerida segue as recomendações da norma IEEE 829.

Test Plan

Ao criar o Plano de Teste no Testlink deve-se informar um nome único que permita a identificação do plano de teste. No exemplo abaixo o identificador é Unificacao v2.2.

No image "tp1.png" attached to ExpressoTestCenter/testlink

Na parte da descrição do Plano de Teste deve-se utilizar o seguinte padrão:

SeçãoComentários
Histórico de VersõesTabela com as seguintes colunas: Data, Versão, Descrição, Autor, Revisor, Aprovado por
1 ObjetivoDescrever os objetivos a serem alcançados com a realização das atividades de teste, informando os tipos de teste que serão realizados, a sistemática de trabalho entre equipes e produtos de trabalho a serem entregues; podendo ser identificado também os recursos e restrições orçamentárias
2 Escopo
2.1 DescriçãoListar as funcionalidades e/ou requisitos (funcionais e/ou não-funcionais) identificados como alvos críticos para realização das atividades de testes. Deve ser identificada a prioridade de cada funcionalidade e/ou requisito a ser testado.
2.2 Fora do escopoListar as funcionalidades que estarão fora do escopo do plano de testes, bem como as razões pelas quais form excluídas.
3 Estratégias de Teste
3.1 DescriçãoPara cada grupo de funcionalidades, descrever as atividades, especificidades e ferramentas usadas no Teste. Descrição dos objetivos das atividades relacionadas para cada grupo. Inclui os critérios de sucesso ou falha dos casos de testes. Define também os critérios para suspensão, requisitos de início e conclusão dos testes, bem como horário de execução e outras informações relativas a execução dos testes, onde se aplicar
3.2 AmbienteIdentificar a preparação/configuração do ambiente, descrevendo quais atividades devem ser feitas antes ou após a realização do teste
3.3 FerramentasIndicar a ferramenta de gestão e rastreamento de defeitos adotada e a ferramenta para realização e gerenciamento de testes funcionais, de performance e automatizados
3.2 Coleta de evidenciaObrigatório apenas para testes não funcionais. Ex: Tempo média de resposta, taxa de sucesso/insucesso, monitoração do consumo de memória/processador do servidor de aplicação/banco de dados
3.4 Critério de paradaObrigatório apenas para testes não funcionais de performance e stress. Nesse item devem ser especificados os critérios de parada usados na execução dos testes para suspender todas ou parte das atividades de teste associadas ao Plano de Teste. Ex: Incidência de defeitos acima do permitido, justificando uma parada no teste para revisão do código para corrigir os defeitos
4 Riscos e contingênciasIdentificar todos os riscos que poderão afetar a execução bem-sucedida do Plano de Testes. Tabela com as seguintes colunas: Risco, Estratégia de Diminuição, Impacto, Situação (Tratado/Não? Tratado), Responsável
5 CronogramaIdenticar restrições significativas do cronograma como por exemplo: preparação de ambiente de teste, disponibilidade de recursos assim como a data limite para finalização das atividades do Plano de Teste
6 ObservaçõesPreenchimento opcional caso existam demais considerações que não foram contempladas nos itens acima e que devam ser registradas.
7 ReferênciasLista documentos eventualmente referenciados no Plano de Teste
8 GlossárioIncluir todos os termos críticos para facilitar a comunicação

Test Suites

Optou-se por organizar os casos de teste de acordo com os módulos do Expresso. Atualmente temos os seguintes Test Suites (grupos de casos de teste):

O Test Suite "Validar Usuário" é destinado a testar o login do Expresso, incluindo o uso de Certificado Digital e Captcha. Depois temos o "Gerenciar E-Mail" que contém testes referentes ao módulo Expresso Mail. O "Gerenciar Agenda" contém testes referentes ao módulo Agenda de Eventos e o "Gerenciar Contatos" os do Catálogo de Endereços. Já o "Administrar Preferências" testa as preferências do Usuário que são comuns a todos os módulos, já que as preferências específicas de cada módulo estão contidas nas respectivas Test Suites dos módulos.

O prefixo "CDU" está sendo utilizado para fazer um mapeamento com os casos de uso (ainda não existentes). Na verdade esse é um ponto que ainda está em discussão, pois o Expresso está em processo de adoção de uma metodologia ágil de desenvolvimento e a ideia é escrever casos de uso apenas para as funcionalidades mais complexas. Para as demais funcionalidades serão escritas estórias de usuário. O problema é que nesse momento estamos escrevendo casos de teste partindo apenas das funcionalidades já implementadas e que não possuem nenhum requisito documentado. O objetivo é produzir uma documentação mínima de requisitos das funcionalidades já existentes, mas essa tarefa deverá ser feita em paralela a criação dos casos de teste pois a prioridade é ter o Centro de Testes do Expresso funcionando o mais rápido possível.

Para cada Test Suite de primeiro nível (que correspondem aos módulos do Expresso) deve-se ter um documento com informações do que e de como executar os testes.

  • 1 - Test Suite de primeiro nível
  • 2 - Documento referente ao Test Suite de primeiro nível

O documento deve ter a seguinte estrutura:

SeçãoComentários
Histórico de VersõesTabela com as seguintes colunas: Data, Versão, Descrição, Autor, Revisor, Aprovado por
1 Introdução
1.1 Objetivo
1.2 Escopo
1.3 Definições, Acrônimos, e Abreviações
1.4 Referências
2 Preparação do Ambiente

Esse documento deve ser baseado no Plano de Teste e contém informações mais técnicas voltadas especificamente para a equipe de teste e não para o usuário.

Para as Test Suites de segundo nível, a documentação é opcional, mas se for utilizada, deve-se utilizar o mesmo padrão da Test Suite de primeiro nível

Test Case

Abaixo segue um exemplo de um caso de teste previamente criado:

  • 1 - Nome do caso de teste - o prefixo "exp" é adicionado automaticamente e foi definido na criação do projeto de teste
  • 2 - Pré-condição - devem ser listadas todas as pré-condições para a execução do caso de teste. Quando a execução do caso de teste depende da prévia execução de outro caso de teste utiliza-se colchetes para indicar isso. Nesse exemplo, o caso de teste "Enviar mensagem" depende da prévia execução do caso de teste "Acessar módulo Expresso Mail". Dessa forma evita-se a repetição de passos em todos os casos de teste do módulo Expresso Mail por exemplo
  • 3 - Passos - devem ser enumerados os passos do caso de teste utilizando o prefixo "PXX", onde XX é o número do passo
  • 4 - Resultados Esperados - não estamos utilizando essa coluna pois os passos são sequenciais e representam a interação usuário-sistema de modo satisfatório e de fácil entendimento; os passos devem estar escritos de forma clara, sem ambiguidades, de forma que o testador possa executar o teste sem necessidade de recorrer ao analista de teste que criou o caso de teste
  • 5 - Categorização - estabelece prioridades e categorias
  • 6 - Requisitos - não estamos utilizando essa funcionalidade do Testlink

Exemplos de Casos de Teste

Ciclo de Vida

Fluxo de atividades de execução de testes no Testlink

No image "etc_d1.png" attached to ExpressoTestCenter/testlink


Última atualização: 17-Set-2010

Attachments