Como escrever um Bug Report

Eu estava fazendo uma pesquisa para a criação de conteúdo de escrita de Bug Report, tentando coletar diferentes pontos de vista sobre o assunto para escrever algo bem completo e quando eu já estava praticamente concluindo o conteúdo encontrei um artigo extremamente completo e seria uma pena pegar apenas partes deste artigo e como o conteúdo está em inglês e muita gente ainda tem dificuldade com o idioma resolvi fazer uma tradução do artigo publicado na Software Testing Help chamado “How to write a good bug report? Tips and Trics”.

Por que um bom bug report?

Se seu bug report é efetivo , então as chances de ter o bug corrigido são maiores. Então corrigir um bug depende de quão efetivo você é em reporta-lo. Reportar um bug não é nada além de uma habilidade e eu vou explicar como adquirir esta habilidade.

Cem Kaner disse “A ideia em escrever um relatório de erros(bug report) é ter os bugs corrigidos”. Se um tester não reporta um bug de forma correta, o programador provavelmente irá rejeitar o bug categorizando-o como irreprodutível.

Isso pode ferir a moral dos testers e as vezes o ego também. (Sugiro não ter nenhum tipo de ego. Ego é “Eu reportei o bug corretamente”, “Eu posso reproduzir isso”, “Por que ele/ela rejeitou o bug?”, “Não é minha culpa” e etc…)

Quais são as qualidades de um bom software bug report?

Qualquer um pode escrever um bom bug report. Mas nem todo mundo pode escrever um bug report efetivo.

Você deveria ser capaz de distinguir entre um bug report comum e um bom bug report. Como distinguir entre um bom bug report e um bug report ruim? É muito simples, aplique as características e técnicas a seguir para reportar um bug.

Características e técnicas inclusas:

#1) Ter claramente especificado o número do bug

Sempre tenha um número único para cada bug report. Isso o ajudará a identificar o histórico do bug. Se você está utilizando qualquer ferramenta de reporte de bug automatizada então este será gerado automaticamente toda vez que você reportar um bug.

Guarde o número e uma breve descrição de cada bug que você reportar.

#2) Reprodutibilidade

Se um bug não é reproduzível, então ele nunca será corrigido.

Você deve informar claramente os passos para reproduzir o bug. Não presuma ou pule qualquer passo. Um bug que é descrito passo a passo é fácil de se reproduzir e corrigir.

#3) Seja específico

Não escreva uma redação sobre o problema.

Seja específico e vá direto ao ponto. Tente resumir o problema no menor número de palavras possível em uma forma efetiva.

Não junte diversos problemas mesmo se eles forem parecidos. Escreva um report diferente para cada problema.

Bug report efetivo

Reportar um bug é um aspecto importante dos testes de software. Um bug report efetivo comunica bem ao time de desenvolvimento e evita confusões ou mal entendidos.

Um bom bug report deve ser claro e conciso sem faltar nenhum ponto chave. Qualquer falta de de clareza leva a mal entendidos e desacelera um bom processo de desenvolvimento. Escrita de defeitos é uma das mais importantes e negligenciadas áreas do ciclo de vida do teste.

Uma boa escrita é muito importante para registrar um bug. O ponto mais importante que um tester deveria ter em mente é não use um tom de comando no report. Isto quebra o moral e cria um ambiente de trabalho não saudável. Use um tom de sugestão.

Não presuma que o desenvolvedor cometeu um erro senão consequentemente você pode usar palavras duras. Antes de reportar, é igualmente importante checar se o mesmo bug já foi reportado ou não.

Um bug duplicado é um fardo no cliclo de testes. Verifique toda a lista de bugs conhecidos. As vezes, o desenvolvedor pode conhecer o problema e ignorar para uma release futura. Ferramentas como Bugzilla que procura automaticamente por bugs duplicados pode ser utilizada. Embora seja melhor procurar de forma manual por qualquer bug duplicado.

Uma informação importante que um bug report deve comunicar é “como?” e “onde?” o report deve claramente responde como o teste foi feito e onde o defeito foi encontrado exatamente. O leitor deve facilmente reproduzir o bug e encontrar onde ele está.

Tenha em mente que o objetivo de escrever um bug report é fazer com que o desenvolvedor visualize o problema. Ele/ela deve claramente entender o defeito a partir do bug report. Lembre-se de dar todas as informações relevantes que o desenvolvedor está procurando.

