Click here to edit title

Click here to edit subtitle

Blog

Reporte de Bugs

Posted by 4AllTesters on December 22, 2014 at 9:25 AM

O Júlio de Lima pediu pra eu falar sobre "Como melhorar o reporte de bugs".


Isso me surpreendeu por dois motivos. O primeiro, é que eu não estava acostumado com o uso de 'reporte' como substantivo.

O segundo motivo é o fato de entre todos os assuntos que apareceram até agora durante o desafio, este é o que mais combina comigo - obrigado pela escolha e pela aula de vocabulário, Júlio!

 



Reporte de bugs é que é um tópico muito amplo, e dá para escrever um sem-fim de artigos sobre isso!


Escolhi escrever um texto bem especifico, sobre a maneira de escrever um relatório de bug. Esses textos de reporte são de extrema importância na atividade de testes: Nosso esforço tem como objetivo descobrir informação sobre áreas de risco, e a maneira de expor essa informação é reportando os defeitos encontrados.


Descrições detalhadas tornam-se mais valiosas ao incluir evidencias (logs, screenshots, códigos de erro), ao definir quais as condições mínimas para replicação da falha, ao incluir os passos executados durante o debug. Mas talvez o mais importante seja seu título! Se os relatórios são parte essencial de nossa atividade de testes, os títulos são o coração dos relatórios.

 


Um bom título é um ponto onde mesmo um melhora pequena tem benefício multiplicado e grandes resultados.

Ha vários motivos para a importância dos títulos: É o primeiro encontro que qualquer um (parceiro de equipe, programador, gerente, cliente) tem com o problema exposto. Durante reuniões de triagem, poucas vezes há tempo ou vontade de ler mais do que esse resumo de uma linha. E muitos times optam por uma administração de defeitos mais ligeira, com post-its ou adições as estórias de desenvolvimento, onde não há necessidade (ou espaço) para mais que um cabeçalho.

 

Neste artigo, vou defender a apresentação dos bugs em linguagem de negócio e não técnica. Que o título contenha o efeito no negócio ao invés da descrição técnica do problema.

Ao usar uma linguagem genérica que se adapta ao negócio, detachamos o problema técnico e criamos uma conversação sobre risco e sobre valor ao cliente. Especificamente, ganhamos:

  • Melhor exposição do problema real
  • Decisões de severidade mais precisas
  • Decisões com encarregados do negócio
  • Menor autoridade técnica nas discussões sobre o bug



Mais fácil do que explicar esses benefícios, vamos dar exemplos:

 

[Versão a] Error 404 ao abrir link 'conexões' na página order.aspx.

[Versão b] Não existe informação disponível sobre os tipos de conexão durante a encomenda.

Qual a severidade da primeira versão do bug? Alguém precisa explicar qual a página order.aspx, que informação existe nela e no link, quais as outras formas de obter esse conhecimento. No segundo, isso está explicado. Quem toma as decisões de negócio pode com facilidade decidir a severidade deste bug.

 

[Versão a] BSoD (tela azul) acontece quando momentaneamente não há memória disponível no dispositivo.

[Versão b] Usuário perde controle do sistema operacional - potencial perda de dados! - de forma esporádica (maiores chances com uso extensivo do dispositivo).

Ficou mais comprido, eu sei. Mas a nova versão permite ao gerente, PO, ou outros encarregados do negócio participar da decisão sobre como e quando concertar. Apesar da reprodução do bug ser consistente quando não há acesso a memória, o acesso a memória não é consistente, e a segunda versão dá uma chance a interessados de perguntar sobre a frequência em que isto pode acontecer.

 

[Versão a] Drag-and-drop não habilitado para sub-itens no Chrome (versão 8 e acima)

[Versão b] Adição ao catalogo é feita diferente em navegadores Chrome (14% dos clientes)

Neste caso, não apenas a informação do impacto ao usuário é clara, como ela remove a discussão técnica. Um debate típico sobre o primeiro título incluiria "é obvio, a biblioteca gráfica que usamos não suporta Chrome" e logo estaríamos em uma argumentação técnica sobre a biblioteca. No segundo título, por outro lado, a conversa será sobre a experiência que gostaríamos de prover a um de cada oito usuários, sem autoridade técnica.

 


Espero que esses exemplos tenham deixado claro umas sugestões sobre como escrever os títulos, mas também esclarecido os benefícios de uma abordagem que foca o negócio:

  • Melhor exposição do problema real
  • Decisões de severidade mais precisas
  • Decisões com encarregados do negócio
  • Menor autoridade técnica nas discussões sobre o bug

 

Boa sorte - qualquer pergunta ou reclamação é bem-vinda!


Shmuel

Categories: Artigos, Conceitos, Bug

Post a Comment

Oops!

Oops, you forgot something.

Oops!

The words you entered did not match the given text. Please try again.

Already a member? Sign In

2 Comments

Reply Lindomar Reitz
8:07 AM on December 24, 2014 
Parabéns pelo post.

Reporte de bugs as vezes é uma tarefa ingrata, principalmente nesses casos dos problemas que são complicados de simular, o que já joga a sua prioridade lá embaixo.

Dependendo do programador, nem o passo a passo resolve, uma vez que a preguiça é maior do que qualquer coisa.

Mesmo assim, na maioria das vezes o reporte é importante pra mim mesmo, pois dificilmente um programador consegue seguir o que eu escrevo (sempre pergunto se é falta de entendimento, mas na maioria é preguiça ou pressa, o que as vezes gera mais bug).
Reply Anderson Cezar
11:36 AM on December 26, 2014 
Bom post!!
Mas discordo da parte que você disse:
"Mas talvez o mais importante seja seu título! Se os relatórios são parte essencial de nossa atividade de testes, os títulos são o coração dos relatórios."

Acredito que o mais importante seja o passo-a-passo para se chegar no bug, junto com uma descrição detalhada, e muitos testers por preguiça omitem uma boa descrição.

Abs,
Anderson Cezar