Como escrever um relatório de bug

Nesse artigo, você pode encontrar as respostas para as perguntas: “como escrever relatório de bug”, “por que o relatório de bug é tão útil”, “onde deve criar relatório de bug”. Vamos tocar nos principais aspectos que você precisa saber para escrever relatórios de erros úteis e úteis.

Por que o relatório de bug é importanterelatório de erro

Você acabou de testar seu projeto e falha no teste. Meus parabéns, você encontra um bug. Agora você deve denunciá-lo.

No caso, se o seu relatório de erros estiver bom, ajudará seus desenvolvedores a consertá-lo e tornar o produto mais confiável.

Como isso ajuda os desenvolvedores exatamente:

  • fala sobre problemas que eles não conhecem
  • ajuda a determinar novos recursos que eles podem não ter pensado
  • ajuda a ter uma ideia de como seus clientes usam o software, para que eles possam torná-lo melhor

E se você escrever seu relatório de bug efetivamente, o bug terá mais chances de ser corrigido. Então corrigir bugs depende diretamente de como você os reporta.

O que é um bom relatório de bug?

Qualquer um pode escrever um relatório de bug. Mas nem todo mundo pode fazer isso de forma eficaz. Você deve ser capaz de distinguir entre um relatório de bug medíocre e um bom. Como distinguir um relatório de bug bom ou ruim?

Relatórios de bugs úteis são aqueles que resultam na correção desse bug. Um bom relatório de erros tem que ser:

  • Reprodutível  – Se reproduzir o bug não é possível, então não será corrigido. Tão logo e fácil quanto o desenvolvedor reproduzir e ver o bug, ele será corrigido. Caso contrário, é mais provável que o desenvolvedor simplesmente prossiga para o próximo relatório de bug. Na descrição do bug, você deve descrever claramente as etapas para reproduzir sem perder nenhum deles.
  • Específico e Informativo  – Não espalhe problema em todo o ensaio. Tente ser específico e maximizar de forma informativa. Esforce-se para resumir o problema em palavras mínimas, mas de maneira efetiva. E, em qualquer caso, não combine vários problemas, mesmo que pareçam semelhantes. Escreva relatórios diferentes para cada problema.

Então o objetivos  de um relatório de bug são para:

  • explicar um bug  para o desenvolvedor e mostrar onde é
  • ajudar o desenvolvedor  corrigi-lo com o custo de tempo mínimo

Conteúdo do relatório de bug

Título : No título deve ser uma breve explicação do que é o problema. Um bom título deve conter informações sobre o nome do produto ou a mensagem de erro ou as etapas que você estava executando quando falhou.
Por exemplo:

  • Como não  façam: ” Bater “,” Procurando um erro “,” Erro
  • Como fazer: ” Erro 5C79 ao confirmar a solicitação

Produtos:  Especifique o nome do produto e a versão do qual é operado.

  • Como não  façam: ” Sua aplicação
  • Como fazer: ” Agfa

Classificação : Muito importante para indicar é uma solicitação de recurso, um bug pequeno ou um bug horrível que causa falha em todo o aplicativo. A maioria de todas as ferramentas têm um conjunto para escolher, mas se não o fizerem, use um destes recursos: “Novo recurso”, “Aborrecimento menor”, “Erro fatal”, “Inseto grave” ou “Inseto menor” para aqueles que você pode trabalhar.

  • Como não  façam:  “Deixe em branco”
  • Como fazer:  “Bug sério”, “Aborrecimento”, “Solicitação de recurso”

Plataforma : Será uma grande vantagem para determinar o que você está usando para executar o software, particularmente o nome ea versão do sistema operacional, no caso do aplicativo da Web, deve informar o nome e a versão do navegador da Web. Existem muitas versões diferentes de sistemas e navegadores, o que é importante para os desenvolvedores saberem.

  • Como não  façam: ” janelas
  • Como fazer: ” Windows 7, Internet Explorer 9

