Descrever um bug de software corretamente facilita a resolução do problema e garante a qualidade e continuidade do projeto.
É preciso descrever de maneira clara e concisa um bug de software, para que o programador veja o problema acontecer, facilitando a resolução do mesmo, não adianta fazer relatórios com informações, se estas não retratam o problema em questão, o programador precisa de informações focadas e não especulações.
Segue algumas dicas para relatar um bug corretamente e com qualidade.
1. Tente reproduzir o problema
Se você não pode reproduzir o bug, é quase impossível encontrar o problema raiz e, portanto, difícil corrigi-lo. Tente reproduzir o bug o máximo possível e mostrar uma maneira detalhada de acioná-lo.
Verifique as informações que o software oferece e certifique-se de incluir todas as informações relevantes, tais como erros de memória, erro de execução, erros de código-fonte, versões do software, logs gerados, etc. O registro gerado pode ser útil para o programador entender exatamente o que acontece.
2. Verifique se o bug já foi relatado
Verifique a versão do sistema instalada e se está atualizada com a versão mais recente, talvez o bug tenha sido concluído, é uma boa ideia tentar reproduzir numa versão mais recente.
Verifique os relatórios criados para evitar duplicação e retrabalho aos programadores.
3. Descreva o problema para o programador reproduzi-lo
Uma das melhores maneiras de relatar bug é demonstrá-los aos programadores. Descreva o problema, incie a rotina e mostre o problema ao programador, para que o mesmo encontra-se a raiz do problema.
Detalhe o problema para o programador ver o mesmo acontecer, quando eles podem ver o problema acontecendo em frente aos seus olhos, fica mais fácil lidar com ele. Diga o que você acessou, quais botões, o que foi acionado e em que ordem o fez, sempre que possível você deve fornecer uma transcrição fiel do erro, mostrando quais comandos você digitou e o que o computador exibiu em resposta. Anote as mensagens exibidas para não esquecer, não adianta relatar que o software apresentou bug se você não puder relatar de forma concisa e demonstrativa.
4. Seja gentil e disposta a ajudar
Mesmo descrevendo o problema de forma clara, o programador poderá precisar de sua ajuda para obter informações suplementares (em especial se ele não pode reproduzi-lo) e você deverá estar pronto para fornecê-la.
5. Use a gravidade correta
Defina corretamente a prioridade do bug, alguns problemas precisam ser corrigidos com máxima urgência, outros não, problemas que afetam o negócio principal devem ter prioridade maior, já problemas comuns que não implicam em paralisação das atividades podem ser corrigidos depois.
Não subestime a gravidade de um problema, por mais simples que seja, pode estar gerando muitos transtornos para um determinado cliente, porém, outros gerados com prioridade alta não implicam em grandes transtornos, cada caso deve ser analisado com clareza e sensatez.
6. Sumário resumido
O objetivo principal de um relatório de bug é permitir que os programadores possam ver o problema com seus próprios olhos. Se você não pode estar com eles pessoalmente para reproduzir o bug, dê-lhes instruções detalhadas para que possam reproduzir o bug por si próprios.
1. Seja claro: Descreva o problema do modo mais simples possível, para que o programador consiga entender o que você quis dizer, com clareza e precisão;
2. Seja específico: Se você puder fazer a mesma coisa de duas maneiras diferentes, diga qual delas usou. “Eu selecionei a opção Carregar” pode significar “Eu cliquei o botão Carregar” ou “Eu pressionei Alt-L”. Diga qual delas você usou. Algumas vezes isso é importante. Descreva tudo em detalhes, quais os caminhos você utilizou, as mensagens de erros exibidas, o que esperaria ver acontecer;
3. Seja prolixo: Dê mais informação em vez de menos. Se você der informações demais, o programador pode ignorar algumas delas. Se você der informações de menos, eles tem que voltar a você e perguntar mais;
4. Tente resolver: Tente por todos os meios diagnosticar ao problema por você mesmo se acha que pode fazê-lo; mas mesmo que faça isso, você ainda deve relatar os sintomas;
5. Tente Reproduzir: Garanta que o defeito seja reproduzível e descreva os passos necessários para a sua reprodução, demonstre a existência do problema encontrado por meio de arquivos de saída, printscreens das telas, mensagens de erro, logs de sistema, etc;
6. Defina a Prioridade Correta: Nem todos os problemas podem ser resolvidos no curto prazo, demanda planejamento, por isso defina o nível de prioridade corretamente;
7. Faça revisão: Leia o que você escreveu, 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.