Menu

Como escrever um bom relatório de bug? Dicas e truques

how write good bug report

Por que um bom relatório de bug?

Se o seu relatório de bug for eficaz, as chances de ser corrigido são maiores. Portanto, consertar um bug depende da eficácia com que você o relata. Relatar um bug nada mais é do que habilidade e irei explicar como conseguir essa habilidade.

“O objetivo de escrever um relatório de problema (relatório de bug) é consertar os bugs” - Por Cem Kaner. Se um testador não estiver relatando um bug corretamente, o programador provavelmente rejeitará esse bug, declarando-o irreproduzível.

Como escrever um bom relatório de bug

Isso pode prejudicar a moral dos testadores e, às vezes, o ego também. (Eu sugiro não manter nenhum tipo de ego. O ego é como “Eu relatei o bug corretamente”, “Eu posso reproduzi-lo”, “Por que ele / ela rejeitou o bug?”, “Não é minha culpa” etc. ,).

O que você aprenderá:

Quais são as qualidades de um bom relatório de bug de software?

Qualquer um pode escrever um relatório de bug. Mas nem todos podem escrever um relatório de bug eficaz.

Você deve ser capaz de distinguir entre um relatório de bug médio e um bom relatório de bug. Como distinguir entre um relatório de bug bom e um mau? É muito simples, aplique as seguintes características e técnicas para relatar um bug.

Características e técnicas incluem

# 1) Ter um número de bug claramente especificado: Sempre atribua um número exclusivo para cada relatório de bug. Isso, por sua vez, o ajudará a identificar o registro do bug. Se você estiver usando qualquer ferramenta automatizada de relatório de bug, este número exclusivo será gerado automaticamente toda vez que você relatar o bug.

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

# 2) Reproduzível: Se o seu bug não for reproduzível, ele nunca será corrigido.

Você deve mencionar claramente as etapas para reproduzir o bug. Não assuma ou pule nenhuma etapa de reprodução. Um bug que é descrito passo a passo é fácil de reproduzir e corrigir.

# 3) Seja específico: Não escreva um ensaio sobre o problema.

Seja específico e direto ao ponto. Tente resumir o problema em palavras mínimas, mas de forma eficaz. Não combine vários problemas, mesmo que pareçam semelhantes. Escreva relatórios diferentes para cada problema.

Relatório de bug eficaz

O relatório de bug é um aspecto importante do teste de software. Um relatório de bug eficaz se comunica bem com a equipe de desenvolvimento e evita confusão ou falha de comunicação.

Um bom relatório de bug deve ser Claro e conciso sem nenhum ponto chave faltando. Qualquer falta de clareza leva a mal-entendidos e também retarda o processo de desenvolvimento. A redação e o relatório de defeitos são uma das áreas mais importantes, mas negligenciadas no ciclo de vida do teste.

melhor atualizador de driver para windows 10

Uma boa redação é muito importante para registrar um bug. O ponto mais importante que um testador deve ter em mente é não usar um tom de comando no relatório. Isso quebra o moral e cria uma relação de trabalho prejudicial. Use um tom sugestivo.

Não presuma que o desenvolvedor cometeu um erro e, portanto, você pode usar palavras duras. Antes de relatar, é igualmente importante verificar se o mesmo bug foi relatado ou não.

Um bug duplicado é um fardo no ciclo de teste. Verifique toda a lista de bugs conhecidos. Às vezes, os desenvolvedores podem ter conhecido o problema e ignorado em uma versão futura. Ferramentas como o Bugzilla, que procura automaticamente por bugs duplicados, também podem ser usadas. No entanto, é melhor procurar manualmente por qualquer bug duplicado.

A informação de importação que um relatório de bug deve comunicar é 'Quão?' e onde?' O relatório deve responder claramente como o teste foi realizado e onde o defeito ocorreu exatamente. O leitor deve reproduzir facilmente o bug e descobrir onde ele está.

Tenha em mente que o objetivo de escrever o relatório de bug é permitir que o desenvolvedor visualize o problema. Ele / Ela deve entender claramente o defeito do relatório de Bug. Lembre-se de fornecer todas as informações relevantes que o desenvolvedor está procurando.

Além disso, tenha em mente que um relatório de bug seria preservado para uso futuro e deve ser bem escrito com as informações necessárias. Use frases significativas e palavras simples para descrever seus bugs. Não use afirmações confusas que desperdicem o tempo do revisor.

Relate cada bug como um problema separado. No caso de vários problemas em um único relatório de bug, você não pode fechá-lo a menos que todos os problemas sejam resolvidos.

Portanto, é melhor dividir os problemas em bugs separados . Isso garante que cada bug possa ser tratado separadamente. Um relatório de bug bem escrito ajuda um desenvolvedor a reproduzir o bug em seu terminal. Isso os ajuda a diagnosticar o problema também.

