Bug encontrado, bug reportado! (Parte II)

Continuando o post anterior...

Mais alguns conceitos interessantes sobre o registro de bugs que eu aprendi lendo o livro "Lessons Learned in Software Testing":

- Never exaggerate your bugs:
De acordo com o projeto e o tipo de sistema, é necessário ter um critério para definir o que seria um bug crítico ou não. Um erro não poderá ser categorizado como crítico sem ter fatos que comprovem essa escolha. Por exemplo, em um site de ecommerce, um erro durante a etapa de compra de produtos com certeza é crítico, principalmente porque acarreta prejuízo para a empresa. Mas tente ser coerente, e não classificar qualquer bug como crítico, apenas para ser corrigido urgentemente.

- Bug reports should be closed by testers:
Todo bug corrigido deverá ser testado novamente, a fim de indentificar se a correção foi realmente concluída. Caso o bug reportado não ocorra mais, este poderá ser fechado definitivamente pelo testador. Quanto antes for possível testar a correção, melhor será para o programador, que lembrará mais facilmente do código alterado, caso o bug não tenha sido realmente corrigido.

- Never use the bug-tracking system to monitor testers performance:
Não é possível medir a eficiência de um tester se baseando apenas na quantidade de bugs reportados. Quantidade não significa qualidade.

- Keep clear the difference between severity and priority:
A gravidade (severity) é referente ao impacto que o erro causa no sistema. A prioridade indica com que urgência o erro deverá ser corrigido. Geralmente quanto maior a gravidade do problema, maior a sua prioridade para correção.


Clicando nesse link você poderá ler sugestões de como reportar um bug na perspectiva de um desenvolvedor.


A comunidade TestExpert listou vários links sobre teste e qualidade de software. Para conferir basta clicar aqui.

1 comentários:

  1. Excelente post Maira! Eu tenho uma "máscara" padrão de abertura de bugs que uso desde que trabalhei em uma empresa nível 3 do CMMI, ela consiste nos seguintes itens:

    Descrição do Problema:
    Comportamento Esperado:
    Passos para Simular:
    1.
    2.
    3.
    Caso de Teste utilizado
    Qualquer outra informação importante (ambiente, log anexo e etc.)

    Passei a utilizar esta máscara na empresa onde trabalho e a galera gostou! Pena que alguns testers não o seguem a risca e acabam por fazer alguns desenvolvedores retornarem o bug por falta de informações!

    O ponto que eu mais gostei do post foi:

    "Não é possível medir a eficiência de um tester se baseando apenas na quantidade de bugs reportados. Quantidade não significa qualidade."

    Vou precisar apresentar isso para algumas pessoas!

    Até mais!

Postar um comentário

 
Monster Bug