Solicitação de Projeto
De DTI Wiki
Tabela de conteúdo |
TestLink
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.
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 escopo das pastas deve ser deixado vazio. É 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.
Organização dos Requisitos
O padrão de organização 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.
