A ferramenta deixa o usuário um pouco confuso ao acessá-la, pois a tela de autenticação não é a primeira a ser apresentada. A autenticação pode ser realizada pelo link “Log in” localizado sem nenhum destaque entre os links do menu superior. Outra forma é clicando na opção “New” para relatar um defeito, que irá apresentar a tela de autenticação.
Na tela de pesquisa de relatos de defeitos, acessada pelo link “Browse”, o usuário encontra uma lista com os projetos cadastrados na qual precisa encontrar o projeto desejado como mostrado na Figura 50. Quanto maior esta lista, maior a probabilidade de o usuário demorar para encontrar o produto desejado.
Figura 50. Bugzilla: página de seleção de projeto para pesquisa de defeitos.
Após clicar no produto desejado, será apresentada a página com a lista dos componentes pertencentes a este produto, como pode ser visto na Figura 51. Mesmo problema citado na escolha do produto. Uma solução seria ter na tela anterior uma combo box para escolha do produto e do componente, com a opção de auto completar o que está sendo digitado.
Figura 51. Bugzilla: página de seleção do componente do projeto para pesquisa dos defeitos.
Para relatar defeitos, o usuário deve clicar em “New” e, novamente, é apresentada a página para seleção do produto antes de acessar a página em que vai preencher o relato. É possível anexar arquivos ao relato, como mostra a Figura 52, mas somente um por vez, seja no cadastro ou na edição.
Na edição, ao clicar no anexo para visualizá-lo (caso seja uma figura), o usuário é levado para outra página onde é apresentada a figura e não há botões ou links para voltar para o relato de defeito. O usuário então tem que clicar no botão voltar do navegador para voltar para o relato. O mesmo acontece quando o usuário deseja inserir um novo anexo ao relato. Quando clica no link, é levado para outra página e, da mesma forma, não há link para retornar ao relato e tem que recorrer ao botão do navegador.
Figura 52. Bugzilla: permite anexar apenas um arquivo por vez no relato de defeito.
A visualização do histórico de modificações do relato de defeito é acessada através do link
“History” no qual o usuário também é levado para outra página como mostrado na Figura 53.
Figura 53. Bugzilla: histórico de modificações do relato de defeito.
Os títulos das páginas correntes são apresentados acima do menu superior, fora da área do conteúdo que o usuário está visualizando como pode ser visto na Figura 54.
Figura 54. Bugzilla: títulos das páginas são apresentadas acima do menu superior.
Figura 55. BugNET: Página principal.
3.4.6.1 Funcionalidades
Cadastrar usuários: permite cadastrar usuários com os seguintes atributos: nome de usuário, nome verdadeiro, e-mail e senha.
Ativar e desativar usuários: permite ativar ou desativar usuários.
Perfis de usuários: permite definir níveis de acesso aos usuários do sistema como visualizador, relator, atualizador, desenvolvedor, QA, administrador.
Suporte a autenticação através do protocolo LDAP: permite a autenticação de usuários no sistema por meio de consulta a uma base LDAP externa.
Cadastrar projetos para relato de defeitos: permite cadastrar projetos para relatos de defeitos.
Cadastrar subprojeto ou categorias e associar a um projeto de defeitos existente: permite cadastrar categorias e associar a um projeto de defeito existente.
Definir projetos de defeitos ativo ou inativo: permite definir se o projeto está ativo ou inativo Definir projetos de defeitos privado ou público: permite definir a visibilidade do projeto como público ou privado.
Anexar imagem ao projeto: permite anexar uma imagem qualquer para ser apresentada junto ao nome do projeto, auxiliando assim na identificação do mesmo.
Perfil de acesso, personalizado por usuário, para cada projeto cadastrado: permite definir perfis de acesso aos projetos, por usuário.
Suporte à integração do projeto de defeito com Subversion: permite configurar integração com servidor de versionamento de código.
Cadastrar relato de defeito: permite que o usuário cadastre relatos de defeito com os seguintes atributos: título, estado, usuário que criou, prioridade, marcos afetados, atribuído à, categoria, data de vencimento, tipo do defeito, porcentagem concluída, marcos, estimação, resolução, descrição.
Anexar arquivos ao relato de defeito: permite anexar arquivos ao relato de defeito.
Definir relato de defeito público ou privado: permite definir se a visibilidade do relato será publica ou privada.
Adicionar comentários a um relato de defeito: permite aos usuários adicionar comentários no relato de defeito.
Monitorar relato de defeito: permite que o usuário receba e-mails notificando sobre qualquer modificação realizada no relato.
Criar relação entre relatos de defeitos cadastrados: permite criar relação com outros defeitos cadastrados.
Pesquisar relatos de defeitos cadastrados: permite que os relatos sejam listados e possam ser utilizados filtros para pesquisar relatos de defeito.
Notificações por e-mail: permite que os usuários possam receber notificações por e-mail sobre modificações no relato.
Fluxo de trabalho para resolução de um caso de defeito (Workflow): permite que sejam definidos o estado e atribuição do defeito a um usuário para resolução.
Histórico de mudanças efetuadas no relato: apresenta os registros de todas as operações feitas por cada usuário no sistema.
Criação de campos personalizados: permite que seja criado um novo campo do tipo: string, integer, double, date, currency, e o label que será apresentado para o campo.
3.4.6.2 Avaliação de usabilidade
Logo na página inicial, como foi mostrado na Figura 55, é possível identificar a ausência de boas práticas de usabilidade. O menu superior, onde encontram-se as opções, possui fonte pequena, na cor cinza claro sobre fundo preto. Dependendo do ajuste de brilho/contraste da tela, isso dificulta a legibilidade das opções. A ferramenta apresenta a relação de todos os projetos cadastrados, porém, na página inicial, não há como ordenar por ordem alfabética, data de criação/atualização.
Em relação a anexar arquivos, a ferramenta possui a mesma limitação que outras avaliadas, permite apenas um arquivo por vez, como pode ser visto na Figura 56.
Figura 56. BugNET: permite anexar apenas um arquivo por vez no relato de defeito.
Em comparação com as outras ferramentas, a BugNET sem dúvidas apresenta interface mais atual e passa a impressão de ferramenta mais moderna que as outras avaliadas até aqui. De modo geral, foram encontradas boas práticas de usabilidade em todas as telas visitadas. Certamente fornecerá boas ideias para a implementação da ferramenta proposta por este trabalho.
4 A FERRAMENTA TESTICIDA
Este capítulo apresenta o trabalho implementado. O nome dado à ferramenta foi Testicida.
Serão apresentadas as linguagens de programação a serem utilizadas, o levantamento de requisitos, a modelagem do sistema e a avaliação a ser aplicada para testar e avaliar a execução do trabalho e o desenvolvimento das etapas referentes ao TCC I.
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.