Gestão de defeitos: Ferramentas Open Source e melhores práticas na gestão de defeitos

O principal objetivo do teste de software é medir o nível de qualidade de um sistema, seja a aplicação executável ou os artefatos utilizados na sua construção. A qualidade de um sistema pode ser medida, essencialmente, pelo número de falhas encontradas durante a execução dos testes.

Falha, nesse contexto, é a conseqüência de um erro, defeito ou engano. Ou seja, é o desvio entre o que foi solicitado pelo usuário por meio dos requisitos e o comportamento apresentado pela aplicação executável. Em virtude da complexidade e tamanho de um sistema ou para atender normas de qualidade ou processos de maturidade, se faz necessário utilizar um processo de gestão de defeitos integrado ao ciclo de vida de desenvolvimento e teste.

Neste contexto, entender as atividades de um processo de gestão de defeitos e escolher a ferramenta adequada para automatizar a gestão do ciclo de vida de um defeito são tarefas fundamentais, como veremos mais adiante.

Neste artigo, você conhecerá os conceitos, atividades e terminologia de um processo de gestão de defeitos. Também será apresentado um exemplo prático utilizando o Mantis, ferramenta Open Source para gestão de defeitos. E, por fim, serão apresentadas outras alternativas Open Source e comerciais caso o Mantis não atenda as suas necessidades.

Processo de Gestão de defeitos

Um processo de gestão de defeitos tem o objetivo de definir práticas para prevenir os defeitos e minimizar os riscos de um projeto. A utilização de uma ferramenta automatizada, além de oferecer uma base comum para a entrada de informações, também oferece um meio para fomentar a integração entre o time de desenvolvimento e o time de testes. Além disso, por meio dos relatórios de gestão e métricas geradas por essas ferramentas, os gestores do projeto poderão promover a melhoria contínua do processo estabelecido.

Genericamente, o termo Erro (Error) é utilizado para indicar uma diferença entre valor computado, observado ou medido em relação ao esperado. No entanto, o padrão IEEE 610.12-1990 (IEEE Standard Glossary of Software Engineering Terminology) distingue a terminologia da seguinte forma:

• Defeito (Fault): Passo, processo ou definição de dados incorretos. Por exemplo, uma instrução incorreta no código ou uma falta num artefato estático;
• Engano (Mistake): Ação humana que produz um resultado incorreto, como por exemplo, uma ação incorreta tomada pelo desenvolvedor ou analista;
• Falha (Failure): Desvio entre o resultado/comportamento apresentado pela aplicação em relação aos requisitos. A falha ocorre em conseqüência de um erro, defeito ou engano gerando um comportamento incorreto da aplicação.

Neste artigo, o termo defeito será usado de forma genérica, podendo representar um erro, engano, defeito ou falha. Segundo o livro, “Base de Conhecimento do CSTE” do QAI, os elementos chave de um processo de gestão de defeitos são (Figura 1):

• Prevenção de defeitos: Com base nos levantamento dos riscos críticos do projeto, devem ser promovidas ações de prevenção e planejamento de contingências para minimizar o impacto caso os riscos tornem-se problemas;
• Linha base entregável: Estabelecimento formal de linhas base (baselines) por meio da Gerência de Configuração de Software. Cada linha base deve determinar quais requisitos/artefatos serão liberados e submetidos ao teste;
• Identificação do defeito: Definição das técnicas necessárias para encontrar, reportar e classificar os defeitos, assim como, os critérios para reconhecê-los;
• Solução do defeito: Definição das atividades para a correção e posterior notificação da resolução do defeito. Muitas destas atividades são definidas pela Gerência de Configuração de Software para garantir o histórico e rastreamento das modificações por meio do controle de versões;
• Melhoria do processo: Análise das métricas e relatórios de gestão para entender a causa raiz dos problemas e promover a melhoria contínua do processo;
• Relatório de gestão: Geração de relatórios com dados relevantes para acompanhar o progresso dos testes e a qualidade do sistema, assim como, a geração de métricas para alimentar a atividade de melhoria do processo.

