Os dez pontos que devem ser considerados para o acompanhamento de bugs
1. Um bom testador se preocupa em reduzir, ao mínimo, o número de passos para reproduzir bugs; isto é muito útil para o programador que tiver que encontrar o defeito.
2. A única pessoa que pode atribuir status de resolvido a um bug é aquela que o reportou primeiro. Qualquer um pode solucioná-lo mas só quem o descobriu pode ter a certeza de que foi realmente resolvido.
3. Não reprodutível informa que o programador não conseguiu recriar o bug. Este status é normalmente usado pelos programadores quando enviam de volta o bug ao testador com a informação de que o relatório não contém algum passo crítico para reproduzi-lo. Bons testadores encaram isto como um desafio, não uma desculpa para encerrar o caso.
4. Acompanhe cuidadosamente as versões. Cada versão do software que você passa aos testadores deve carregar um identificador de versão que pode ser colocado no campo de versão da ferramenta de gestão de bugs. Quando um programador resolve o bug ele deve indicar em que versão a correção se aplica para que o pobre testador não reteste o bug numa versão do software em que a correção não se aplica.
5. Se você é um programador e está enfrentando problemas para conseguir que os testadores usem a ferramenta de gestão de bugs, não aceite nenhum bug reportado por qualquer outro meio. Assim se os testadores lhe enviam e-mails com os relatórios de bugs, mande de volta os e-mails com a mensagem: “Por favor coloque isto no banco de dados de bugs. Eu não consigo dar conta dos meus e-mails”.
6. Se você é um testador e está enfrentando problemas para conseguir que os programadores usem a ferramenta de gestão de bugs, não os informe sobre qualquer bug - coloque-os na ferramenta e deixe que ela os informe.
7. Se você é um programador e somente alguns dos seus colegas usam a ferramenta de gestão de bugs, comece a lhes designar bugs. Cedo ou tarde eles entenderão.
8. Se você é um gerente, designe bugs à sua equipe na ferramenta de gestão de bugs. Cedo ou tarde eles entenderão que em vez de chegar em seu escritório de vez em quando dizendo “que devo fazer agora?” eles simplesmente vão ver o que lhes foi designado na ferramenta.
9. Crie o hábito de escrever todos seus relatórios de bug com três seções: passos para a reprodução, o bug em si, e o que era esperado.
10. Crie formulários simples para o report de bugs, pois se a formalidade de registrar um bug der muito trabalho, as pessoas vão começar a trocar e-mails, e os casos vão se perder.
11. (Bônus grátis) Não tenha raiva dos bugs! Se um bug lhe for designado, não significa uma crítica pessoal, é apenas uma forma de melhorar o software. Depois que você passar pelos primeiros três mil bugs, você deixará de se sentir deprimido e começará a apreciar o gosto dos quebra-cabeças que lhe trarão os bugs. Algumas pessoas pagam por livros de quebra-cabeças e os resolvem na praia ou na rede. Você vai solucioná-los no trabalho e será pago para isto. O que pode ser mais divertido?
