TestLink
De DTI Wiki
O TestLink pode ser acessado em: http://cvsserver/testlink/login.php, caso não se tenha acesso é necessário solicitar a equipe de testes a criação de um cadastro. Um manual para ele está disponível em http://cvsserver/testlink//docs/testlink_user_manual.pdf.
O projeto de teste (onde habitam os requisitos, casos de teste e planos de teste) usado para projetos novos é o DTI. Ele pode ser selecionado por meio do menu dropdown no canto superior direito como visto na imagem abaixo.
Em projetos novos o TestLink pode ser usado para documentar os: casos de teste, requisitos, e planos de teste.
Tabela de conteúdo |
Processo (a ser discutido)
Seguindo o processo da DTI o grupo dos testadores deve receber um aviso de que haverá um projeto novo durante a fase de concepção. O analista de negócios que determina os envolvidos no desenvolvimento deve mandar um e-mail a equipe de testes pedindo a indicação de um testador para ser vinculado ao projeto. O envolvimento do testador começa quando começam a ser definidos os requisitos (ele pode participar das reuniões de elicitação do documento de visão mas isso é opcional). Durante a fase de definição dos requisitos o testador já pode começar a desdobrar casos de teste a partir dos mesmos. Dúvidas geradas na elaboração dos casos de teste retroalimentam a definição dos requisitos. Exemplo: O testador pode não ter certeza como testar um determinado requisito; a dúvida é levantada durante a reunião de elicitação dos requisitos com o cliente; o documento de requisitos é clarificado. Isso gera uma continua evolução dos casos de teste e requisitos.
Um plano de teste consiste nos casos de teste que se escolheu para executar durante um determinado momento. Nem sempre todos os casos de teste para uma aplicação serão executados. Critérios usados para definir o que incluir ou não no caso de teste incluem, mas não se limitam a: tempo disponível; relevância do caso de teste (ou funcionalidade associada); quais casos falharam ou não foram testados durante os últimos testes.
Os casos de teste e/ou requisitos documentados quando desenvolvidos serão mantidos atualizados. Uma manutenção para um projeto que foi testado e documentado deve ser analisada para verificar se altera os requisitos ou os casos de teste. Preferencialmente isso deve ser feito pelo mesmo testador que testou a aplicação durante o desenvolvimento. O manual do usuário também deveria ser mantido atualizado mas não se decidiu se isso será responsabilidade dos testadores também.
Organização dos Casos de Teste
Em "DTI > Comum" ficam todos os casos de teste que podem se aplicar a aplicações da Intranet ou dos Sistemas informatizados. Pastas de nome "Comum" podem ser criadas em qualquer ponto da hierarquia e acumulam os casos de teste que poderiam ser repetidos entre as suas pastas-irmãs. Um exemplo: A pasta "DTI > Intranet > Comum" guarda os casos de teste que seriam comuns (e repetidas) entre as aplicações da Intranet. Outro exemplo: Caso se percebesse que há casos de teste similares em "DTI > Intranet > Acadêmico" e "DTI > Intranet > Recursos Humanos" eles também poderiam ser removidos e colocada um única cópia em "DTI > Intranet > Comum". Esses casos de teste podem ou não ser aplicáveis a todos os projetos nas pastas irmãs. Quando um caso de teste é considerado aplicável e relevante ele é agregado ao plano de teste que se usará para testar a aplicação.
Em "DTI > Intranet" ficam todos os casos relativos a aplicações da Intranet. A hierarquia de pastas abaixo dela deve ser criada usando o texto exato das ligações utilizadas para chegar até a aplicação que ela se relaciona, a partir da página inicial da intranet. A única exceção a essa regra são os diretórios de nome "Comum". Exemplo: Caso para chegar na aplicação desejada se selecione o menu "Acadêmico" e o submenu "Intercâmbio" e depois o menu dentro da aplicação "Cadastro de alunos" deve se usar os itens entre aspas como títulos das pastas na hierarquia.
Em "DTI > SI" ficam todos os casos relativos a aplicações Delphi dos Sistemas Informatizados. A hierarquia de pastas é similar a usada na intranet. Os textos nos menus e botões clicados para se acessar uma determinada parte do sistema deve ser usada nos títulos das pastas que formam a hierarquia até os casos de teste.
O campo de detalhes das pastas deve ser deixado vazio (exceto quando a pasta é prefixada com "[ORG]" nesse caso é recomendável preencher os detalhes da pasta). É subentendido que um pasta trata de todas as aplicações que podem ser acessadas através do menu/botão/link cujo texto é usado no título da mesma.
O nome de uma pasta pode ser prefixada com "[ORG]", nesse caso se subentende que a única função da pasta é agregar/organizar casos de teste (e/ou outras pastas). Isso significa que o título da pasta não é um link ou menu a ser clicado na Intranet ou no SI. Esse recurso deve ser usado quando há um número muito grande de testes que ocorrem na mesma página/janela. Exemplo: Há mais de 20 testes dentro de "DTI > Intranet > Acadêmico > Intercâmbio > Cadastro de alunos". Todos eles tratam de testes de funcionalidade do módulo naquela página. Dentro da pasta "Cadastro de alunos" se cria uma pasta chamada "[ORG] Idiomas". Nessa pasta ficaram os casos de teste da manutenção de idiomas do aluno (que é acessível, para cada aluno cadastrado, por um ícone na coluna "Idiomas" relacionada a linha do aluno). Essa manutenção fica dentro da página do "Cadastro de alunos", não possuindo URL própria, e necessitando de pelo menos um aluno cadastrado para acessar. Um diretório normal não era adequado (não havia texto do link p/ colocar no título, e se houvesse poderia haver mais de um link com o mesmo texto, um para cada aluno cadastrado) logo se usou uma pasta com "[ORG]" prefixando. O escopo da pasta pode ser clarificado no campo "Detalhes" já que, diferente de uma pasta sem o prefixo, não se pode inferir que a pasta agrega tudo que pode ser acessado por meio do link cujo texto é seu título.
O campo objetivo do teste deve permanecer vazio a menos que o título e passos por si só não sejam auto-explicativos.
O campo "Pré-condições" não deverá possuir a seguinte pré-condição: visitar a página X ou a janela Y, que é acessada a partir do clique nos links/menus com o texto igual ao título das pastas ascendentes. Se subentende que para executar o caso de teste o usuário deve estar na página/janela/sistema/módulo indicado pela hierarquia de pastas. Caso haja mais de um nível de permissões é preciso especificar com que permissões o teste deverá ser feito, caso contrário se subentende o que é especificado nos requisitos (os requisitos devem especificar quais usuários tem acesso a aplicação, se não for um número específico pode ser um grupo).
Cada passo de um teste deverá ter algo em "Resultados esperados" a menos que seja algo esperado do preenchimento de qualquer formulário (ao escrever o valor em um campo ele deverá permanecer lá, ao selecionar o elemento de uma lista ele deverá ficar selecionado, ao clicar em uma checkbox ela deverá ficar marcada, etc). Caso se clique um botão ou uma aba deve se informar que janela deve abrir ou ação ocorrer. Uma sequência de passos deve ser inserida na forma de uma sequência de passos e não de uma lista de ações dentro de um único passo.
Organização dos Requisitos
O padrão de organização das pastas dos requisitos é semelhante ao dos casos de teste. A única diferença é que os requisitos exigem um código a ser inserido que não pode ser repetido (esse código é necessário a pastas e especificações e não pode ser igual ao de nenhuma pasta ou especificação). O padrão para definição do código é "<código da pasta pai>:<sigla de duas ou três letras retiradas do título>". A "Intranet" tem sigla "IT" e os "Sistemas informatizados" tem sigla "SI". Todas pastas "Comum" tem sigla "CM" (precedidas do código das pastas anteriores).
Planos de teste
Planos de teste são criados com o intuito de expor e documentar o que foi testado em uma determinada data. Eles também permitem reunir um conjunto de casos de teste e indicar para cada caso de teste quais passaram, quais não passaram, e quais não puderam ser testados devido a um comportamento errôneo anterior. Quando uma aplicação possui casos de teste documentados e se pretende executá-los é recomendado usar esse recurso.