Ciclo de vida de um defeito

Como discutimos anteriormente, a qualidade de um sistema pode ser medida, essencialmente, pelo número de defeitos encontrados durante a execução dos testes.

Podemos afirmar que os defeitos são encontrados por meio da execução formal dos testes (testes estruturais ou funcionais), durante a utilização do sistema em produção ou, até mesmo, por acidente. A priori, podemos classificar os defeitos nas seguintes categorias:

• Faltante (Missing): O defeito ocorre em virtude da falta parcial ou total de um requisito;
• Errado (Wrong): O defeito ocorre porque o requisito foi implementado incorretamente;
• Acréscimo (Extra): O defeito ocorre em virtude de um comportamento ou elemento que foi implementado, mas foi não especificado no requisito.

Uma vez que o defeito for encontrado, seja por intenção ou por acidente, o próximo passo deverá ser o relato (ou reporte) desse defeito por meio de algum mecanismo estabelecido no processo de gestão de defeitos.

Este mecanismo poderá ser, desde uma simples planilha, até uma ferramenta automatizada. Por motivos óbvios, uma ferramenta automatizada e construída para esse propósito será, sem sombra de dúvida, muito mais eficiente do que uma simples planilha ou solução alternativa.

De qualquer forma, tão logo o defeito seja relatado, ele deverá ser submetido a um ciclo de vida pré-definido pelo processo de gestão de defeitos. Este ciclo de vida define os fluxos que o defeito deverá percorrer até o seu fechamento.

A Figura 2 descreve genericamente um ciclo de vida de um defeito aderente ao processo de gestão de defeitos apresentado anteriormente. Devemos lembrar que esse é um exemplo didático, existem fluxos alternativos e papéis que não estão presentes nesta figura.

Recomendações para o relato de defeitos

Notamos que, muito embora o relato de um defeito seja um dos passos fundamentais do processo de gestão de defeitos, normalmente ele é relegado para segundo plano. A listagem abaixo apresenta as diretrizes que devem ser seguidas durante o relato de um defeito com base nas recomendações descritas no livro “Base de conhecimento em teste de software”:

• Resumir: Descreva claramente o defeito, mas de forma resumida;
• Precisão: Certifique-se que o defeito identificado realmente é um desvio do comportamento esperado e não uma falha de entendimento;
• Neutralizar: Relate apenas os fatos, evitando manifestações de humor, emoção, etc;
• Generalizar: Procure entender o problema de forma genérica, em virtude de que este problema também pode acontecer em outras situações ou funcionalidades.
• Reproduzir: Garanta que o defeito seja reproduzível e descreva os passos necessários para a sua reprodução;
• Evidenciar: Evidencie a existência do defeito encontrado por meio de arquivos de saída, printscreens das telas, etc;
• Revisar: Revise a descrição e os passos para reproduzir o defeito. Lembre-se que o relato do defeito é um documento do projeto, assim como um caso de uso, um plano de testes, etc. Trate-o como tal;

Severidade X Prioridade

A classificação da severidade e prioridade dos defeitos é, de forma similar ao relato de defeitos, um ponto normalmente negligenciado e foco de interpretações incorretas. A classificação incorreta da severidade e da prioridade normalmente contribui para a ineficiência da priorização e agendamento da correção dos defeitos. O efeito colateral direto desse problema é a má utilização dos recursos em função do enfoque na correção de defeitos menos prioritários.

A grosso modo, podemos afirmar que a severidade de um defeito define o impacto do defeito no funcionamento da aplicação. Por outro lado, a prioridade indica a ordem de correção do defeito (defeitos com alta prioridade são corrigidos imediatamente ou num curto prazo de tempo). De modo geral, defeitos com alta severidade são classificados com alta prioridade. No entanto, podem existir diversas situações onde não podemos aplicar essa regra. Por exemplo, a corrupção dos dados de uma aplicação no Windows 3.11 é um defeito com alta severidade mas, no entanto, deve ter baixa prioridade em virtude de que 99,9% dos usuários da aplicação utilizam versões mais atuais do Windows. A justificativa para esse critério é: Por que priorizar a correção de um defeito que vai beneficiar apenas 0,01% dos usuários?

