Encontrar um defeito em um sistema é só metade do trabalho de quem testa software. A outra metade é comunicar esse defeito de forma que qualquer pessoa da equipe consiga entender, reproduzir e corrigir. Um relatório de bug confuso gera idas e vindas, perda de tempo e, muitas vezes, um problema que continua em produção. Neste artigo, você vai aprender a estruturar um relatório de bug claro e útil.
O que é um relatório de bug e por que ele importa
Um relatório de bug (ou relatório de defeito) é o registro formal de um comportamento do software que diverge do esperado. Ele costuma ser cadastrado em uma ferramenta de acompanhamento de tarefas e serve de ponte entre quem testa e quem desenvolve.
Um bom relatório poupa tempo de todos. Quando o desenvolvedor consegue reproduzir o problema na primeira tentativa, a correção começa imediatamente. Quando falta informação, ele precisa perguntar, esperar a resposta e tentar adivinhar o cenário, o que atrasa a entrega.
Os elementos essenciais de um bom relatório
Cada equipe adapta o modelo à sua realidade, mas alguns campos aparecem quase sempre:
- Título: uma frase curta que resume o problema e onde ele ocorre.
- Ambiente: sistema operacional, navegador, versão do aplicativo, dispositivo e tipo de conta usada.
- Pré-condições: o que precisava estar configurado antes do teste, como um usuário cadastrado ou um item no carrinho.
- Passos para reproduzir: sequência numerada, na ordem exata em que as ações foram feitas.
- Resultado esperado: o que deveria acontecer segundo o requisito.
- Resultado obtido: o que realmente aconteceu.
- Evidências: capturas de tela, vídeos, mensagens de erro e registros (logs), quando disponíveis.
- Severidade e prioridade: o tamanho do impacto e a urgência da correção.
Como escrever um título que ajuda
O título é a primeira coisa que as pessoas leem e é por ele que o bug será localizado depois. Evite frases vagas como “Erro no sistema” ou “Não funciona”. Prefira algo que informe o local e o sintoma.
| Título fraco | Título melhor |
|---|---|
| Erro ao salvar | Formulário de cadastro não salva quando o campo telefone está vazio |
| Botão quebrado | Botão “Finalizar compra” não responde ao clique no navegador móvel |
| Tela travando | Tela de relatórios congela ao filtrar por períodos superiores a um ano |
Passos para reproduzir: o coração do relatório
Esta é a parte mais importante. Escreva como se estivesse explicando para alguém que nunca viu a tela. Use verbos de ação e um passo por linha:
- Acesse a página de login com um usuário comum.
- Clique em “Meu perfil”.
- Apague o conteúdo do campo “Telefone”.
- Clique em “Salvar”.
Depois, informe com que frequência o problema acontece: sempre, às vezes ou apenas uma vez. Se ele for intermitente, registre o que você observou sobre as condições em que apareceu. Isso já é uma pista valiosa.
Resultado esperado versus resultado obtido
Separar esses dois campos deixa claro por que aquilo é um defeito. O resultado esperado deve vir de uma fonte confiável, como o requisito, a história de usuário ou o protocolo de teste. Se o comportamento correto não estiver definido em lugar nenhum, vale conversar com a pessoa responsável pelo produto antes de abrir o registro, pois o problema pode ser uma dúvida de requisito, e não um bug.
Exemplo: “Esperado: o sistema salva o perfil e exibe a mensagem de sucesso. Obtido: o sistema exibe uma página em branco e nenhuma alteração é gravada.”
Evidências que fazem diferença
Uma imagem costuma explicar mais do que um parágrafo inteiro. Anexe capturas de tela com a região do problema destacada e, quando houver animação ou sequência de ações, um vídeo curto de gravação de tela. Copie a mensagem de erro exatamente como aparece, sem parafrasear. Se você tiver acesso ao console do navegador ou aos registros da aplicação, inclua os trechos relevantes.
Cuidado com dados sensíveis: ao anexar evidências, esconda senhas, dados pessoais reais e informações confidenciais.
Severidade e prioridade não são a mesma coisa
Os dois conceitos são frequentemente confundidos. A severidade mede o impacto técnico do defeito sobre o sistema; a prioridade indica a urgência de corrigi-lo, considerando o negócio.
| Situação | Severidade | Prioridade |
|---|---|---|
| Sistema fecha sozinho ao abrir uma função raramente usada | Alta | Pode ser baixa |
| Erro de ortografia no nome da empresa na página inicial | Baixa | Pode ser alta |
| Pagamento não é concluído para todos os clientes | Alta | Alta |
Em muitas equipes, quem testa sugere a severidade e o time de produto define a prioridade. Combine esse fluxo com o seu grupo.
Erros comuns ao relatar bugs
- Misturar vários problemas em um único registro, o que dificulta o acompanhamento e a correção.
- Usar linguagem acusatória ou emocional. O foco é o produto, não as pessoas.
- Omitir o ambiente, algo essencial quando o defeito só ocorre em determinado navegador ou aparelho.
- Não verificar se o bug já foi registrado, gerando duplicidades.
- Descrever suposições como se fossem fatos, por exemplo afirmar a causa sem ter investigado.
Um modelo simples para começar
Se você está começando, use esta estrutura como roteiro: título objetivo, ambiente, pré-condições, passos numerados, resultado esperado, resultado obtido, frequência, evidências e severidade sugerida. Releia antes de enviar e se pergunte: “Uma pessoa que não estava comigo consegue reproduzir isso só com este texto?” Se a resposta for sim, o relatório está pronto.
Conclusão
Escrever bem um relatório de bug é uma habilidade prática que melhora com a repetição e que diferencia profissionais de QA atentos. Clareza, objetividade e evidências são os três pilares. Se você quer aprofundar seus conhecimentos em testes, qualidade e técnicas de documentação, vale conhecer os cursos de informática e testes de software disponíveis na Cursa, que ajudam a transformar a teoria em rotina de trabalho.