Resumo : Tente descrever resumidamente o que você estava tentando fazer antes de encontrar o bug e como reagir a esse aplicativo. Tente usar uma linguagem natural simples e escreva todas as frases simples.

  • Como não  façam: ” Aplicativo não funciona
  • Como fazer: ” C lambeu em “Arquivo / Salvar como …” e a caixa de diálogo “Salvar” foi exibida  → C selecionado no botão “OK”, mas o arquivo não foi salvo.

Passos para reproduzir: istoll estar ótimo E se você capaz para reproduzir aquele bugnovamente. Porque doreprodutível insetos Mais fácil para consertar. Você devemos descrever como para reproduzir naquela erro passos por degrau, Como detalhado Como isto possível. Dont esqueço, você devo estar específico.

  • Como  não  façam: ”
    • Página inicial> Botão esquerdo> Clique nele
    • Loja> tente comprar smth> você não pode “
  • Como fazer: ”
    • Vá para Configurações> Perfil (isso levaria o usuário a uma nova tela)
    • Toque em Mais opções> Excluir conta

Resultado esperado:  O que deve acontecer quando você faz uma ação?

  • Como  não  façam: ” I tentou para impressão, mas isto não fez trabalhos
  • Como fazer: ” De a ‘Fazer compras’ tela, clique em aImpressãobotão

Resultado atual:  Aqui está o resultado do bug. Como de costume, os testadores são um pouco indefinidos nesta parte do relatório de erros. Então, tente ser conciso.

  • Como  não  fazer: “Button não funciona como esperado”
  • Como fazer: “Button fecha app”

Prioridade:  Está mostrando ao desenvolvedor quanto tempo ele precisa ser consertado. A prioridade é geralmente definida de 1 a 5. Quanto menor o número, maior a prioridade. 1 pontuação – deve ser corrigido o quanto antes. Pontuação 5 – pode corrigir quando o tempo permitir.

Gravidade: Isso descreve o impacto do bug.

Tipos de gravidade:

 

  • Bloqueador:  Nenhum outro trabalho de teste pode ser feito.
  • Crítico:  Queda de aplicativo, perda de dados.
  • Principal:  Grande perda de função.
  • Menor:  Pequena perda de função.
  • Trivial:  Alguns aprimoramentos da interface do usuário.
  • Aprimoramento: Solicitação de um novo recurso ou algum aprimoramento no já existente.

Status: Está mostrando o status de um relatório de bug em qualquer sistema de rastreamento de bugs. No início, o status do relatório de erros será “Novo”. Depois disso, o status pode mudar como Fixo, Verificado, Reabrir, Não Corrigir e etc. Todos os vários status que você verá abaixo Ciclo de vida do relatório de bugs
Anexos : Se você pode tirar uma foto – faça isso. Será uma enorme vantagem para o desenvolvedor ver o que você viu antes do bug e depois. Basta anexar algumas capturas de tela para o relatório de erros.Como executar casos de teste, ferramenta de gerenciamento de testes do EasyQA, controle de qualidade, software, teste, login, registro, caso de teste, teste de execução, execução de caso de teste, saas, EasyQA

Aqui está um exemplo de sistema de rastreamento de bugs – EasyQA , que tem todos os campos necessários para escrever o relatório de erros.

Ciclo de vida do relatório de bugs

O ciclo de vida do relatório de bug começa com o bug sendo detectado e relatado pelo testador e termina após o encerramento. Durante todo o ciclo de vida do bug tem estados diferentes.
O esquemático ciclo da vida  pode ser mostrado neste gráfico :

