Durante o ciclo de desenvolvimento de uma aplicação é comum encontrar falhas que tecnicamente são definidas como bugs de software. Esses problemas não podem ficar perdidos e devem ser coletados e organizados em uma ferramenta capaz de criar um bug report, para facilitar todo o processo de correção que virá a seguir.

Por bugs entendemos todo comportamento fora da especificação que dita os rumos do desenvolvimento. Portanto, sabendo que esses cenários não esperados podem acontecer, é preciso sempre testar a aplicação, a fim de validar que as regras de negócio são seguidas.

Mas como reportamos, na prática, os bugs de software encontrados durante nosso ciclo de testes? Este artigo trará algumas dicas úteis sobre como construir seu bug report de forma eficiente.

Siga um padrão para seu bug report

Primeiramente, é fundamental que o time envolvido em um projeto siga um padrão de bug report, pois isto facilitará muito o ato de catalogar e o entendimento sobre os problemas reportados. Algumas empresas já determinam o padrão desejado, mas caso este padrão ainda não exista, é preciso defini-lo.

Exemplos de padrões de bug report

Quando se fala em bug report, há alguns formatos já estabelecidos que ajudam a organizar a informação claramente. Cada um deles é pensado para coletar detalhes importantes que auxiliem os desenvolvedores a reproduzir o problema e encontrar a solução mais rapidamente. Veja alguns exemplos amplamente utilizados:

• Padrão clássico: é um modelo mais direto, geralmente dividido em Título, Descrição, Passos para Reproduzir, Comportamento Esperado, Comportamento Atual, e Informações Adicionais. É muito usado em ferramentas como JIRA e Bugzilla, onde a ênfase está no esquema de entendimento rápido do problema e reprodução facilitada;
• Padrão “Defeito como História do Usuário”: alguns times preferem relatar bugs no formato de histórias do usuário. Esse modelo é útil para focar na experiência do usuário. Um exemplo comum dele seria: “Como [tipo de usuário], eu quero [ação], para que [resultado desejado]”, seguido de uma descrição detalhada do problema. Trata-se de um formato mais usado em metodologias ágeis e ferramentas como Trello ou Azure DevOps.
• Padrão de Relatório de Incidente: muitas empresas adotam um relatório de incidente detalhando o que aconteceu, o porquê e como evitar problemas semelhantes. Esse padrão inclui também causas-raiz e soluções. Ferramentas como o Confluence são bastante aproveitadas para hospedar esses reports detalhados.

Agora, vamos a algumas dicas práticas sobre como estruturar seu bug report:

Estrutura para reportar bugs de software

Estruturar seções para escrever um bug report é importante para que as informações estejam coesas.

Comece por um título descritivo que resuma o problema de forma clara. Podem ser incluídos os ambientes em que foi identificado o defeito. Na sequência, indique a versão específica do software onde o bug foi encontrado e, por fim, descreva o ambiente onde o bug ocorreu. 

Toda essa organização já compõe um bom início de um bug report, porém ainda não é suficiente. É preciso, agora, descrever o bug. Mas antes, veja um exemplo até aqui:

**Título:** [DEV] [HML] Problema na Página de Login

**Versão do software:** 2.1.0

**Ambiente:** Desenvolvimento e Homologação/

Descreva o bug em detalhes

Um bug report completo precisa trazer detalhes do problema encontrado, tanto para documentação, como para facilitar a tomada de decisão.

Portanto, forneça uma descrição detalhada do bug, incluindo o que você esperava que acontecesse e o que realmente aconteceu.

Você identificou o bug, logo ninguém melhor para esmiuçar as etapas para reproduzi-lo. Então, liste os passos exatos que levaram à ocorrência do bug. Isso ajuda os desenvolvedores a reproduzirem o problema mais rapidamente.

Como um bug é uma intercorrência não esperada, faça uma comparação que ilustre o que aconteceu. Descreva o resultado esperado versus o resultado real, ou seja, destaque a discrepância entre os dois cenários.

Vamos aos exemplos:

**Descrição:**

Ao tentar fazer login, o sistema não reconhece as credenciais válidas. Recebo uma mensagem de erro "Erro de autenticação" em vez de ser redirecionado para o painel principal.

**Passos para reprodução:**

1. Abrir o Google Chrome.

2. Acesse a página de login (URL).

3. Insira o nome de usuário e senha válidos.

4. Clique no botão "Entrar".

**Resultado esperado vs. Resultado real:**

- Esperado: Redirecionamento para o painel principal.

- Real: Mensagem de erro "Erro de autenticação".

Use e abuse das evidências no bug report

Você já assistiu a uma série investigativa na TV? Quando há um crime, os policiais precisam procurar provas para incriminar o suspeito. Acontece o mesmo em um bom bug report, no qual as evidências estão nos anexos e mídias.

Ao relatar um bug de software, se possível, anexe as evidências com as capturas de tela, gravações ou até mesmo GIFs que mostram o problema. Outra possibilidade são os logs de erro. Inclua os mais relevantes, se disponíveis.

**Anexos:**

- Captura de tela do erro anexada.

Informação nunca é demais

Para enriquecer ainda mais o bug report, inclua todo o contexto adicional que for possível. Nessa etapa, você pode listar e detalhar itens como:

• Frequência: Especifique se o bug é replicável consistentemente ou ocorre ocasionalmente. Esta informação evita mal-entendidos durante a correção do defeito;
• Prioridade e severidade: Avalie a gravidade e urgência do bug com base no impacto ao usuário ou ao sistema. Se preciso, leve para o time as informações necessárias a fim de definir o nível de prioridade da resolução deste defeito, bem como a sua severidade;
• Ambiente específico: Informe se o bug ocorre apenas em circunstâncias/ambiente específicos. Isto agiliza a análise por parte do responsável por trazer uma solução;
• Informações com contexto: Navegadores/Sistemas Operacionais Afetados -  liste os navegadores ou sistemas operacionais nos quais o bug foi identificado;
• Histórico de eventos: Se possível, forneça detalhes sobre qualquer ação ou evento que possa estar relacionado ao bug.

**Frequência:** Ocorre consistentemente.

**Prioridade e severidade:** Média. Afeta todos os usuários, mas existe uma solução alternativa.

**Informações com contexto:** Acontece apenas no Chrome.

**Navegadores/sistemas operacionais afetados:** Google Chrome 99.0.1234.567, Windows 10.

Seja claro na linguagem

Ao redigir um bug report, é fundamental usar uma linguagem objetiva e descritiva, uma vez que estas informações serão consumidas por uma pessoa que deverá trazer uma resposta técnica a este defeito.

Bug reports mal escritos, além de dificultarem o entendimento do problema por quem o resolverá, podem gerar soluções com novos problemas devido ao mau entendimento do texto.

Portanto, é importante redigir tais relatórios da forma mais objetiva e descritiva possível, evitando usar jargões em demasia e presumir conhecimento prévio pela parte que consumirá estas informações.Para redigir bugs reports de qualidade com padrões de forma e escrita é necessário prática. É uma boa medida pedir para que seus pares revisem seus relatórios, avaliando a clareza do documento redigido.