A Tabela 6 apresenta o comparativo dos requisitos identificados e avaliados nas três ferramentas de gestão de defeitos e nas três ferramentas de gestão de testes. A sigla AT significa atende totalmente, AP atende parcialmente e NA não atende. A coluna “Testicida” representa a ferramenta desenvolvida com a indicação dos requisitos já implementados (AT), os que ainda estão em desenvolvimento (ED) e os que não serão implementados (NA) nessa primeira versão da ferramenta.
Tabela 4. Avaliação de requisitos das ferramentas avaliadas.
Requisitos TestLink Testia
Tarântula Testopia Bugzilla Mantis BugNET Testicida
Cadastrar usuário AT AT NA AT AT AT AT
Definir a disponibilidade de um usuário AT NA NA AT AT AT AT
Definir o perfil de acesso do usuário AT AP NA AT AT AT AT
Armazenar operações realizadas por usuário. AT NA NA AT AT AT AT
Exportar os usuários cadastrados para um arquivo
formato .xml AT NA NA NA NA NA ED
Cadastrar projeto de teste AT AT NA NA NA NA AT
Definir os papéis dos usuários no projeto de teste AT AT NA NA NA NA AT
Definir a disponibilidade de um projeto de teste AT NA NA NA NA NA AT
Definir a visibilidade de um projeto de teste AT NA NA NA NA NA AT
Clonar projeto de teste AT NA NA NA NA NA ED
Cadastrar plano de teste AT AT AT NA NA NA AT
Definir os papéis dos usuários no plano de teste AT NA AT NA NA NA AT
Definir a disponibilidade de um plano de teste AT NA AT NA NA NA AT
Definir a visibilidade de um plano de teste AT NA AT NA NA NA AT
Clonar plano de teste AT NA AT NA NA NA ED
Cadastrar build/versão AT NA AT AT NA AT AT
Definir a disponibilidade de um build/versão AT NA AT AT NA AT AT
Cadastrar marco AT NA AT AT NA AT AT
Cadastrar suíte de teste AT AT NA NA NA NA ED
Cadastrar caso de teste AT AT AT NA NA NA AT
Atribuir suíte de teste a um plano de teste AT AT NA NA NA NA ED
Atribuir caso de teste a um plano de teste AT AT AT NA NA NA AT
Atribuir suíte e caso de teste a usuários para
execução AT AT AP NA NA NA AT
Permitir que o usuário insira o resultado do caso de
teste como passou, falhou ou bloqueado. AT AT AT NA NA NA AT
Associar, no caso de teste, um link para o relato de
defeito AT AT NA NA NA NA AT
Importar / exportar suítes de teste AT NA NA NA NA NA ED
Importar / exportar casos de teste AT NA AT NA NA NA ED
Mover / copiar casos de teste e suítes de teste AT AP AP NA NA NA ED
Visualizar histórico de testes executados. AT AT AT NA NA NA AT
Relacionar caso de teste com caso de teste AT NA AP NA NA NA AT
Cadastrar requisitos AT AT NA NA NA NA AT
Relacionar requisito com caso de teste AT AT NA NA NA NA AT
Relacionar requisito com requisito AT NA NA NA NA NA AT
Relatórios AT AT AT AT AT AT AT
Integração com Bug Trackers AP AP AP NA NA NA NA
Integração com Selenium AP NA NA NA NA NA NA
Cadastrar projetos para relato de defeitos e sugestões NA NA NA AT AT AT AT
Cadastrar subprojeto e associar a um projeto de
defeitos existente. NA NA NA AT AT AT ED
Definir projetos de defeitos ativo ou inativo NA NA NA AT AT AT AT
Definir projetos de defeitos privado ou público NA NA NA AT AT AT AT
Cadastrar relato de defeito NA NA NA AT AT AT AT
Clonar um relato de defeito NA NA NA AT AT NA ED
Monitorar relato de defeito NA NA NA AT AT AT ED
Criar relação entre relatos de defeitos cadastrados NA NA NA NA AT AT AT
Alternar formulário de relato de defeito entre básico
e avançado NA NA NA AT NA NA NA
Anexar arquivos a um relato de defeito NA NA NA AP AP AP AT
Pesquisar relatos de defeitos cadastrados NA NA NA AT AT AT AT
Adicionar comentários a um relato de defeito NA NA NA AT AT AT AT
Notificações por e-mail AP NA NA AT AT AT AT
Fluxo de trabalho para resolução de um caso de
defeito (Workflow) NA NA NA AT AT AT AT
Histórico de mudanças efetuadas no relato NA NA NA AP AT AT AT
Suporte a autenticação através do protocolo LDAP AT NA NA AT AT AT NA
Criação de campos personalizados AT NA NA AT AT AT NA
Validações de preenchimento dos campos AP AP AP AP AP AP AT
Interface responsiva NA NA NA NA NA NA AT
Apresenta versão AT AP AP AT AP AT AT
Suporte à multiplos idiomas AT NA AT AT AT NA NA
Ajuda e Documentação AT AP AP AT AP AT ED
A avaliação das ferramentas encontradas, em especial as apresentadas na Tabela 6, que foram avaliadas mais detalhadamente, reforçaram os dois problemas que motivaram a realização deste trabalho: não oferecem a integração de requisitos, gestão dos testes e gestão dos defeitos em uma mesma ferramenta; e a ausência de boas práticas de usabilidade é evidente. Percebeu-se também que o fato de usar duas ferramentas diferentes agrava o problema da usabilidade porque, por exemplo, os projetos, usuários, permissões precisam ser cadastrados nas duas ferramentas. As interfaces, operações, requisitos e regras de negócio das ferramentas são diferentes. Algumas ferramentas de gestão de testes oferecem integração com ferramentas de gestão de defeitos, mas talvez o termo integração esteja empregado de forma equivocada, de tão simples que é, não elimina a necessidade das duplicidades de cadastros citados, o que eleva a probabilidade de inconsistência entre os dados.
A seguir serão apresentados os requisitos funcionais, não funcionais e as regras de negócio.
Nesta seção, o termo “cadastrar” compreende as operações de inclusão, edição, exclusão e consulta.
Regras de negócio genéricas:
O formato padrão para uma data é dd/mm/aaaa.
Qualquer atributo de data deve ser verificado em relação ao calendário.
Qualquer atributo de e-mail deve ser verificado se é válido.
A data dos cadastros deve ser gerada pela própria ferramenta e não deve ser editável.
O tamanho máximo permitido para anexos, por padrão, é de 10MB.
O atributo disponibilidade pode assumir os valores ativo ou inativo. Qualquer entidade só poderá ser desativada se estiver com o estado ativo e só poderá ser ativada se estiver com o estado inativo. O valor padrão será ativo.
O atributo visibilidade pode assumir os valores público ou privado. O valor padrão será público.
Requisitos não funcionais:
As senhas devem ser criptografadas com o algoritmo sha1.
A interface da ferramenta deve ser responsiva de forma que seja visualizada corretamente em desktops, notebooks, tablets e smartphones.
O preenchimento dos campos deve ser validado em tempo real com a utilização da linguagem JavaScript.
O sistema deve ter suporte à autenticação de usuários através de uma consulta a um servidor LDAP, além da autenticação na base de dados local.
Módulo Usuários
Requisito: o sistema deve permitir que um Administrador possa cadastrar usuários.
Regras de negócio:
Um usuário deve ter as seguintes informações: nome real (string > 1 e <= 64, obrigatório), nome de usuário (string > 1 e <= 32, obrigatório, único), senha (string >= 4 e <= 32, obrigatório), e-mail (string >= 5 e <= 64, obrigatório), perfil de acesso (obrigatório), disponibilidade (obrigatório).
Com relação aos perfis de acesso, serão apresentados os cadastrados na tela Perfis de Acesso.
As opções de consulta devem ser por: nome real, nome de usuário, e-mail, perfil de acesso e disponibilidade.
A exclusão de um usuário só deve ser permitida quando este usuário não tiver outras informações relacionadas com ele.
Requisito: o sistema deve permitir que um Administrador possa definir a disponibilidade de um usuário.
Requisito: o sistema deve permitir que um Administrador possa exportar os usuários cadastrados para um arquivo e importar a partir do arquivo.
Regras de negócio:
O arquivo deve ser gerado no formato XML
Requisito: o sistema deve armazenar os registros das operações realizadas por cada usuário no sistema.
Regras de negócio:
para cada operação devem ser armazenadas as informações: data e hora, usuário, entidade, operação realizada, detalhe da operação realizada.
Módulo Projetos
Requisito: o sistema deve permitir que um Administrador possa cadastrar projetos.
Regras de negócio:
Um projeto deve ter as seguintes informações: nome (string > 1 e <= 64, obrigatório, único), descrição (string <= 2000), disponibilidade (obrigatório) e visibilidade (obrigatório).
Um projeto dispõe de três módulos: requisitos, testes e defeitos. Deve ser possível definir a disponibilidade e visibilidade de cada módulo, de forma independente.
As opções de consulta devem ser por: nome, descrição, disponibilidade e visibilidade.
A exclusão de um projeto só deve ser permitida quando este projeto não tiver outras informações relacionadas com ele.
Requisito: o sistema deve permitir que um Administrador possa cadastrar subprojetos em um projeto.
Regras de negócio:
Não é obrigatório que um subprojeto seja cadastrado para um projeto e não há limite de quantidade de subprojetos por projeto.
As informações que um subprojeto deve ter são as mesmas de um projeto.
Adicionalmente, deverá ter um campo em que possa ser criada a relação com o projeto ao qual pertence.
Requisito: o sistema deve permitir que um Administrador possa atribuir papéis dos usuários no projeto.
Regras de negócio:
o sistema deve permitir que um Administrador possa definir os papéis dos usuários para cada projeto e subprojeto, de forma independente.
Requisito: o sistema deve permitir que um Administrador possa definir a disponibilidade de um projeto e subprojeto.
Requisito: o sistema deve permitir que um Administrador possa definir a visibilidade de um projeto e subprojeto.
Requisito: o sistema deve permitir que um Administrador possa clonar projetos.
Regras de negócio:
Deverá ser apresentado o formulário preenchido com os dados do projeto de origem, exceto o campo nome, que deverá ser preenchido para que o projeto clonado possa ser salvo.
Casos de teste executados, relatos de defeito e relatórios não serão clonados.
Requisito: o sistema deve permitir que um Administrador possa cadastrar versões de software (builds) para o projeto.
Regras de negócio:
Uma versão de software deve ter as seguintes informações: nome(string > 1 e <=
64, obrigatório, único), descrição(string <= 2000), disponibilidade(obrigatório), data(obrigatório).
Requisito: o sistema deve permitir que um Administrador possa definir a disponibilidade de uma versão de software.
Módulo Requisitos
Requisito: o sistema deve permitir que um Administrador possa cadastrar requisitos.
Regras de negócio:
Um requisito deve ter as seguintes informações: identificador (string > 1 e <=
32, obrigatório), título (string > 1 e <= 128, obrigatório), descrição (string <=
2000), estado (obrigatório) e tipo (obrigatório).
O estado de um requisito pode ser: esboço, revisão, retrabalho, finalizado, implementado, válido, não testável e obsoleto.
O tipo de um requisito pode ser: informacional, característica, caso de uso, interface, não funcional, função do sistema.
Após a inclusão de um novo requisito, este será definido como versão 1.
Requisito: o sistema deve permitir que um Administrador possa anexar arquivos a um requisito.
Requisito: o sistema deve permitir que um Administrador possa criar um caso de teste automaticamente a partir de um requisito.
Regras de negócio:
Após criar, o caso de teste será automaticamente relacionado ao requisito.
Requisito: o sistema deve permitir que um Administrador possa criar uma nova versão de um requisito.
Requisito: o sistema deve permitir que um Administrador possa criar uma relação de um requisito com um caso de teste.
Requisito: o sistema deve permitir que um Administrador possa criar uma relação entre requisitos.
Regras de negócio:
os requisitos podem ter a seguinte relação: é pai de, é filho de, bloqueia, depende de, é relacionado a.
Módulo Plano de Teste
Requisito: o sistema deve permitir que um Administrador possa cadastrar um plano de teste.
Regras de negócio:
um plano de teste deve ter as seguintes informações: nome (string > 1 e <= 128, obrigatório), descrição (string <= 128), disponibilidade (obrigatório), visibilidade (obrigatório).
Requisito: o sistema deve permitir que um Administrador possa definir a disponibilidade um plano de teste.
Requisito: o sistema deve permitir que um Administrador possa definir a visibilidade de um plano de teste.
Requisito: o sistema deve permitir que um Administrador possa clonar um plano de teste.
Requisito: o sistema deve permitir que um Administrador possa cadastrar um marco para o plano de teste.
Requisito: o sistema deve permitir que um Administrador possa ativar ou desativar um marco para o plano de teste.
Módulo Caso de Teste
Requisito: o sistema deve permitir que um Administrador possa cadastrar uma suíte de teste.
Requisito: o sistema deve permitir que um Administrador possa exportar uma suíte de teste para um arquivo e importar a partir de um arquivo.
Regras de negócio:
O arquivo deve ser gerado no formato XML.
Requisito: o sistema deve permitir que um Administrador possa cadastrar um caso de teste.
Regras de negócio:
um caso de teste deve ter as seguintes informações: título (), objetivo (), pré- condições (), estado (), prioridade (), tempo de execução estimada ().
um caso de teste pode possuir um ou mais passos para execução. Cada um desses passos deve ter as seguintes informações: número do passo (string ), ações do passo (), resultado esperado ().
Requisito: o sistema deve permitir que um Administrador possa exportar um caso de teste para um arquivo e importar a partir de um arquivo.
Regras de negócio:
O arquivo deve ser gerado no formato XML.
Requisito: o sistema deve permitir que um Administrador possa criar uma relação entre casos de teste.
Regras de negócio: os casos de teste podem ter a seguinte relação: é pai de, é filho de, bloqueia, depende de, é relacionado a.
Requisito: o sistema deve permitir que um Administrador possa atribuir um caso de teste ou uma suíte de testes à um plano de teste.
Requisito: o sistema deve permitir que um Administrador possa atribuir um caso de teste ou uma suíte de testes à um usuário para execução.
Regras de negócio:
ao atribuir o caso de teste a um usuário, o sistema deve automaticamente definir o estado como não executado.
Requisito: o sistema deve permitir que um Testador visualize os casos de teste atribuídos a ele para execução.
Regras de negócio:
o sistema deve apresentar o estado de cada caso de teste com seus estados e permitir que o testador possa filtrar por estes estados.
Requisito: o sistema deve permitir que um Testador possa definir um resultado para a execução de um caso de teste.
Regras de negócio:
Os resultados são: passou, falhou ou bloqueado.
Requisito: o sistema deve permitir que um Testador possa relatar um defeito a partir de um link localizado em qualquer um dos passos de execução do caso de teste.
Regras de negócio:
ao clicar no link deve ser apresentada a tela de relato de defeito com as seguintes informações preenchidas: componente, build, etapa. O campo descrição deve conter o texto “Defeito encontrado durante execução do caso de teste <número>, no passo <número, ações do passo e resultado esperado>”. Apesar de preenchidos automaticamente, o usuário poderá editar qualquer um desses campos. Após o envio do relato, deverá ser associado no caso de teste um link para o relato com o número e título.
Módulo Defeitos
Requisito: o sistema deve permitir que um Testador possa cadastrar um relato de defeito.
Regras de negócio:
Um relato de defeito deve ter as seguintes informações: componente (), build (), etapa (), frequência (), gravidade (), prioridade (), atribuir à (), visibilidade (), título (), descrição ().
Após a inclusão de um novo relato, este será definido com o estado Novo.
O sistema deve enviar, automaticamente, uma notificação via e-mail para o usuário cujo relato foi atribuído.
Requisitos: o sistema deve permitir que um Testador possa anexar arquivo a um relato de defeito.
Requisito: o sistema deve permitir que sejam atribuídos estados que indiquem a etapa da resolução de um relato de defeito (workflow).
Regras de negócio:
os estados podem ser: novo, admitido, confirmado, resolvido, pronto para teste, fechado.
O sistema deve enviar, automaticamente, uma notificação via e-mail sobre a atualização do relato para os usuários envolvidos, exceto para o usuário que efetuou a modificação.
Requisito: o sistema deve permitir que um Administrador possa clonar um relato de defeito.
Requisito: o sistema deve permitir que um Administrador possa cadastrar comentários em um relato de defeito.
Regras de negócio:
os comentários não poderão ser inseridos quando o relato estiver com o estado fechado.
Requisito: o sistema deve permitir que um usuário possa monitorar um relato de defeito.
Regras de negócio:
O sistema deve enviar, automaticamente, notificações via e-mail para o usuário sobre qualquer atualização efetuada no relato de defeito.
Requisito: o sistema deve permitir que um Administrador possa criar uma relação entre relatos de defeito.
Regras de negócio:
os relatos de defeito podem ter a seguinte relação: é pai de, é filho de, é duplicado de, possui duplicado, está relacionado a.
Requisito: o sistema deve permitir que os usuários visualizem o histórico de atualização do relato de defeito.
Regras de negócio:
o histórico deve apresentar as seguintes informações: data e hora, nome de usuário, campo alterado e detalhe da alteração.
Módulo Relatórios
Requisito: o sistema deve gerar relatórios da execução dos planos de teste, casos de teste e defeitos de um projeto.