Saudações caçadores de bugs!
Tão importante quanto encontrar o bug, é reportá-lo de maneira direta e objetiva, para que outras pessoas envolvidas no projeto possam ler, entender e acompanhar.
Lendo o livro "Lessons Learned in Software Testing" dos escritores Cem Kaner, James Bach e Bret Pettichord, eu aprendi algumas lições sobre o conceito de reporte de bugs. Em breve, em outro post, pretendo comentar mais especificamente sobre o livro.
Abaixo, seguem as lições que eu considerei mais interessantes:
- You are what you write:
Reportar um erro é bem mais que apenas descrever o que aconteceu.
Por exemplo, se você simplesmente escrever: "Não é possível cadastrar o produto.", haverá vários programadores furiosos questionando: esse bug acontece em qual ambiente, em quais circustâncias? É necessário algum pré-requisito para reproduzir?
Portanto, é importante informar a prioridade de correção, o ambiente em que foi encontrado, a sequência de ações necessárias, um resultado esperado, imagens, enfim, dados relevantes para os desenvolvedores e os outros envolvidos no projeto. Quanto melhor o conjunto de informações, mais fácil será para o programador identificar o mesmo erro e corrigi-lo posteriormente.
Lembrando que clientes e diretores também poderão ler os bugs reportados. Então "The better your reports, the better your reputation."
- Make you bug report an effective sales tool:
Uma maneira implícita de convencer o seu amigo desenvolvedor, que é realmente necessário corrigir um determinado bug, é adicionar o benefício que a correção resultaria, ou o custo que gera para a empresa caso não seja corrigido. É claro que deve ser utilizado o bom senso, e não exigir que bugs com prioridades baixas sejam corrigidos imediatamente.
Por experiência própria, eu já negociei vários bugs. Felizmente, na empresa onde eu trabalho, a relação entre testers e desenvolvedores é muito amigável. Sempre conversamos sobre a importância da correção, e entramos em um acordo dependendo da necessidade e da urgência na entrega dos sistemas.
Ou seja, quando todos estão realmente envolvidos no projeto, há apenas um objetivo em comum: entregar o sistema da melhor maneira possível dentro do prazo estipulado.
- Report defects promptly:
Assim que o bug for identificado, é necessário registrá-lo. Se demorar muito para reportar, a chance de esquecer dados importantes aumenta e o erro levará mais tempo para ser corrigido.
- Always report nonreproducible erros; they may be time bombs:
Você encontrou um bug, mas não consegue reproduzir? Não deixe de reportar o erro mesmo assim. Antes de fechar a tela com o erro, providencie imagens da cena do crime, para comprovar posteriormente que a falha realmente acontece.
- Every bug deserves its own report:
Mesmo que em uma única tela existam vários erros, cada erro deverá ser reportado separadamente, com suas respectivas informações.
- The summary line is the most important line in the bug report:
O título da descrição do bug deverá ser objetivo, direto. Deve ser uma breve descrição do erro, de maneira que apenas lendo o título já seja possível entender em qual parte do sistema acontece e o que acontece. Pense em um título que, em apenas algumas palavras, você consiga transmitir o erro e os stakeholders consigam entender, sem ter que visualizar mais detalhes. Também poderá ser adicionado o impacto ou a consequência do bug.
Existem outras considerações tão importantes quanto essas. Continua no próximo post!
Curiosidade: Mensagens de Erros Bizarras
Mais esse texto é coisa mais linda *-*. O que me deixa mais PUTOO é bug reportado com algo do tipo "Problema na baixa de pagamentos, dá uma conferida ae", do tipo se vira, normalmente quem testa já possui todo o caso identificado, em vez de perde alguns minutos relatando exatamente o problema e mostrando o caso, o desenvolvedor acaba perdendo muito tempo e as vezes nem achando o erro ou não identificando o caso corretamente e acaba fazendo mais caca ainda.
Maira, sorte de quem recebe bugs seus hauahauahauh. Bjsssss