Tenha em mente também que um bug report deve ser guardado para uso futuro e deve ser bem escrito com todas as informações necessárias. Use frases com significado e palavras simples para descrever um bug. Não use frases confusas que desperdicem o tempo do leitor.

Reporte cada bug como um problema em separado. Em caso de múltiplos problemas em um único bug report, você não poderá fechar o bug a menos que todos os problemas tenham sido resolvidos.

Por isso é melhor dividir os problemas em bugs separados. Isso certifica que cada bug pode ser trabalhado separadamente. Um bug report bem escrito ajuda desenvolvedores a reproduzir o bug em suas máquinas. Isso ajuda eles a diagnosticarem o problema também.

Como reportar um Bug?

Use o template de bug report abaixo:

Este é um formato de bug report simples. Isto pode variar dependendo da ferramenta de report de bug que você está usando. Se você está escrevendo um bug report manualmente então alguns campos precisam ser mencionados especificamente como o número do bug, que deve ser designado manualmente.

Quem está reportando: Seu nome e e-mail.

Produto: Em que produto você está encontrando o bug.

Versão: A versão do produto.

Componente: O sub-modulo do produto.

Plataforma: Mencione a plataforma de hardware em que foi encontrado o bug. São varias as plataformas como “PC”, “MAC”, “HP”, “Sun” e etc…

Sistema operacional: Mencione todos os sistemas operacionais onde o bug foi encontrado. Sistemas como Windows, Linux, Unix, SunOS, Mac OS. Mencione também as diferentes versões do SO como Window NT, Windows 2000, Windows XP e etc…

Prioridade: Quando um bug deve ser corrigido? Prioridade é geralmente definida de P1 a P5. P1 como “Correção com prioridade máxima” e P5 como “Correção quando tiver tempo”.

Severidade: Descreve o impacto do bug

Tipos de severidade:

• Blocker: Não é possível continuar com os testes

• Critical: Aplicação quebrou, perda de dados.

• Major: Grande perda de função

• Minor: Pequena perda de função

• Trivial: Algumas melhorias de UI

• Enhancement: Requisição por uma nova funcionalidade ou melhoria em alguma funcionalidade existente.

Status:

Quando você inclui um bug em qualquer ferramenta de gerenciamento de bugs por padrão o status do bug será “new”.

Depois, o bug vai passando por por vários estágios como “Fixed”, “Verified”, “Reopen”, “Won’t fix” e etc…

Designado para:

Se você sabe quem é o desenvolvedor responsável pelo modulo em particular que o bug foi encontrado, então você pode especificar o endereço de e-mail do desenvolvedor. Caso contrário mantenha o campo em branco para que o bug possa ser designado para o dono do módulo, senão o gerente irá designar o bug para algum desenvolvedor. Se possível inclua o endereço de e-mail do gerente em cópia.

URL:

A URL em que ocorreu o bug

Sumário:

Um breve resumo do bug em 60 palavras ou menos. Tenha certeza de que seu sumário reflita o problema e onde ele está.

Descrição:

Uma descrição detalhada do bug.

Use os campos abaixo para preencher a descrição:

• Passos para reprodução: Claramente, informe os passos para reprodução do bug.

• Resultado esperado: Como a aplicação deveria se comportar durante os passos citados acima.

• Resultado encontrado: Qual é o resultado realmente encontrado executando os passos acima. O comportamento do bug.

Esses são alguns passos importantes em um bug report. Você pode incluir também o “Tipo de report” como mais um campo em que será descrito o tipo de bug.

O tipo de report inclui:

1) Erro no código

2) Erro de design

3) Nova sugestão

4) Problema de documentação

5) Problema de hardware

Funcionalidades importantes em seu bug report

Abaixo estão os bugs importantes em um bug report:

#1) Número/ID do Bug:

Um número ou ID de um bug(como swb001) faz um bug report e a referência a um bug bem mais fácil.

#2) Título do bug

O título do bug é mais lido que qualquer outra parte do bug report. Ele deve dizer tudo o que o tem no bug.

O título do bug deve ser sugestivo o bastante para o leitor entende-lo. Um título claro é torna muito mais fácil a compreensão e o leitor pode saber se o bug foi reportado anteriormente ou já foi corrigido.

#3) Prioridade

Baseado no severidade do bug, uma prioridade pode ser definida para ele. Um bug pode ser um Blocker, Critical, Major, Minor, Trivial ou suggestion. Uma prioridade de bug pode ser P1 a P5 assim os mais importantes podem ser visto antes.

