O que é um bug report
Bug report (ou relatório de bug) é o registro de um defeito encontrado em um sistema: o comportamento errado, o comportamento esperado, os passos para reproduzir e as evidências. Ele vira um card no Jira, um work item no Azure DevOps ou um chamado no service desk, e é por ele que o desenvolvedor começa a investigar.
Os campos de um bom bug report
- Título curto e específico: o que falha e onde ("Cupom retorna erro 500 no checkout").
- Ambiente: URL, navegador e versão, sistema operacional, tamanho da tela, usuário ou perfil.
- Passos para reproduzir, numerados, a partir de um estado inicial claro.
- Resultado esperado.
- Resultado obtido, com a mensagem exata de erro.
- Severidade e impacto: quem é afetado e se existe contorno.
- Evidências: screenshots ou vídeo, requisições com falha (status, request e response) e erros do console.
- Frequência: sempre, às vezes, só com certos dados.
Modelo de bug report para copiar
Título: [Checkout] Aplicar cupom retorna erro 500 quando já existe desconto
Ambiente: https://loja.exemplo.com · Chrome 130 · Windows 11 · 1920×1080
Usuário: cliente comum, carrinho com 2 itens
Passos para reproduzir:
1. Adicionar 2 produtos ao carrinho
2. Ir para o checkout (o desconto de primeira compra já aparece)
3. Informar o cupom BEMVINDO10 e clicar em "Aplicar"
Resultado esperado: cupom aplicado ou mensagem clara de que não acumula.
Resultado obtido: "Erro inesperado"; o total não muda.
Severidade: alta — bloqueia o uso de cupom para novos clientes.
Frequência: sempre.
Evidências:
- POST /api/cart/coupon → 500 response {"error":"discount already applied"}
- Console: TypeError: Cannot read properties of undefined (reading 'total')
- Vídeo/GIF dos passos e relatório completo em anexoErros que fazem o bug voltar
- "Não funciona" sem dizer o quê, onde e com qual mensagem.
- Passos que pulam etapas ou dependem de algo que só quem reportou sabe.
- Print sem contexto: não mostra a URL, os dados nem o que veio antes.
- Sem network e console — o dev precisa reproduzir só para ver o erro.
- Vários problemas em um único bug.
- Severidade "crítica" para tudo.
Bug report manual x automático
| Manual | Com a Capto | |
|---|---|---|
| Tempo para montar | Print, texto e DevTools montados à mão | O tempo de reproduzir o problema |
| Passos | Escritos de memória | Gravados dos cliques e inputs reais |
| Evidências técnicas | Depende de quem reporta saber abrir o DevTools | Network, console e ambiente capturados sempre |
| Texto do report | Varia de pessoa para pessoa | A IA reescreve em linguagem técnica e padronizada |
| Causa | O dev investiga do zero | A IA aponta arquivo, linha e correção sugerida (com repositório conectado) |
Como gerar o bug report automaticamente
- Instale a extensão da Capto no Chrome.
- Descreva em uma frase o que você tentou fazer.
- Reproduza o problema. A Capto grava passos, screenshots, network e console.
- Revise o texto que a IA escreveu (resumo, passos, esperado x obtido, severidade).
- Envie: o card é criado no Jira Software, no Jira Service Management ou no Azure DevOps com tudo anexado.
Perguntas frequentes
Qual a diferença entre bug report e relatório de bug?
Nenhuma: são o mesmo documento. "Bug report" é o termo em inglês que o mercado de QA e desenvolvimento usa no Brasil.
Quem deve escrever o bug report?
Quem encontrou o problema: QA, suporte, produto ou o próprio cliente. Com a Capto, mesmo quem não é técnico gera um report completo, porque o contexto técnico é capturado automaticamente.
Precisa de vídeo no bug report?
Ajuda em bugs de fluxo e de interface. Mais importante que o vídeo são os passos, o resultado obtido com a mensagem exata e as requisições que falharam.
Onde registrar o bug report?
Na ferramenta que o time de desenvolvimento usa: Jira, Azure DevOps ou o service desk. A Capto envia direto para Jira Software, Jira Service Management e Azure DevOps Boards.