O resultado mais comum de um bug report mal escrito: o desenvolvedor não consegue reproduzir o problema, marca como "Cannot Reproduce" e segue em frente. O bug ainda existe. Cada elemento de um relatório eficaz previne uma falha específica. Um título preciso previne o roteamento errado. Passos numerados e exatos com pré-condições previnem o desfecho de "não consigo reproduzir". Resultados esperado e atual separados impedem desenvolvedores de despriorizarem o que não conseguem avaliar.

Por que bug reports falham

O resultado mais comum de um bug report mal escrito: o desenvolvedor abre, não consegue reproduzir o problema, marca como "Cannot Reproduce" e segue em frente. O bug ainda existe. Você perdeu tempo. O desenvolvedor está levemente irritado. Ninguém ganha.

O segundo resultado mais comum: o desenvolvedor reproduz mas não entende o impacto, desprioriza, e o bug vai para produção.

Ambas as falhas são evitáveis.

A anatomia de um bug report que é corrigido

Título: uma frase, sem palavras vagas

O título é o que aparece no Jira ou qualquer tracker que seu time usa. Deve dizer a um desenvolvedor lendo uma lista de tickets exatamente qual é o bug, sem precisar abrir.

Títulos ruins:

  • "Bug no login"
  • "Algo quebrado no dashboard"
  • "Problema com mensagem de erro"
  • "Tabela não funciona corretamente"

Títulos bons:

  • "Formulário de login envia com campo de senha vazio: nenhum erro de validação exibido"
  • "Tabela do dashboard perde a ordenação após filtrar por status"
  • "Upload de arquivo mostra toast 'Sucesso' mesmo quando upload falha com erro 413"
  • "Contagem de linhas da tabela de itens difere da resposta da API quando a página carrega com filtro ativo"

O padrão: [componente/feature] [o que acontece] [quando/sob qual condição]. Tudo que um desenvolvedor precisa para entender o escopo do problema, antes de clicar para abrir.

Ambiente: exatamente onde isso acontece

Vago: "Chrome no Windows"

Útil:

Navegador: Chrome 124.0.6367.78 (Windows 11)
OS: Windows 11 22H2
Versão/build do app: v2.4.1 (commit: abc123)
Ambiente de teste: staging (https://staging.lab.becomeqa.com)
Usuário de teste: admin@becomeqa.com

Detalhes de ambiente parecem tediosos até você tentar reproduzir um bug que só acontece no Firefox no macOS. São 20 minutos rodando Chrome no Windows sem entender por que não falha.

Passos para reproduzir: exatos, numerados, autossuficientes

Cada passo deve ser tão específico que alguém que nunca viu esse bug antes consiga reproduzi-lo na primeira tentativa.

Ruim:

1. Fazer login
2. Ir para os itens
3. Ordenar e filtrar
4. Bug aparece

Bom:

Pré-condições: Usuário logado como admin@becomeqa.com. 
A tabela de itens exibe a visualização padrão (sem filtros ativos).

Passos:
1. Navegar para https://lab.becomeqa.com/dashboard
2. Clicar no cabeçalho da coluna "Status" para ordenar crescente
3. Clicar no dropdown "Filtrar" e selecionar "Planejado"
4. Clicar novamente no cabeçalho da coluna "Status" para ordenar decrescente
5. Remover o filtro clicando em "Limpar" no dropdown de filtro

Resultado esperado: A tabela retorna à visualização padrão mostrando todos os itens, 
ordenada pela última ordem de classificação (Status decrescente).

Resultado atual: A tabela mostra todos os itens, mas a ordem de classificação volta ao padrão 
(sem ordenação), perdendo o estado de ordenação do passo 2.

A diferença: a primeira versão exige que o leitor adivinhe o que "ordenar e filtrar" significa. A segunda não exige nenhuma adivinhação.

Resultado esperado vs. resultado atual: ambos obrigatórios, não apenas um

Todo bug report precisa dos dois:

Resultado esperado: o que deveria acontecer de acordo com a especificação, o senso comum, ou a intenção do desenvolvedor. Se há um requisito documentado, referencie-o. "De acordo com os critérios de aceite em PROJ-142, filtrar não deve afetar o estado de ordenação." Resultado atual: o que realmente acontece. Seja preciso. "Mostra um erro" é fraco; "exibe 'Internal Server Error' em um toast vermelho no topo da página por 3 segundos" é útil.
Não escreva "Esperado: funcionar. Atual: não funciona." Essa é a falha mais comum em bug reports de QA iniciantes. O resultado esperado deve descrever o comportamento correto específico, não apenas "funcionando."

Severidade e prioridade: coisas diferentes

Severidade é o impacto no sistema: qual é a gravidade técnica desse bug?
  • Crítica: crash do sistema, perda de dados, vulnerabilidade de segurança, bloqueia funcionalidade principal para todos os usuários
  • Maior: feature significativa quebrada para um subconjunto de usuários, tem um workaround
  • Menor: pequeno problema funcional, cosmético, improvável de afetar muitos usuários
  • Trivial: erro de digitação, inconsistência visual menor, sem impacto funcional
Prioridade é a urgência de negócio: com que rapidez isso precisa ser corrigido?

Um erro de digitação na página de erro de um produto de saúde pode ser severidade Menor mas prioridade Alta (preocupação regulatória). Uma feature de admin quebrada pode ser severidade Maior mas prioridade Baixa (usada uma vez por mês por 2 pessoas).

Definir severidade e prioridade com precisão sinaliza que você entende o impacto no negócio, não apenas o comportamento técnico.

Anexos: mostre, não apenas descreva

Screenshots capturam o resultado atual visualmente. Um screenshot mostrando o toast de mensagem errada vale mais do que três frases descrevendo-o.

Gravações de vídeo são inestimáveis para bugs dependentes de timing: race conditions, falhas de animação, falhas intermitentes. Softwares de gravação de tela (Loom, OBS, ShareX) levam 30 segundos para configurar e evitam horas de "cannot reproduce."

Logs de rede (do DevTools do navegador, aba Network) são críticos para bugs em nível de API. Eles mostram exatamente qual requisição foi enviada, qual resposta voltou, e o timing.

Logs do console frequentemente contêm o erro que explica o bug. Desenvolvedores conseguem identificar a causa raiz imediatamente a partir de um stack trace de erro JavaScript.

Para bugs intermitentes, grave um vídeo na primeira reprodução. Não assuma que você vai conseguir reproduzir de novo para o desenvolvedor.

Um exemplo completo

Como fica um bug report bem escrito:

Título: Modal de upload de arquivo mostra toast "Upload realizado com sucesso" quando o arquivo excede o limite de 5MB Ambiente:
  • Navegador: Chrome 124, Firefox 125
  • OS: Windows 11
  • Build: v2.4.1
  • Ambiente: staging
Pré-condições: Usuário logado como admin@becomeqa.com Passos para reproduzir:

1. Navegar para https://staging.lab.becomeqa.com/dashboard

2. Clicar no botão "Upload de Arquivo"

3. Selecionar um arquivo maior que 5MB (ex: um .pdf de 10MB)

4. Clicar em "Upload" no modal

Resultado esperado: Upload falha com erro de validação: "O tamanho do arquivo deve ser 5MB ou menos." O arquivo não é enviado. O toast de sucesso não aparece. Resultado atual: Modal fecha, toast "Upload realizado com sucesso" aparece brevemente. Ao navegar para a seção Arquivos, o arquivo não está presente, indicando que o upload falhou silenciosamente. Nenhum erro é comunicado ao usuário. Severidade: Maior. Usuários perdem o upload sem nenhum feedback, e podem não perceber que o arquivo não foi salvo. Prioridade: Alta. Afeta qualquer usuário tentando fazer upload de arquivos acima do limite de tamanho. Anexos: [screenshot mostrando toast de sucesso] [log de rede mostrando resposta 413]

Esse relatório dá ao desenvolvedor tudo: reprodução exata, comparação clara de esperado/atual, avaliação precisa de severidade, e evidências.

Erros comuns a evitar

"Não está funcionando" sem dizer o que deveria acontecer. Sempre especifique o comportamento esperado. Passos que assumem conhecimento. "Fazer login como admin." Qual admin? Qual URL? Quais credenciais? Pré-condições ausentes. Bugs que só acontecem com certos dados, certos papéis de usuário, ou após certas ações anteriores precisam desse contexto na seção de pré-condições. Títulos de uma linha. "Bug de pagamento registrado." Registrado contra qual cenário? Inflação de severidade. Chamar tudo de Crítico torna o Crítico sem significado. Reserve para perda de dados, problemas de segurança, e features completamente quebradas para todos os usuários. Sem limpeza de dados de teste. Se seus passos de reprodução criaram dados de teste (um novo usuário, um pedido, um arquivo), anote para que alguém possa limpar sem precisar de um admin de banco de dados.

FAQ

Devo escrever bug reports para cada problema que encontro?

Registre tudo que não está funcionando conforme o esperado. Desenvolvedores e responsáveis de produto podem fechar ou despriorizar, mas não podem corrigir o que não sabem. A exceção são coisas que você não tem certeza se são bugs: levante primeiro em um comentário ou mensagem rápida.

E se não conseguir reproduzir o bug de forma consistente?

Registre mesmo assim. Anote no bug report: "Intermitente: reproduzido 3 de 10 tentativas. Não foi possível identificar um gatilho consistente." Anexe um vídeo de uma reprodução. Um bug intermitente registrado é melhor do que um que não foi registrado.

Qual o nível de detalhe dos passos de reprodução?

Detalhado o suficiente para que um desenvolvedor que acabou de entrar no time consiga reproduzir sem fazer uma única pergunta. Na dúvida, erre pelo lado de mais detalhe.

Meu bug foi marcado como "by design." Eu errei?

Não necessariamente. "By design" significa que o responsável de produto decidiu que o comportamento atual é aceitável. Esse é um resultado legítimo. O que importa é que você documentou o comportamento com clareza. Se está causando confusão ao usuário, essa conversa deve acontecer antes da decisão do produto ser tomada, não depois.

→ Veja também: Como Escrever um Caso de Teste: Formato, Exemplos e Erros Comuns | O que é Teste Manual? O Guia Completo para 2026