Como relatar um bug?

Use o seguinte modelo de relatório de bug simples:

Este é um formato de relatório de bug simples. Isso pode variar dependendo da ferramenta de relatório de bug que você está usando. Se você estiver escrevendo um relatório de bug manualmente, alguns campos precisam ser mencionados especificamente, como o número do bug, que deve ser atribuído manualmente.

Repórter: Seu nome e endereço de email.

Produtos: Em qual produto você encontrou esse bug.

Versão: A versão do produto, se houver.

Componente: Esses são os principais submódulos do produto.

Plataforma: Mencione a plataforma de hardware onde você encontrou esse bug. As várias plataformas como ‘PC’, ‘MAC’, ‘HP’, ‘Sun’ etc.

Sistema operacional: Mencione todos os sistemas operacionais onde você encontrou o bug. Sistemas operacionais como Windows, Linux, Unix, SunOS, Mac OS. Mencione as diferentes versões do sistema operacional também como Windows NT, Windows 2000, Windows XP, etc., se aplicável.

Prioridade: Quando um bug deve ser corrigido? A prioridade é geralmente definida de P1 a P5. P1 como “consertar o bug com a maior prioridade” e P5 como “Consertar quando o tempo permitir”.

Gravidade: Isso descreve o impacto do bug.
Tipos de Gravidade:

  • Bloqueador: Nenhum trabalho de teste adicional pode ser feito.
  • Crítico: Falha do aplicativo, perda de dados.
  • Principal: Grande perda de função.
  • Menor: Perda menor de função.
  • Trivial: Algumas melhorias na IU.
  • Aprimoramento: Solicitação de um novo recurso ou algum aprimoramento do existente.

Status: Quando você está registrando o bug em qualquer sistema de rastreamento de bug, por padrão, o status do bug será ‘Novo’.
Mais tarde, o bug passa por vários estágios como corrigido, verificado, reabrir, não corrigido, etc.

o que é teste alfa com exemplo

=> Clique aqui para ler mais sobre o ciclo de vida do bug detalhado.

Atribuir a: Se você souber qual desenvolvedor é responsável por aquele módulo específico no qual o bug ocorreu, você pode especificar o endereço de e-mail desse desenvolvedor. Caso contrário, mantenha-o em branco, pois isso atribuirá o bug ao proprietário do módulo, caso contrário, o gerente atribuirá o bug ao desenvolvedor. Possivelmente adicione o endereço de e-mail do gerente na lista CC.

URL: O URL da página em que o bug ocorreu.

Resumo: Um breve resumo do bug principalmente em 60 palavras ou menos. Certifique-se de que seu resumo está refletindo sobre qual é o problema e onde ele está.

Descrição: Uma descrição detalhada do bug.

Use os seguintes campos para o campo de descrição:

  • Reproduza as etapas: Claramente, mencione as etapas para reproduzir o bug.
  • Resultado esperado: Como o aplicativo deve se comportar nas etapas mencionadas acima.
  • Resultado atual: Qual é o resultado real da execução das etapas acima, ou seja, o comportamento do bug.

Estas são as etapas importantes no relatório de bug. Você também pode adicionar o “Tipo de relatório” como mais um campo que irá descrever o tipo de bug.

Os tipos de relatório incluem:

1) Erro de codificação
2) Erro de design
3) Nova Sugestão
4) Problema de documentação
5) Problema de hardware

Recursos importantes em seu relatório de bug

A seguir estão os recursos importantes no relatório de bug:

# 1) Número / id do bug

Um número de bug ou um número de identificação (como swb001) torna o relatório de bug e a referência a um bug muito mais fácil. O desenvolvedor pode verificar facilmente se um bug específico foi corrigido ou não. Isso torna todo o processo de teste e reteste mais suave e fácil.

# 2) Título do bug

Um título de bug é lido com mais freqüência do que qualquer outra parte do relatório de bug. Deve dizer tudo sobre o que vem no bug.

O título do Bug deve ser sugestivo o suficiente para que o leitor possa entendê-lo. Um título de bug claro torna mais fácil de entender e o leitor pode saber se o bug foi relatado anteriormente ou foi corrigido.

# 3) Prioridade

Com base na gravidade do bug, uma prioridade pode ser definida para ele. Um bug pode ser um bloqueador, crítico, principal, secundário, trivial ou uma sugestão. Uma prioridade de bug de P1 a P5 pode ser dada para que os mais importantes sejam vistos primeiro.

# 4) Plataforma / Ambiente

A configuração do sistema operacional e do navegador é necessária para um relatório de bug claro. É a melhor forma de comunicar como o bug pode ser reproduzido.

