Como escrever um relatório de bug com exemplos

O que é relatório de bug? Por que você precisa de um bom relatório de bug?

Bug Report é um documento importante no STLC que oferece diversas vantagens para a equipe de testes. Ele monitora todos os defeitos, vários bugs, erros e outras discrepâncias encontradas durante os testes de software e os relata.

O objetivo desta documentação pós-teste é fornecer informações à equipe de profissionais envolvida sobre o nível de bugs encontrados durante o processo de teste.

investimentos engenheiro de desenvolvimento de software pode ser informado de todos os defeitos e problemas presentes no software por meio deste tipo de relatório. Também permite descobrir o que há de errado com um bug, para que você possa usar o melhor método para corrigi-lo. Também ajuda você a economizar tempo e dinheiro, ajudando a detectar bugs e problemas.

Por que você deveria se preocupar com boas explicações sobre bugs?

Boas explicações sobre bugs

Aqui está o ponto que você precisa considerar ao escrever um relatório de bug de software bom e detalhado:

  • Ele atua como um guia para ajudar a evitar o mesmo bug em versões futuras.
  • Economize tempo para comunicação (e-mails, chamadas).
  • Menos trabalho para os desenvolvedores (eles farão exatamente o que você deseja).
  • Você terá menos gargalos no projeto; bugs serão corrigidos de maneira mais rápida e eficiente.

Como escrever um relatório de bug (modelo de relatório de bug)

Não existe um modelo exato de relatório de bugs, pois depende do seu sistema de rastreamento de bugs. Seu modelo pode ser diferente.

No entanto, o seguintewing campos comuns são sempre necessários quando você deseja escrever um relatório de bug:

  • ID/título do bug.
  • Gravidade e Prioridade.
  • Descrição
  • Meio Ambiente
  • Passos para reproduzir.
  • Resultado esperado.
  • Resultado atual.
  • Anexos (capturas de tela, vídeos, texto)

Vejamos todos esses componentes de correção de bugs, um por um:

1) Título/ID do bug:

Cada bug deve receber um número de identificação exclusivo. As ferramentas de relatório de bugs devem ser exclusivas numbers para os bugs recém-criados para que possamos identificá-los facilmente.

Exemplos:

❌ Ruim: “Não consigo ver o produto quando volto, digito que não.”

  • Vago
  • Agressivo
  • Muito prolixo

pede que uma solução seja implementada.

✅ Bom: “CARRINHO – Novos itens adicionados ao carrinho que não aparece”.

  • Este tipo de título localiza instantaneamente o problema (CART)
  • Ele se concentra no problema técnico real.

2) Gravidade do bug:

A gravidade do bug é um fator muito importante no relatório do bug. Descreve o efeito do defeito no desempenho do aplicativo.

  • Bloqueadores: Este erro faz com que o aplicativo falhe.
  • importante: Um erro crítico indica uma mudança importante na lógica de negócios.
  • Minor: Um problema que não afeta a funcionalidade do aplicativo, mas afeta os resultados esperados.
  • Trivial: Isso não afeta a funcionalidade ou operado aplicativo. Pode ser um erro tipográfico.

3) Prioridade de Bugs:

Following é a gradação geral para decidir a prioridade do bug:

  • High: Abrange qualquer coisa que afete o fluxo ou bloqueie o uso do aplicativo.
  • Meio: Isso afeta negativamente a experiência do usuário.
  • Minor: Todos os outros erros como (erros de digitação, ícones ausentes, problemas de layout, etc.).

4) Ambiente:

Um bug pode aparecer em um ambiente específico e não em outros. Por exemplo, às vezes aparece um bug ao executar o site em Firefoxou um mau funcionamento do aplicativo apenas quando executado em um Android dispositivo e funcionando bem no iPhone.

Esses relatórios de bugs só podem ser identificados com testes entre navegadores ou dispositivos. Portanto, ao relatar o bug, os QAs devem ser capazes de especificar se o bug deve ser observado em um ou mais ambientes específicos.

5) Resumo:

No entanto, adicionar apenas o título no relatório de bug não atende ao propósito. Portanto, se o seu título não for suficiente, você pode adicionar um breve resumo do relatório.

Seu resumo com o mínimo de palavras possível, incluindo quando e como o bug ocorreu. Seu título e descrição do bug também devem ser usados ​​nas pesquisas, portanto, você deve garantir que cobriu palavras-chave importantes.

Exemplos:

  • Bad: “Eu estava tentando adicionar coisas ao teste e nada apareceu quando fiz isso ou cliquei no botão.”
  • Bom: “Quando tentei adicionar [PRODUTO] ao carrinho de compras, mas nada aconteceu quando cliquei no botão 'adicionar' na página de visão geral do produto específico.”

6) Passos para reproduzir:

Ao relatar um bug, é importante especificar as etapas para reproduzi-lo. Você também deve incluir ações que possam causar o bug. Aqui, não faça declarações genéricas.

Seja específico nas etapas a seguir:

Aqui está um exemplo de procedimento bem escrito:

Passos:

  1. Selecione o produto X1.
  2. Clique em Adicionar ao carrinho.
  3. Clique em Remover para remover o produto do carrinho.

7) Resultado esperado:

Em relatórios de bugs, é importante descrever o resultado esperado de acordo com a tarefa técnica, o design dos resultados do caso de teste ou de acordo com a opinião do testador. Tudo isso ajuda os desenvolvedores a se concentrarem em encontrar rapidamente as informações necessárias.

Por exemplo:

Os campos obrigatórios devem ser destacados em vermelho após clicar no botão “Enviar”.

