FL-5.6.1 (K3) Escrever um relatório de defeito, cobrindo os defeitos encontrados durante o teste
Sem um processo de relato, classificação atribuição e gerenciamento dos defeitos, desde o seu descobrimento até a sua correção, facilmente se perde o controle sobre eles.
O relato de incidentes cumpre 3 propósitos:
1. Prove aos programadores e gerentes com informações detalhadas sobre o comportamento observado e sobre o defeito;
2. Suporte a análise de tendências sobre os dados do defeito, seja para entender melhor um conjunto de defeitos, ou para entender o nível geral da qualidade do software;
3. Quando analisado sobre o projeto ou entre projetos prove informações úteis para melhoria do processo de teste.
REGRAS PARA ESCREVER UM BOM RELATO DE INCIDENTES
→ A execução do teste deve ser feita de forma atenciosa – nunca se sabe quando irá se descobrir um problema. Após encontrar um problema: reproduza os sintomas do problema identificado.
→ Procure ir além dos casos de teste, buscando condições mais comuns de falhas do sistema, para evitar como resposta a um incidente aberto: “nenhum usuário real irá fazer isso”.
→ Compare sintomas observados em outros defeitos, sintomas de defeitos que já foram corrigidos e que cobrem uma parte similar do software.
→ O impacto do defeito deve ser definido a partir da sua prioridade e severidade.
→ Cuidado com as palavras – procure ser neutro e focado em fatos.
→ Mantenha o relato de incidentes conciso, para evitar que as pessoas se percam em detalhes.
→ Faça um processo de revisão no relato de incidentes antes de sua liberação.
O que colocar em um relato de incidente?
Um relato de incidente descreve alguma situação, comportamento ou evento que ocorreu durante o teste e necessita mais investigação. É comum utilizar algumas telas completa de informações registradas em um ferramenta de acompanhamento de defeitos.
A figura abaixo ilustra o template proposto pela norma IEEE 29119 para relato de incidentes:
→ Quando o incidente é atribuído para resolução o gerente deve definir um nível de prioridade.
→ Os responsáveis pelo controle de mudanças, ou comitê de triagem de defeitos deve documentar os riscos, custos oportunidades e benefícios associados a correção ou não correção do defeitos.
→ O programador quando for corrigir o defeito, pode definir a causa raiz, a fase de introdução e de remoção do defeito.
→ Durante o ciclo de vida do relato de incidente o sistema de acompanhamento de defeitos deve permitir que cada pessoa possa entrar com o estado e a informação histórica do defeito.
O que acontece com o relato de incidente após ser preenchido?
O ciclo de vida de um relato de incidente é mostrado em um diagrama de estado. Entendendo o fluxo de um defeito que é corrigido:
A. Após um incidente ser reported, um testador ou o gerente de teste revisa o relato.
B. Se o relato está ok, ele passa para o estado de opened.
C. Agora o time do projeto deve decidir se corrige ou não o defeito.
D. Se o defeito será corrigido, um programador será assigned para isso.
E. Uma vez finalizado a correção o estado muda para fixed e retorna para o testador para o teste de confirmação.
F. Se o teste de confirmação falha, o relato do incidente é reopened e então reassigned.
G. Se o teste de confirmação é ok, então o incidente é closed.