Para evitar a subjetividade da classificação, sugere-se que os critérios para cada nível de prioridade e severidade sejam definidos na documentação do processo de gestão de defeitos. Para fins didáticos e de entendimento, serão apresentados na Tabela 1 e Tabela 2 exemplos de critérios para classificar a severidade e a prioridade dos defeitos respectivamente.

Mantis

O Mantis é uma ferramenta Open Source automatizada escrita em PHP cujo principal objetivo é dar suporte ao processo de gestão de defeitos. O Mantis controla o ciclo de vida de um defeito, desde o seu relato até o seu fechamento, por meio de fluxos (workflows) personalizáveis, como pode ser observado na Figura 3.

O endereço do site do Mantis está disponível na seção Links. Caso você tenha interesse de conhecê-lo com maior profundidade, os passos para a instalação são os seguintes:

1. As pré-condições para a instalação são (PHP 4.0.6 ou superior, MySQL 3.23.2 ou superior, Apache ou IIS).
2. Faça o download do Mantis no site disponível na seção Links.
3. Descompacte o arquivo zip do Mantis na pasta www ou htdocs do servidor WEB (Apache ou IIS).
4. Abra o seu navegador e acesse o seguinte endereço: (http://localhost/mantis_1.0.5/).
5. Na janela Pre-Installation Check, preencha os campos username com o nome da conta de usuário para acesso ao banco de dados MySQL e o campo password com a senha.
6. Deixe os valores default nos demais campos.
7. Pressione o botão Install/Upgrade Database.
8. Ao final do processo, abra o seu navegador e acesse o seguinte endereço: (http://localhost/mantis_1.0.5/login_page.php).
9. Faça o primeiro login com o usuário padrão (administrator/root). Lembre-se de mudar a senha deste usuário.

O Mantis é instalado em inglês por padrão. Caso você prefira utilizar o Mantis com os textos traduzidos para a língua portuguesa, então siga os passos descritos abaixo:

1. Faça o login normalmente com o seu usuário e senha.
2. Clique no menu “My Account” e então selecione a opção “Preferences”.
3. No campo Language selecione a opção "portuguese_brazil".
4. Pressione o botão "Update Prefs".

Entre as diversas funcionalidades oferecidas pelo Mantis, devemos destacar as seguintes:

• Pode ser executado em qualquer plataforma que suportar PHP/Apache/Mysql (Windows, Linux, Mac, Solaris, AS400/i5, etc);
• Suporta vários bancos de dados (MySQL, MS SQL, PostgreSQL);
• Suporta múltiplos mecanismos de autenticação (Interna, LDAP, HTTP Basic, Active Directory);
• Traduzido em 68 línguas diferentes (incluindo "portuguese_brazil");
• Criação ilimitada de projetos e relatos de defeitos;
• Controle de acesso e níveis de permissões para os usuários;
• Ciclo de vida dos defeitos (worflow) personalizável;
• Gerador interno de relatórios e gráficos (possibilidade para exportar os dados nos formatos CSV, Excel e Word);
• Mecanismo para a criação de campos personalizáveis (custom fields);
• Notificações por email automáticas ou por meio de RSS Feeds;
• Integração com ferramentas de controle de versões (Subversion e CVS);
• Interface Webservice (SOAP) para integração com outras ferramentas;
• MantisWAP – Suporte a dispositivos móveis (funcionalidade paga);

A fim de dar ao leitor uma exposição sobre as principais funcionalidades do Mantis e como elas atendem os principais fluxos de um ciclo de vida de um defeito, vamos simular na prática o relato de um defeito e acompanhar todos os passos até o seu fechamento.

Tão logo um testador ou usuário encontre um defeito, seja por intenção ou por acidente, o próximo passo deverá ser o relato (ou reporte) desse defeito.

No nosso cenário, vamos relatar um defeito (problema no recurso de seleção de textos quando existe uma tabela no topo do documento) do OpenOffice Writer (processador de texto Open Source).

Para realizar tal tarefa, você deverá selecionar o menu “Relatar Caso” do Mantis. Uma vez que a janela de relato for exibida, você deverá informar o resumo do defeito, a descrição, os passos para reproduzir e assim por diante, como pode ser observado na Figura 4.

É importante lembrar que o correto preenchimento dos campos severidade (gravidade) e prioridade neste passo é de extrema importância para a priorização e agendamento da correção do defeito.

Assim que o defeito for relatado, o analista de teste (ou líder de desenvolvimento) poderá filtrar os defeitos cadastrados recentemente para confirmar e reconhecer se o que foi relatado realmente é um defeito ao invés de um mal entendimento do comportamento esperado.

Se for confirmado que o relato não é um problema, ele é imediatamente fechado. Caso contrário, o analista de teste (ou líder de desenvolvimento) deverá confirmar se a severidade (gravidade) e prioridade foram classificadas corretamente e atribuir o defeito a um desenvolvedor, como pode ser visto na Figura 5.

Nesta altura, também poderão ser realizadas a projeção da complexidade e a estimativa do tempo necessário para finalizar a correção do defeito.

O desenvolvedor, por sua vez, receberá um e-mail automaticamente conforme o fluxo (workflow) definido no Mantis, como pode ser observado no exemplo apresentado na Figura 6. De qualquer forma, o desenvolvedor poderá visualizar os defeitos atribuídos a ele diretamente no Mantis por meio da página “Minha Visão”. Nesta página (Figura 7), são apresentados e consolidados todos os defeitos, inclusive os defeitos associados ao usuário logado no Mantis.

Assim que o desenvolvedor receber o e-mail notificando que a correção do defeito foi programada e atribuída a ele, o próximo passo será a execução da correção propriamente dita.

Dessa forma, tão logo a correção seja finalizada, o desenvolvedor deverá reportar a correção do defeito por meio do Mantis. Para tal tarefa, o desenvolvedor deverá mudar a resolução do defeito para “Corrigido” e descrever quais foram as modificações necessárias para corrigir o defeito no campo “Anotação”, como pode ser visto na Figura 8.

Por fim, assim que for reportada a correção do defeito, o testador deverá executar o re-teste. Durante o re-teste, o testador poderá identificar que o defeito não foi corrigido corretamente ou foi parcialmente corrigido. Neste caso, o defeito deverá ser reaberto e o ciclo de vida do defeito é reiniciado.

Por outro lado, o defeito deverá ser fechado caso ele tenha sido corrigido corretamente. Para realizar tal tarefa, o testador deverá mudar o status do defeito para “Fechado” e descrever algum comentário sobre o fechamento no campo “Anotação”, como pode ser visto na Figura 9. Dessa forma, chegamos ao final da simulação de um ciclo de vida de um defeito e a apresentação das principais funcionalidades do Mantis.

Métricas e relatórios de gestão

A norma IEEE Std 829-1998 (IEEE Standard for Software Test Documentation) define a documentação e relatórios necessários para a execução de um projeto de teste de software. Dentre os relatórios sugeridos, existe um relatório chamado “Relatório de Incidente de Teste”. Este relatório registra e consolida as ocorrências que precisam de algum tipo de investigação. Ele é normalmente utilizado para registrar os defeitos encontrados durante a execução dos testes.

Ferramentas automatizadas de gestão de defeitos, tais como o Mantis, geram diversos relatórios e gráficos com métricas que poderão fornecer dados para alimentar o Relatório de Incidente de Teste.

O Mantis, além de oferecer um relatório com o resumo consolidado de todos os defeitos relatados (Figura 10), também permite a visualização de gráficos com as principais métricas utilizadas na gestão de defeitos (Figura 11). Na listagem a seguir, são apresentadas diversas sugestões de indicadores e métricas de um processo de gestão de defeitos eficaz, afinal, você não pode gerenciar o que você não pode medir:

• Densidade dos defeitos: Indica o número de defeitos por uma unidade. É normalmente utilizado para identificar a quantidade de defeitos por cada mil linhas de código (KLOC);
• Taxa de abertura dos defeitos: Utilizado para acompanhar o progresso da execução dos testes e o nível da qualidade do sistema em teste;
• Taxa de correção dos defeitos: Utilizado para acompanhar e medir a capacidade do time de desenvolvimento de corrigir os defeitos encontrados;
• Taxa de defeitos re-abertos: Utilizado para acompanhar a qualidade da correção dos defeitos. Pode identificar baixa qualidade no trabalho dos desenvolvedores ou baixa qualidade nos relatos dos defeitos (o que leva a uma correção incorreta);
• Taxa de defeitos abertos agrupados por testador: Identifica a taxa de abertura de defeitos por testador. Deve ser analisada em conjunto com outros dados, caso contrário, vai privilegiar testadores que encontram dezenas de defeitos bobos em detrimento dos testadores que encontram poucos defeitos (porém são defeitos complexos e difíceis de reproduzir);
• Taxa de defeitos corrigidos agrupados por desenvolvedor: Identifica a taxa de correção dos defeitos por desenvolvedor. Deve ser analisada em conjunto com outros dados, caso contrário, vai privilegiar desenvolvedores que corrigem dezenas de defeitos bobos em detrimento dos desenvolvedores que corrigem poucos defeitos (porém são defeitos de difícil resolução);
• Severidade por módulo: Utilizado para identificar os módulos que contém muitos defeitos com severidade alta. Com base nesses dados, podemos tomar alguma decisão para identificar a causa raiz dos problemas e promover alguma modificação no processo para diminuir a quantidade de defeitos com severidade alta no módulo;
• Prioridade por módulo: Identifica módulos com alta taxa de defeitos com prioridade alta. Com base nesses dados, podemos realocar os recursos a fim de atender a demanda. Normalmente é analisada em conjunto com a métrica de Severidade por módulo;
• Vazamento de defeitos: Utilizada para medir a efetividade da abordagem de testes em cada fase de teste (Unidade, Integração, Sistema e Aceitação). Dessa forma, podemos identificar que a abordagem e cobertura de testes utilizada na fase de testes de Sistema não foram muito eficientes em virtude de que muitos defeitos “vazaram” e foram encontrados durante a fase de testes de Aceitação;
• Bug Convergence: Identifica o ponto de declínio da taxa de abertura dos defeitos. Este é o ponto onde a quantidade de defeitos abertos tende a ser menor do que a quantidade de defeitos corrigidos. Dessa forma, espera-se que a partir desse ponto a quantidade de defeitos abertos diminua até chegar a zero;
• Zero Bug Bounce: Utilizada para acompanhar os picos e vales do gráfico de defeitos encontrados a partir do momento do declínio da taxa de abertura dos defeitos (Bug Convergence). Os vales desse gráfico representam os pontos no tempo onde não existem defeitos conhecidos com status igual a aberto, ou seja, estes são os melhores momentos para liberar o sistema para a próxima fase ou para o cliente;

Conclusão

Neste artigo foram apresentados os conceitos e melhores práticas na gestão de defeitos. O objetivo principal do artigo era destacar a importância da gestão de defeitos como um processo de apoio ao desenvolvimento e teste de software. Para facilitar o entendimento do leitor, foram demonstrados na prática os conceitos discutidos por meio da utilização do Mantis (ferramenta Open Source para gestão de defeitos).

Se o leitor quiser se aprofundar no assunto, são apresentadas na Tabela 3 algumas das principais ferramentas comerciais e Open Source para a gestão de defeitos. Não foram esgotadas todas as opções disponíveis, mas já é um bom ponto de partida para auxiliar o leitor a encontrar a solução ideal para a sua necessidade.