Version 12 (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.
Na parte da descrição do Plano de Teste deve-se utilizar o seguinte padrão:
Seção | Comentários |
Histórico de Versões | Tabela com as seguintes colunas: Data, Versão, Descrição, Autor, Revisor, Aprovado por |
1 Objetivo | Descrever 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ção | Listar 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 escopo | Listar 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ção | |
3.2 Ferramentas | Indicar 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 evidencia | |
3.3 Critério de parada | |
4 Riscos e contingências | Identificar 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 Cronograma | Identicar 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ções | Preenchimento opcional caso existam demais considerações que não foram contempladas nos itens acima e que devam ser registradas. |
7 Referências | Lista documentos eventualmente referenciados no Plano de Teste |
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ção | Comentários |
Histórico de Versões | Tabela 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 |
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
Última atualização: 14-Set-2010