Gestão de Defeitos em Teste de Software

Gestão de Defeitos é o termo que utilizamos para minimizar riscos de um projeto e adquirir práticas de prevenção de bugs.

Em um projeto muitas mudanças podem ocorrer durante o desenvolvimento do software como alterações de escopo, novas possibilidades de negócio, restrições de tempo, custo e recursos entre outros.

Por essa razão é fundamental saber identificar a severidade dos defeitos encontrados durante os testes para mensurar o impacto que eles poderão causar para o sistema.

Em linhas gerais os processos que determinam uma boa Gestão de Defeitos são:

1- Prevenção de Defeitos – No planejamento de testes devem ser considerados os riscos do projeto e determinar ações para prevenção de defeitos. Uma boa estratégia seria utilizar testes automáticos de regressão e TDD.

2- Linha Base Entregável – É importante logo no inicio do projeto definir linhas entregáveis para teste. Dessa forma é possível focar na funcionalidade entregue não ocorrendo reportes de erros de pontos que ainda não foram desenvolvidos.

3- Identificação do Defeito – Definição das técnicas que serão aplicadas para identificação, reporte, classificação e gerenciamento dos defeitos encontrados.

4- Solução do Erro – Organização das atividades para desenvolvimento da correção de incidentes encontrados.

5- Melhoria do Processo – Análise de métricas e relatórios dos defeitos encontrados com objetivo de mapear a causa raiz dos problemas e promover melhorias contínuas no processo de testes.

Um incidente pode ser classificado de diversas maneiras, por exemplo:

Erro de Configuração de Ambiente – Esse tipo de erro pode ocorrer quando é realizado uma parametrização errada na base de testes que ocasiona um incidente.

Erro de Elaboração de Casos de Testes – O comportamento do sistema foi diferente do resultado esperado no caso de teste e após análise identificou-se que o caso de teste estava errado.

Erro de Especificação – Erro ocasionado devido a falta de especificação no documento de visão ou causado devido a aplicação de alguma regra definida no documento.

Erro de Desenvolvimento – Erro causado em virtude do código implementado de forma errada pelo desenvolvedor.

Esses foram apenas alguns exemplos.

Além da classificação temos a severidade de um incidente que de modo geral são divididos em 4 opções:

Grave – erros em funcionalidades críticas para o negócio, que podem ocasionar perdas ou prejuízos  financeiros ou que impeça a continuidade dos testes ou grande parte dos cenários.

Alta – erros em funcionalidades críticas para o negócio, que podem ocasionar perdas ou prejuízos  financeiros, mas que não impede a continuidade dos testes.

Média – erros em funcionalidades que não ocasionam perdas ou prejuízos financeiros.

Baixa – erros de layout, estética ou exibição que não provoquem nenhum tipo de perda ou prejuízo para o negócio.

A severidade ajuda no momento de priorizar os erros encontrados durante os testes para correção. Caso o prazo de entrega seja muito apertado os erros de severidade Grave e Alta serão os primeiros a serem corrigidos. Se não der tempo de corrigir os erros Médios e Baixos a liberação da entrega será feito com menor risco de qualidade possível. Por isso é muito importante classificar corretamente a severidade de um erro, pois se um incidente de severidade Grave ou Alta for classificado como Médio ou Baixo o risco do projeto aumenta.

Mas porque é tão importante classificar um incidente?

Para implementar melhorias no processo de qualidade, precisamos antes identificar onde mais ocorrem erros.

Caso a incidência de maior defeitos seja decorrente a configuração de ambientes, por exemplo, seria aplicado uma politica de pré configurações ou bases espelho para testes. Dessa forma iríamos diminuir o risco de encontrar erros provenientes de ambiente de testes.

Agora, caso a maior incidência fosse na elaboração de casos de testes poderiam ser aplicados treinamentos, workshops entre outras atividades de aprendizado com o objetivo de capacitar os testadores nas funcionalidades que serão trabalhadas.

Gestão de Defeitos também tem haver com reporte de erro!

Quanto mais detalhado e completo a descrição de um reporte de erro mais fácil será para conseguir reproduzi-lo e identificar a causa raiz do problema. Dessa forma, todos ganham, as correções e retestes são sempre mais rápidas e assertivas e, tanto o programador quanto o testador conseguem seguir com as suas atividades de forma independente sem precisar recorrer ao outro o tempo todo para reproduzir o incidente.

Um bom reporte de erro precisa ter:

1 Sistema e/ou versão, onde o erro foi reproduzido.

2 Base de dados, onde o desenvolvedor possa debugar o erro com mais facilidade.

3 Menu de acesso no sistema.

4 Descrição breve do incidente encontrado.

5 Passo a passo para reprodução do erro.

6 Prints, vídeos, logs do erro para facilitar a análise do desenvolvedor.

Lembrando que um reporte de erro bem detalhado também facilita no reteste do erro, onde muitas vezes pode não ser realizado pelo mesmo testador que o encontrou.

 Sobre Gestão de Defeitos é isso galera. Espero ajudá-los com essas informações.

E lembrem-se: Quanto mais colaborativo for o nosso trabalho mais produtivos seremos, afinal, o nosso objetivo é comum: entregáveis com a melhor qualidade possível.

Por EMANUELLE BERNARDO SPONTON

Formada em Tecnologia e Análise de Desenvolvimento de Sistemas, Certificada em Testes (Foundation Level - CTFL), e-learning em Gestão de Projetos - FGV, cursando Gestão e Estratégia de Empresas - Instituto Unicamp

Postado em: 28 de abril de 2016

Confira outros artigos do nosso blog

Matera participa da 9ª edição do meetup DevTests Campinas

03 de setembro de 2018

Ariane Ferreira Izac

Teste de mutação com PITest

24 de agosto de 2018

Julio Cesar Consolini

Introdução ao Dev-Test Pairing

13 de junho de 2018

Caio Rizolli

Falando sobre Teste de Intrusão (ou PenTest)

03 de abril de 2018

Jacqueline Costa

Deixe seu comentário