ciclo da vida
Erro ciclo de vida inclui os seguintes passos ou status:

  1. Novo: Quando um bug é reportado e postado pela primeira vez. Seu estado é dado como novo.
  2. Atribuído: Depois que o testador informar o bug, o líder do testador confirmará se o defeito é válido e será atribuído ao desenvolvedor ou à equipe de desenvolvedores apropriada.
  3. Abrir:  Isso significa que o desenvolvedor começou a analisar o bug e tentar corrigi-lo.
  4. Fixo: Depois que o desenvolvedor alterou o código e corrigiu o bug, ele alterou o estado para “Fixo” e pode ser passado para a equipe de controle de qualidade para novo teste.
  5. Retestar pendente :  Neste relatório de bug estágio aguardando para retestar.
  6. Retestar :  Nesta fase, os testadores verificam as alterações e testam novamente as alterações que os desenvolvedores fizeram.
  7. Verificado :  Se o novo teste não for detectado e o produto estiver funcionando corretamente, o testador alterará o status do relatório de erros em “Verificado”.
  8. Reabrir: Reabertura: caso o testador volte a verificar e o bug ainda exista, o estado do bug se tornando “Reabertura” e o relatório de bug passa pelo ciclo de vida novamente.
  9. Fechadas: Uma vez que o desenvolvedor tenha corrigido os erros, ele envia o produto para os testadores para o novo teste. Se o testador decidir que o bug foi corrigido, ele altera o status do relatório de bug para “Fechado”. Isso significa que o defeito é fixo, verificado e aprovado.
  10. Duplicado: Se o bug é repetido duas vezes ou os dois bugs mencionam o mesmo conceito do bug, então um status do bug é alterado para “duplicar “.
  11. Rejeitado: Se o desenvolvedor achar que o bug não é genuíno, ele rejeita o bug. Em seguida, o estado do bug é alterado para “rejeitado”.
  12. Diferido:  Isso significa que o bug será corrigido, mas em outra versão, e agora está aguardando. Normalmente, a razão para isso é a baixa prioridade de erros e falta de tempo.
  13. Não é um bug: O relatório de bagagem pode ter esse status, no caso de, por exemplo, se um cliente pedir para fazer pequenas alterações no produto: alterar a cor, a fonte e muito mais.

Dicas para escrever relatos de bugs

  1. O que estava acontecendo antes:  Para corrigir os erros, os desenvolvedores precisam reproduzir todo o fluxo de trabalho que o testador e o sistema fazem. Portanto, não se esqueça de descrever as etapas de maneira específica e informativa.
  2. Seja específico:  Você deve escrever os mesmos nomes de campos, botões e outros itens que são nomeados no aplicativo. Se você quiser descrever a mensagem, copie e cole toda a mensagem na descrição do relatório de erros.
    • Para menus : Siga a sequência de menus separados pelo caractere “/”, por exemplo, “Arquivo / Salvar como …”
    • Para telas : Olhe no topo da janela e digite exatamente o que está lá
    • Para botões ou guias : Copie e cole o texto exato mostrado
    • Para links:  Copie e cole o URL inteiro (incluindo o “http: //”)
  3. Não fique pessoal:  Quando você está relatando o bug, não se esqueça de informar sobre o defeito do software, não sobre o defeito do desenvolvedor. Seja educado e específico. Relatórios de bugs com linguagem ofensiva e emocional serão ignorados pelos desenvolvedores.
  4. Anexar ou Copiar e Colar:  Você deve anexar capturas de tela, vídeo, mensagens e etc. o mais possível. Isso ajudará os desenvolvedores a encontrarem o problema mais fácil e rapidamente
  5. Um defeito por relatório: Nem mais nem menos. Um único bug em um relatório pode ajudar a evitar duplicação e confusão. Se você descrever muitos defeitos, alguns deles podem passar despercebidos.
  6. Reproduza o bug antes de escrever um relatório de bug: Certifique-se de que suas ações levem a reproduzir o bug sem ambigüidade. O defeito deve ser reproduzível.
  7. Escreva um bom resumo:  Será mais fácil para um desenvolvedor analisar a natureza do bug. Um defeito deficiente relata o teste de resíduos e o tempo de desenvolvimento

.gif
Eu desejo que você tenha apenas os ótimos relatórios de bugs e em qualquer caso – não fique chateado. Tudo vem com a prática. Então …