Bug encontrado, bug reportado! (Parte I)

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! 

3 comentários:

  1. 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

  1. Olá Zis!
    O que os testers e inclusive outras pessoas que participam do projeto, tem que ter em mente é que "tempo é dinheiro". O desenvolvedor pode perder muito tempo tentando reproduzir um bug, que às vezes nem existe mesmo. Portanto, ao descrever o bug com as informações necessárias para facilitar sua identificação posteriormente, minimiza os custos do projeto, já que o desenvolvedor não terá que perder horas procurando, enquanto poderia corrigir os bugs.

  1. Fran Zamberlam disse...:

    Utilizo como base o relatório de incidentes da IEEE 829!

Postar um comentário

 
Monster Bug