O que fazer com um relatório de bug que você não consegue reproduzir

reproduçãoDenis Povarov30 de agosto de 2026

O relatório está parado no seu bug tracker. O usuário viu acontecer, e você acredita nele, mas na sua máquina tudo funciona, e você já gastou uma hora provando isso. E agora?

A maioria das equipes tem exatamente uma jogada aqui: marcar como «não reproduzível» e fechar. Essa jogada custa caro duas vezes, sem ninguém perceber. O bug continua em produção, onde os próximos usuários vão encontrá-lo. E quem reportou aprende que reportar bugs não adianta nada, então o próximo relatório, aquele com o detalhe que teria resolvido este, nunca chega.

Diagnosticar por que um bug se reproduz para o usuário e não para você é uma disciplina à parte: a diferença está sempre em algum lugar entre estado, timing, ambiente ou dados. Este post trata da outra metade do trabalho: o fluxo. O que você faz com o ticket, hoje, quando a reprodução falhou.

Troque «fechado» por uma decisão de verdade

Um relatório que não se reproduz tem três desfechos honestos, e «fechado» não é um deles:

Corrigido mesmo assim: as evidências apontaram para uma causa que você conseguiu corrigir sem nunca ver o bug ao vivo.
Estacionado com instrumentação: você não conseguiu desvendar o bug, então armou uma armadilha para a próxima ocorrência e seguiu em frente.
Em observação: o relatório é um ponto de dados; você está esperando de propósito pelo segundo.

Cada passo abaixo leva a um desses três. O objetivo da triagem não é reproduzir, e sim levar o ticket a uma decisão que você consiga defender.

Passo 1: esprema o relatório que você tem

Antes de abrir um navegador, extraia tudo o que o relatório de fato contém:

Cruze o horário. Compare o horário do relatório com os logs do servidor e o histórico de deploys. «Quebrou às 14:02» ao lado de «fizemos deploy às 13:58» já resolveu mais mistérios do que qualquer debugger.
Procure relatórios parecidos. Mesma página, mesmo texto de erro, mesmo endpoint, no seu bug tracker e no seu monitoramento de erros. Um relatório que parece único muitas vezes é o terceiro do tipo, com três títulos diferentes.
Leia o sintoma de trás para a frente. Se o botão «não fez nada», liste o que poderia engolir um clique: um estado desabilitado, um return antecipado, uma rejeição não tratada. Cada hipótese implica uma condição em que o usuário poderia estar. Você ainda não está reproduzindo: está montando uma lista curta.

Passo 2: reserve uma hora, e só uma, para reproduzir como o usuário

As tentativas de reprodução falham porque os desenvolvedores reproduzem como eles mesmos: sessão nova, rede rápida, conta de admin, tela grande. Passe uma hora, e só uma, sendo de propósito quem reportou. O navegador e o tipo de dispositivo dele, o viewport dele, uma conexão limitada, uma conta com o papel e o volume de dados dele, a sequência de ações dele em vez da sensata.

Se a hora não render nada, pare. É em caçadas de reprodução sem limite que um bug médio devora uma sprint. O passo a passo continua de qualquer jeito.

Passo 3: faça uma pergunta a quem reportou, não cinco

Um questionário é abandonado; uma pergunta específica é respondida. Escolha aquela cuja resposta divide a sua lista curta ao meio («ainda acontece depois de recarregar a página?», «acontece sempre no mesmo registro?») e mande só ela.

Mais uma regra: peça fatos, nunca trabalho. «Qual navegador?» é um fato que os usuários não sabem informar com segurança e que uma ferramenta captura automaticamente; perguntar isso gasta a boa vontade de quem reportou com algo que uma tag de script deveria ter feito.

Passo 4: estacione do jeito certo

Estacionar não é fechar. Um ticket bem estacionado tem três coisas:

As evidências anexadas: tudo do passo 1, mais as hipóteses que você descartou, para que ninguém repita a mesma hora no mês que vem.
Uma armadilha armada: acrescente a linha de log, o breadcrumb, a asserção que vai disparar quando acontecer de novo. Se a sua ferramenta de relatórios captura a saída do console, um console.error bem colocado no caminho suspeito transforma o próximo relatório no diagnóstico.
Um gatilho de recorrência: o ticket reabre quando chega um relatório parecido, em vez de depender de alguém lembrar que ele existe.

Passo 5: trate o segundo relatório como a virada do caso

Bugs que não se reproduzem voltam: é a única coisa confiável neles. E o segundo relatório muda o jogo: um relatório é uma anedota, dois são uma comparação, cinco são um conjunto de dados. Pergunte o que as ocorrências têm em comum (navegador? papel? um registro específico? hora do dia?) e o que não têm. As variáveis em comum são a sua causa; o resto é ruído.

Por isso relatórios duplicados devem se acumular numa única tarefa, em vez de serem fechados como duplicados: justamente nessa classe de bug, a pilha é a análise. É também um ponto em que um assistente de IA ajuda de verdade: conectado aos seus relatórios pelo servidor MCP do BugDump, o Claude Code ou o Cursor percorre todos os relatórios de uma tarefa e encontra o fio em comum mais rápido do que uma pessoa assistindo a cinco replays de sessão.

Mantenha quem reportou informado

Duas frases, em dois momentos: quando você estaciona o ticket («ainda não conseguimos identificar a causa; adicionamos monitoramento e deixamos o seu relatório aberto») e quando corrige o bug («o seu relatório de março resolveu o caso, obrigado»). A primeira preserva a relação; a segunda é o investimento mais barato que existe numa cultura de relatórios. Quem vê que seus relatórios importam passa a enviar relatórios melhores.

Conserte o pipeline, não só o bug

Tudo o que este passo a passo contorna (o ambiente que falta, a sequência que falta, os erros que faltam) existia no navegador de quem reportou no momento da falha. Só não foi capturado. Essa é a correção duradoura: quando um relatório é enviado pelo BugDump, ele chega com o buffer do console (erros sinalizados), as requisições de rede recentes (falhas destacadas), navegador, SO, dispositivo, viewport, URL da página e um replay de sessão navegável do que o usuário fez de fato. Acrescente uma chamada identify e você sabe qual conta inspecionar, em vez de adivinhar uma parecida.

Com esse pipeline funcionando, boa parte deste passo a passo deixa de ser necessária: o passo 1 já vem feito, o passo 2 começa de fatos, a pergunta do passo 3 em geral já está respondida. O «não reproduzível» não desaparece por completo, mas deixa de ser um desfecho e vira o que deveria ter sido desde o início: um estado raro e temporário entre um relatório e uma correção.