A eficiência no desenvolvimento de software permite qualidade, lançamentos pontuais e clientes mais felizes. Uma grande parte dessa eficiência depende, precisamente, da correcção bem sucedida de bugs, e relatórios de defeitos de qualidade ajudam os programadores a fazer essas correcções rapidamente. Ao escrever relatórios de defeitos, os testers podem ser úteis, acrescentando passos detalhados e precisos para reproduzir os problemas que encontram, nos quais se deverá encontrar os resultados esperados como os resultados reais – podem, também, incluir capturas de ecrã e anexos de vídeo para ajudar à compreensão do defeito em questão.
Os detalhes escritos no relatório de defeito ajudam os programadores a compreender a profundidade e amplitude do efeito do bug e a descobrir o código afetado. A localização do código partido numa base de código complexa não é uma tarefa fácil, especialmente quando os programadores trabalham em mais do que um projecto de cada vez. Quanto mais detalhes o relator de defeitos acrescentar ao relatório de defeitos, mais fácil será a reprodução, localização e correcção do bug. Quanto maior for a compreensão do defeito, mais provável é que a equipa o conserte correctamente – e sem gerar novos e relacionados bugs.
Os detalhes necessários para um relatório de defeito compreensível incluem o seguinte: – deve incluir, por exemplo:
- Identificação Única para Rastreio: Isto permite que os testers encontrem o defeito por identificação;
- Nome do Autor do Relatório: Nome e informações de contacto;
- Aplicação e Versão de Código;
- Servidor ou Ambiente: Definir o local onde se realizaram os testes;
- Navegador e SO, se Aplicável;
- Capturas de Ecrã ou Vídeo, Ficheiros de Registo ou Erros: Os registos de ferramentas de desenvolvimento do navegador ou outros ficheiros de registo ajudam os programadores a compreender o defeito – a inclusão de vídeo do defeito em acção, ou capturas de ecrã ajudam, naturalmente, na compreensão visual;
- Resultado/Comportamento Esperado e Resultado/Comportamento Real: Os programadores podem não saber como funciona a aplicação de ponta a ponta, uma vez que tendem a codificar funções específicas. A inclusão do resultado esperado – para além do resultado real – fornece informações cruciais à localização do defeito;
- Severidade/Prioridade: Quão crítico é o defeito?;
- Notas de Resolução de Problemas: Incluir quaisquer notas sobre as medidas de resolução de problemas tomadas, consultas a bases de dados ou resultados de registo de erros.
- Entre outros.
A continuação do artigo original via TechTarget pode ser lido aqui.
