[[PageOutline(1-3, Conteúdo)]]
= 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 [wiki:ExpressoTestCenter/piloto 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'''.

[[Image(tp1.png)]]

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''||Para 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 Ambiente''||Identificar a preparação/configuração do ambiente, descrevendo quais atividades devem ser feitas antes ou após a realização do teste||
||''3.3 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''||Obrigató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 parada''||Obrigató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ê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||
||''8 Glossário''||Incluir 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):

[[Image(ct1.png)]]

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.

[[Image(ct2.png)]]

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.

[[Image(ct21.png)]]

 * '''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''||||

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:

[[Image(ct3.png)]]

 * '''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

[wiki:ExpressoTestCenter/tests Exemplos de Casos de Teste]

== Ciclo de Vida ==

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

[[Image(etc_d1.png)]]

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