Post

1 Star2 Stars3 Stars4 Stars5 Stars
Loading ... Loading ...

By [email protected]blogger.com (Maira Stella da Silva)
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

Source: http://themonsterbug.blogspot.com/2011/09/bug-encontrando-bug-reportado-parte-i.html

Category: bug report, reportar bugs, reportar falhas

Você também pode querer ler

Comments are off for this post.