8) Resultado real:

Como o nome sugere, este campo descreve o efeito real do bug. É muito importante escrever uma descrição clara do resultado real.

Por exemplo:

Os campos obrigatórios são destacados em verde após clicar no botão “Enviar”.

9) Anexos (capturas de tela e vídeos):

Em relatórios de bugs, é uma prática recomendada anexar arquivos aos relatórios de bugs, o que facilita a percepção das informações quando você precisa exibi-las visualmente:

Por exemplo:

  • Captura de tela: As capturas de tela podem facilmente elaborar erros no programa; (é conveniente quando o bug é destacado com uma anotação específica, círculo ou imagem de seta).
  • Vídeo: Às vezes é difícil descrever o bug em palavras, então é melhor criar um vídeo para que o desenvolvedor possa corrigir o defeito no programa).

10) Versão afetada:

É a versão do software afetada onde o bug é relatado.

11) Versão de correção:

É a versão do software em que o bug foi resolvido. Portanto, quando o controle de qualidade que relatou o bug verifica se ele foi corrigido, ele usa a versão correta do software.

12) Versão alvo:

A versão alvo onde um bug deve ser direcionado para ser corrigido. Portanto, quando a equipe de desenvolvimento trabalha na correção de um bug, ela se concentra principalmente em uma versão específica do aplicativo.

13) Data de Fechamento:

É a data em que o bug é fechado pela equipe de testes de software. Fechar um bug é uma parte vital e integrante do teste de software.

14) Estado:

Quando um novo bug é criado, seu status deve ser aberto. Depois disso, passa por etapas como Em Andamento, Fixo, Em Execução, Reabrir, etc.

Dicas para escrever relatórios de bugs

Aqui estão algumas dicas importantes que você deve lembrar ao escrever um relatório de bug eficaz:

  • Seja específico ao criar relatórios de bugs. Certifique-se de não incluir fatos inúteis ou irrelevantes.
  • Você deve relatar o bug imediatamente assim que for detectado.
  • Prepare o relatório detalhadamente para capacitar o desenvolvedor a usar os fatos e as informações para depurar o problema.
  • Você deve testar a mesma ocorrência de bug em outros módulos semelhantes para validação.
  • Revise o relatório de bug pelo menos uma vez antes de enviá-lo.
  • Você deve garantir que o relatório do bug contenha a descrição de apenas um erro.
  • Por último, você não deve ter medo de pedir ajuda ao gerente de projeto se não tiver certeza sobre alguma coisa.

Ferramentas de relatório de bugs

O processo de relatório de bugs, realizado manualmente, agora está sendo realizado com diversas ferramentas de relatório de bugs disponíveis no mercado.

Você pode verificar nossa análise detalhada do melhor ferramenta de relatório de bugs.

Problema comum e solução ao escrever um relatório de bug:

Aqui estão alguns problemas comuns e suas soluções ao escrever um relatório de bug:

Exemplo de relatório de bug Problema
Ao multiplicar 2 por 3, a resposta será positiva. Relate o padrão, não um exemplo.
A lista será ordenada em ordem alfabética ao adicionar um novo item para evitar isso. Não descreva apenas o que há de errado
Por exemplo:
Para isso, você precisará abrir seu navegador e digitar a URL do site. Você encontrará o primeiro campo, 'nome de usuário', escrito incorretamente.
Sempre vá direto ao ponto (nunca conte a história!).
O nome do cliente no relatório está escrito incorretamente. Prioridade: Alta, Gravidade: Alta Nunca misture prioridade e gravidade.
A fórmula de cálculo do imposto está INCORRETA!!?? Não usa CAPS, letras vermelhas, círculos vermelhos, '!',
Não acho que o design Ul da página inicial seja bom. Não use seu julgamento.
Exemplo de descrição pouco clara: Sobre nossa discussão de hoje, execute as ações necessárias para esta página. Torne sua descrição compreensível para todos.
O fundo da página deve ser azul, laranja ou verde, ou você pode torná-lo preto ou branco.

Isso não é bom, pois não está claro o que é necessário da equipe de desenvolvimento e design web

Minimize as opções
A fórmula de cálculo do imposto às vezes não funciona conforme o esperado. A regra de ouro: não use a palavra 'às vezes'.

Exemplo de relatório de bug

Aqui está um pequeno exemplo de relatório de bug:

[MINHA CONTA] O sublinhado é exibidoyed ao passar o mouse sobre o botão Atualizar.

Descrição: Precisamos remover o sublinhado ao passar o mouse sobre o botão Atualizar na seção Minha conta.

link: http://test.com/mv-account/

Navegador/SO: Cromo 25.OSX Yosemite 10.10.2

Passos para reproduzir:

1. Acesse www.test.com

2. Faça login por meio de credenciais de login

3. Navegue até Minha conta

4. Passe o mouse sobre o botão Atualizar

Resultado atual: há um sublinhado.

Resultado esperado: sem sublinhado.

Dados de login: test@test.com/mysecretpass12

Deve evitar erros na redação de relatórios de bugs

Aqui estão alguns erros importantes que você deve evitar ao escrever um relatório de bug:

  • Não escreva sobre sua insatisfação e nunca inclua seus sentimentos pessoais.
  • Irrita as pessoas que querem se concentrar na tarefa quando você sobrecarrega sua postagem com muitos emoticons.
  • Nunca sobrecarregue sua postagem com pontos de exclamação; não acelera o trabalho.
  • Ninguém quer se sentir ofendido. Isso destrói a motivação e retarda a compreensão do problema.