Sem a plataforma ou ambiente exato, o aplicativo pode se comportar de forma diferente e o bug no final do testador pode não se replicar no desenvolvedor. Portanto, é melhor mencionar claramente o ambiente em que o bug foi detectado.

# 5) Descrição

A descrição do bug ajuda o desenvolvedor a entender o bug. Descreve o problema encontrado. A má descrição criará confusão e desperdiçará o tempo dos desenvolvedores e testadores também.

É necessário comunicar claramente sobre o efeito da descrição. É sempre útil usar frases completas. É uma boa prática descrever cada problema separadamente, em vez de destruí-los completamente. Não use termos como 'Eu acho' ou 'Eu acredito'.

# 6) Etapas para reproduzir

Um bom relatório de bug deve mencionar claramente as etapas de reprodução. As etapas devem incluir ações que causam o bug. Não faça declarações genéricas. Seja específico nas etapas a seguir.

Um bom exemplo de um procedimento bem escrito é dado abaixo

Passos:

  • Selecione o produto Abc01.
  • Clique em Adicionar ao carrinho.
  • Clique em Remover para remover o produto do carrinho.

# 7) Resultado esperado e real

A descrição de um bug está incompleta sem os resultados esperados e reais. É necessário delinear qual é o resultado do teste e o que o usuário deve esperar. O leitor deve saber qual é o resultado correto do teste. Claramente, mencione o que aconteceu durante o teste e qual foi o resultado.

# 8) Captura de tela

Uma imagem vale mais que mil palavras. Faça uma captura de tela da instância da falha com legendas adequadas para destacar o defeito. Destaque as mensagens de erro inesperadas com a cor vermelha clara. Isso chama a atenção para a área necessária.

Algumas dicas bônus para escrever um bom relatório de bug

Abaixo estão algumas dicas adicionais para escrever um bom relatório de bug:

# 1) Relate o problema imediatamente

Se você encontrar algum bug durante o teste, não precisa esperar para escrever um relatório de bug detalhado mais tarde. Em vez disso, escreva o relatório do bug imediatamente. Isso garantirá um relatório de bug bom e reproduzível. Se você decidir escrever o relatório de bug mais tarde, então há grandes chances de perder etapas importantes em seu relatório.

# 2) Reproduza o bug três vezes antes de escrever um relatório de bug

Seu bug deve ser reproduzível. Certifique-se de que suas etapas sejam robustas o suficiente para reproduzir o bug sem qualquer ambigüidade. Se o seu bug não for reproduzível todas as vezes, você ainda pode registrar um bug mencionando a natureza periódica do bug.

# 3) Teste a mesma ocorrência de bug em outros módulos semelhantes

Às vezes, o desenvolvedor usa o mesmo código para diferentes módulos semelhantes. Portanto, há maiores chances de o bug em um módulo ocorrer também em outros módulos semelhantes. Você pode até tentar encontrar a versão mais severa do bug que encontrou.

# 4) Escreva um bom resumo do bug

qual é o melhor site de download de mp3 de graça?

O resumo do bug ajudará os desenvolvedores a analisar rapidamente a natureza do bug. Um relatório de baixa qualidade aumentará desnecessariamente o tempo de desenvolvimento e teste. Comunique-se bem com o resumo do seu relatório de bug. Lembre-se de que o resumo do bug é usado como referência para pesquisar o bug no inventário de bug.

# 5) Leia o relatório de bug antes de clicar no botão Enviar

Leia todas as sentenças, redações e etapas usadas no relatório de bug. Veja se alguma frase está criando ambigüidade que pode levar a interpretações erradas. Palavras ou frases enganosas devem ser evitadas para se ter um relatório de bug claro.

# 6) Não use linguagem abusiva

É bom que você tenha feito um bom trabalho e encontrado um bug, mas não use esse crédito para criticar o desenvolvedor ou para atacar qualquer indivíduo.

Conclusão

Sem dúvida, o seu relatório de bug deve ser um documento de alta qualidade.

Concentre-se em escrever bons relatórios de bugs e gaste algum tempo nesta tarefa porque este é o principal ponto de comunicação entre o testador, o desenvolvedor e o gerente. Os gerentes devem conscientizar sua equipe de que escrever um bom relatório de Bug é a principal responsabilidade de qualquer testador.

Seu esforço para escrever um bom relatório de bug não só economizará os recursos da empresa, mas também criará um bom relacionamento entre você e os desenvolvedores.

Para melhor produtividade, escreva um relatório de bug melhor.

Você é um especialista em escrever um relatório de bug? Sinta-se à vontade para compartilhar suas idéias na seção de comentários abaixo.

Leitura recomendada

^