#4) Plataforma/Ambiente

As configurações dos sistemas operacionais e dos browsers são necessários para um bug report claro. É a melhor maneira de informar como o bug pode ser reproduzido.

Sem a exata plataforma ou ambiente, a aplicação pode se comportar diferentemente e os bugs que foram encontrados nos testes dos QA podem não ser encontrados nos testes dos desenvolvedores. Então é melhor informar claramente o ambiente no qual o bug foi detectado.

#5) Descrição

A descrição do bug ajuda o desenvolvedor a entender o bug. Ela descreve o problema encontrado. Uma descrição pobre irá criar confusão e desperdiçar o tempo dos desenvolvedor e dos testers.

É necessário comunicar claramente sobre o efeito na descrição. Usar sentenças completas sempre ajuda. É uma boa prática descrever cada problema separadamente ao invés de todos juntos. Não use termos como “Eu acho” ou “Eu acredito”.

#6) Passos para reproduzir

Um bom bug report deve claramente mencionas os passos para reprodução. Os passos devem incluir as ações que causaram o bug. Não faça declarações genéricas. Seja específico no fluxo dos passos.

Um bom exemplo de fluxo de passos está descrito abaixo:

• Selecione o produto abc01.

• Clique em adicionar ao carrinho.

• Click em remover para remover o produto do carrinho.

#7) Resultados esperados e Resultados encontrados

A descrição de um bug está incompleta sem o resultado esperado e o resultado encontrado. É necessário resumidamente informar a saída do teste e o que deveria ser esperado. O leitor deve saber qual é a saída correta do teste.

#8) Screenshot

Uma imagem vale mais que mil palavras. Tire um screenshot da falha apropriadamente descrita para evidenciar o defeito. Evidencie mensagens de erro inesperadas com a cor vermelha. Isto chama a atenção para a área requerida.

Algumas dicas bônus para escrever um bom bug report

Abaixo estão algumas dicas adicionais para escrita de um bom bug report:

1) Reporte o problema Imediatamente:

Se você encontrar qualquer bug enquanto está testando, então não pode esperar para escrever um bug report detalhado depois. Invés disso escreva o bug report imediatamente. Isto garantirá um bug report bom e fácil de reproduzir. Se você decidir escrever o bug report depois há uma grande chance de esquecer algum passo importante no seu report.

2) Reproduza o bug três vezes antes de escrever um bug report:

Seu bug deve ser reproduzível. Tenha certeza de que seus passos são robustos o suficiente para reproduzir o bug sem nenhuma ambiguidade. Se seu bug não é reproduzível toda vez você ainda assim pode reportar o bug informando a frequência desse bug.

3) Teste a ocorrência do mesmo bug em outros módulos similares:

As vezes desenvolvedores usam o mesmo código para módulos similares. Então há uma grande chance de um bug que ocorreu em um módulo ocorrer em um módulo similar também. Você pode até tentar encontrar versões mais severas do bug que você encontrou.

4) Escreva um bom resumo do bug:

O Resumo do bug ajudará os desenvolvedores a analisar rapidamente a natureza do bug. Um report de baixa qualidade irá desnecessariamente aumentar o tempo de desenvolvimento e teste. Se comunique bem através de seu resumo do bug report. Tenha em mente que o resumo do bug é usado como uma referência para a procura do bug em um inventário de bugs.

5) Leia o bug report antes de apertar o botão enviar:

Leia todas as sentenças, palavras e passos que foram usadas no bug report. Veja se qualquer sentença está criando ambiguidade que possa levar a uma má interpretação. Palavras ou sentenças dúbias devem ser evitadas para se ter um bug report claro.

6) Não use linguagem abusiva:

É legal que você fez um bom trabalho e encontrou um bug mas não use este crédito para criticar o desenvolvedor ou atacar qualquer individuo.

Conclusão

Sem dúvidas que seu bug report deva ser um documento de alta qualidade.

Foque em escrever um bom bug report e gaste algum tempo nesta tarefa porque esta é o principal ponto de comunicação entre o testador, desenvolvedor e o gestor. Gestores deveriam criar um aviso para o seu time de que escrever um bom bug report é a responsabilidade primária de qualquer testador.

Seu esforço em escrever um bom bug report irá não apenas poupar recursos da empresa como também criará um bom relacionamento entre você e os desenvolvedores.

Para uma produtividade melhor escreva um bug report melhor.

Referência

https://www.softwaretestinghelp.com/how-to-write-good-bug-report/