Porquê um bom Relatório de Bug?

Se o seu Relatório de Bug é eficaz, então as suas hipóteses de ser corrigido são maiores. Então a correção de um bug depende da eficácia com que você o reporta. Relatar um bug não é nada além de habilidade e eu explicarei como atingir esta habilidade.

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

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.,).

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

Anyone pode escrever um relatório de bug. Mas nem todos podem escrever um relatório de bugs efetivo.

Você deve ser capaz de distinguir entre um relatório de bugs médio e um bom relatório de bugs. Como distinguir entre um bom e um mau relatório de bugs? É 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 único para cada relatório de bug. Isto, por sua vez, ajudará você a identificar o registro do bug. Se você estiver usando qualquer ferramenta automática de relatório de bugs então este número único será gerado automaticamente a cada vez que você relatar o bug.

Note 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, então ele nunca será corrigido.

Você deve mencionar claramente os passos 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.

Sê Específico e ao ponto. Tente resumir o problema em palavras mínimas ainda de uma forma eficaz. Não combine vários problemas mesmo que pareçam ser semelhantes. Escreva relatórios diferentes para cada problema.

Relatar Bug Efetivos

Relatar Bug é um aspecto importante dos Testes 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 ausente. Qualquer falta de clareza leva a mal-entendidos e atrasa o processo de desenvolvimento também. Escrever e relatar defeitos é uma das áreas mais importantes mas negligenciadas no ciclo de vida do teste.

Bom escrita é muito importante para arquivar um bug. O ponto mais importante que um testador deve ter em mente é não usar um tom de comando no relatório. Isto quebra a moral e cria uma relação de trabalho pouco saudável. Use um tom sugestivo.

Não assuma 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 testes. Verifique a lista completa de bugs conhecidos. Às vezes, os desenvolvedores podem ter conhecido o problema e ignorado para um lançamento futuro. Ferramentas como o Bugzilla que automaticamente procura por bugs duplicados também podem ser usadas. Entretanto, é melhor procurar manualmente por qualquer bug duplicado.

A informação de importação que um relatório de bug deve comunicar é “Como?” e “Onde?”. O relatório deve responder claramente como o teste foi realizado e onde o defeito ocorreu exatamente. O leitor deve facilmente reproduzir o bug e encontrar onde o bug está.

Cuidado que o objetivo de escrever o relatório de bug é permitir ao desenvolvedor visualizar o problema. Ele/ela deve entender claramente o defeito do relatório de Bug. Lembre-se de dar todas as informações relevantes que o desenvolvedor está procurando.

Tambem, 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 sentenças significativas e palavras simples para descrever seus bugs. Não use declarações confusas que desperdiçam o tempo do revisor.

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

Aonde é melhor dividir os problemas em bugs separados. Isto assegura que cada bug pode ser tratado separadamente. Um relatório de bug bem escrito ajuda o desenvolvedor a reproduzir o bug em seu terminal. Isto os ajuda a diagnosticar o problema também.

Como Relatar um Bug?

Utilizar o seguinte modelo simples de relatório de Bug:

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

Reporter: Seu nome e endereço de e-mail.

Produto: Em qual produto você encontrou este bug.

Version: A versão do produto se houver.

>

Componente: Estes são os principais sub-módulos do produto.

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

Sistema operativo: Mencione todos os sistemas operacionais onde você encontrou o bug. Sistemas operativos como Windows, Linux, Unix, SunOS, Mac OS. Mencione as diferentes versões do SO 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 “corrigir o bug com a maior prioridade” e P5 como “corrigir quando o tempo permitir”.

Severidade: Isto descreve o impacto do bug.
Tipos de Severidade:

• Bloqueador: Nenhum trabalho de teste adicional pode ser feito.
• Crítico: Falha da aplicação, perda de dados.
• Major: Perda maior da função.
• Menor: Menor perda de função.
• Trivial: Alguns aprimoramentos de IU.
• Aprimoramento: Pedido para um novo recurso ou alguma melhoria no existente.

Status: Quando você estiver registrando o bug em qualquer sistema de acompanhamento de bugs, então por padrão o status do bug será ‘New’.
Later on, o bug passa por vários estágios como Fixed, Verified, Reopen, Won’t Fix, etc.

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

Assign To: Se você sabe qual desenvolvedor é responsável por aquele módulo em particular no qual o bug ocorreu, então você pode especificar o endereço de e-mail daquele desenvolvedor. Caso contrário, mantenha-o em branco, pois isto irá atribuir o bug para o dono do módulo se não for o Gerente irá atribuir o bug para o desenvolvedor. Possivelmente adicione o endereço de e-mail do gerenciador na lista CC.

URL: A URL da página na qual o bug ocorreu.

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

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

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

• Reproduza os passos: Claramente, mencione os passos para reproduzir o bug.
• Resultado esperado: Como a aplicação deve se comportar nos passos acima mencionados.
• Resultado real: Qual é o resultado real da execução dos passos acima mencionados, ou seja, o comportamento do bug.

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

Tipos de relatório incluem:

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

Características importantes no relatório de bug

Dados abaixo estão as características 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 bugs e a referência a um bug muito mais fácil. O desenvolvedor pode facilmente verificar se um bug em particular foi corrigido ou não. Ele torna todo o processo de teste e re-teste mais suave e fácil.

#2) Título do Bug

Um título de Bug é lido mais frequentemente do que qualquer outra parte do relatório de bug. Ele 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 claro do bug torna fácil de entender e o leitor pode saber se o bug foi relatado anteriormente ou foi corrigido.

#3) Prioridade

Baseado na severidade do bug, uma prioridade pode ser definida para ele. Um bug pode ser um Blocker, Critical, Major, Minor, Trivial, ou uma sugestão. Uma prioridade de bug de P1 a P5 pode ser dada para que os importantes sejam vistos primeiro.

#4) Plataforma/Ambiente

A configuração do SO e do navegador é necessária para um relatório de bug claro. É a melhor maneira 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 final do desenvolvedor. Então é melhor mencionar 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. A má descrição irá criar confusão e desperdiçar o tempo dos desenvolvedores e dos 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, ao invés de desmoroná-los por completo. Não use termos como “Eu acho” ou “Eu acredito”.

#6) Passos para Reproduzir

Um bom relatório de Bug deve mencionar claramente os passos para reproduzir. Os passos devem incluir as ações que causam o bug. Não faça afirmações genéricas. Seja específico nos passos a seguir.

Um bom exemplo de procedimento bem escrito é dado abaixo

Passos:

• Selecione o produto Abc01.
• Clique em Adicionar ao carrinho.
• Click Remove to remove the product from the cart.

#7) Resultado esperado e real

A descrição do bug está incompleta sem os resultados esperado e real. É 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) Screenshot

Uma imagem vale por mil palavras. Tire uma Screenshot da instância de falha com o devido legenda para destacar o defeito. Destaque as mensagens de erro inesperadas com cor vermelha clara. Isto chama a atenção para a área requerida.

Some Bonus Tips To Write A Good Bug Report

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

#1) Relate o problema imediatamente

Se você encontrar algum bug enquanto estiver testando, então não precisa esperar para escrever um relatório de bug detalhado mais tarde. Ao invés disso, escreva o relatório de bugs imediatamente. Isto irá assegurar um bom e reprodutível relatório de bug. Se você decidir escrever o relatório de bug mais tarde então há grandes chances de perder os passos importantes no 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 seus passos são robustos o suficiente para reproduzir o bug sem qualquer ambiguidade. Se o seu bug não for reproduzível toda vez que você ainda puder arquivar um bug mencionando a natureza periódica do bug.

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

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

#4) Escreva um bom resumo do bug

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

#5) Leia o relatório de bug antes de pressionar o botão Submit

Leia todas as frases, palavras e passos que são usados 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 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 que seu relatório de bug deve ser um documento de alta qualidade.

Focalize na escrita de bons relatórios de bug e gaste algum tempo nesta tarefa porque este é o principal ponto de comunicação entre o testador, o desenvolvedor e o gerente. Gerentes devem criar uma consciência de sua equipe que escrever um bom relatório de Bug é a principal responsabilidade de qualquer testador.