Como reportar um bug que o time consegue resolver

O que é um bom reporte de bug

Um reporte de bug é o registro de um problema: algo que deveria funcionar de um jeito e está funcionando de outro. Um bom reporte de bug é aquele que permite a quem vai corrigir reproduzir o problema sem falar com quem reportou. Essa é a régua. Se a pessoa que pegou o item precisa mandar mensagem perguntando "em qual tela isso aconteceu?" ou "o que você esperava que acontecesse?", o reporte falhou — e o custo dessa falha é alto, porque cada ida e volta adia a correção em horas ou dias.

Na prática, um bom reporte tem cinco elementos: um título específico, os passos para reproduzir, o contraste entre o que acontece hoje e o que deveria acontecer, uma evidência (print, vídeo, arquivo) e uma severidade honesta. Nada disso exige conhecimento técnico. Uma analista de marketing que percebeu que o disparo de e-mail saiu com o nome errado consegue escrever um reporte impecável seguindo essa estrutura — e um desenvolvedor sênior consegue escrever um reporte péssimo ignorando ela.

Vale dizer desde já: bug não é sinônimo de "coisa de TI". Um formulário de admissão do RH que aceita CPF em branco, uma planilha de comissões que arredonda errado, um post agendado que publica no horário errado — tudo isso é bug: um comportamento combinado que está sendo violado. Times de qualquer área que trabalham com sprints se beneficiam de tratar esses problemas com o mesmo rigor que um time de engenharia trata os seus.

A anatomia do reporte: cinco partes, nenhuma opcional

1. Título específico

O título é o que aparece no board, na busca e na conversa da daily. "Erro no relatório" não diz nada; daqui a duas semanas ninguém saberá do que se trata. Um bom título responde o quê + onde + quando: "Relatório de vendas exporta valores zerados quando o filtro de região está ativo". Quem lê já sabe o que esperar antes de abrir o item.

Um teste simples: se o seu título servir para três bugs diferentes, ele é vago demais. "Problema no cadastro" serve para dezenas de situações; "Cadastro de fornecedor aceita CNPJ com 13 dígitos" serve para uma só.

2. Passos para reproduzir

Aqui mora a diferença entre um bug que se resolve em uma tarde e um que apodrece no backlog. Escreva os passos numerados, partindo de um ponto que qualquer pessoa do time consegue alcançar:

1. Acesse o painel de campanhas com um usuário do time de mídia.
2. Crie uma campanha com data de início no último dia do mês.
3. Salve e abra a campanha novamente.
4. Observe o campo "data de início": ele exibe o primeiro dia do mês seguinte.

Repare nos detalhes que fazem diferença: com qual usuário (permissões mudam comportamento), com quais dados (o bug só aparece no último dia do mês) e onde olhar (o campo específico). Se o problema depende de ambiente — navegador, celular, versão da planilha — inclua isso também. Antes de enviar, faça o teste de fogo: siga seus próprios passos do zero. Se o bug não aparecer, você ainda não descobriu a condição que o dispara, e o reporte vai gerar um "não consegui reproduzir" frustrante para os dois lados.

3. O que acontece hoje × o que deveria acontecer

Essas são duas frases separadas, e a segunda é a mais esquecida. "O sistema mostra a data errada" descreve o sintoma; "deveria exibir exatamente a data que salvei" descreve o combinado violado. Sem o comportamento esperado, quem corrige precisa adivinhar a intenção — e às vezes adivinha errado, corrigindo para um comportamento que também não era o desejado.

Se o time escreve critérios de aceite nas User Stories, o comportamento esperado geralmente já existe por escrito: cite-o. "O critério de aceite da história de agendamento diz que o post publica no fuso do cliente; hoje publica no fuso de Brasília" é um reporte que praticamente se resolve sozinho.

4. Evidência

Um print vale dez linhas de descrição. Um vídeo curto de tela vale cinquenta. Anexe o que provar o problema: captura da tela com o erro visível, o arquivo exportado com os valores zerados, o e-mail que chegou com o nome errado. Marque na imagem onde olhar — uma seta ou um retângulo vermelho poupa a pessoa de caçar o problema num print inteiro. Se houver mensagem de erro, copie o texto dela além do print: texto é pesquisável, imagem não.

5. Severidade honesta

Severidade é a medida do impacto real, não da irritação de quem encontrou. Uma escala simples que funciona para qualquer área:

• Crítica — bloqueia o trabalho de todos e não há caminho alternativo. Ex.: ninguém consegue fechar a folha de pagamento.
• Alta — afeta muita gente ou um fluxo importante, mas existe contorno trabalhoso. Ex.: o relatório oficial falha, mas dá para montar na mão.
• Média — afeta poucas pessoas e o contorno é simples. Ex.: um filtro não funciona, mas a busca resolve.
• Baixa — detalhe visual, texto, alinhamento. Incomoda, não impede.

"Honesta" é a palavra-chave. Quando tudo é marcado como crítico, nada é crítico — o time para de confiar na etiqueta e volta a decidir no grito. O contrário também vale: minimizar um bug que bloqueia o cliente para "não incomodar" só transfere o custo para mais tarde, com juros.

Bug é um tipo de item de trabalho — trate como tal

Um erro comum é deixar bugs vivendo em mensagens de WhatsApp, e-mails e conversas de corredor, enquanto as User Stories moram organizadas no board. O resultado é previsível: o que não está no board não é priorizado, não é estimado e não é lembrado.

O bug merece o mesmo tratamento da história: entra na hierarquia Feature → User Story → Task como um item irmão da User Story, ligado à feature que ele afeta. A diferença está no conteúdo: enquanto a história descreve algo novo a construir, o bug descreve algo existente a consertar — e por isso os passos para reproduzir fazem o papel que os critérios de aceite fazem na história. No TeamBOX, o tipo Bug existe exatamente com esse formato: o item pede os passos para validar a correção e aceita anexos para os prints e arquivos de evidência, de modo que quem corrige e quem valida trabalham sobre o mesmo registro, sem depender de memória.

Os passos para validar, aliás, são o fechamento do ciclo: o mesmo roteiro que reproduz o problema serve para confirmar que ele sumiu. Corrigiu? Alguém — de preferência quem reportou — refaz os passos e confirma que o comportamento agora é o esperado. Bug sem validação é bug que volta.

De reporte ruim a reporte bom: três reescritas

Time de marketing

Ruim: "O e-mail tá saindo errado, alguém olha?"

Bom: "Disparo de boas-vindas envia '{nome}' literal no lugar do nome do lead. Passos: 1) cadastre um lead de teste pelo formulário do site; 2) aguarde o e-mail automático de boas-vindas; 3) observe a saudação. Hoje: 'Olá, {nome}!'. Esperado: 'Olá, Mariana!' (nome do cadastro). Evidência: print do e-mail recebido em anexo. Severidade: alta — afeta todos os leads novos e queima a primeira impressão; contorno não existe porque o envio é automático."

Time de RH

Ruim: "O formulário de admissão está com problema no CPF."

Bom: "Formulário de admissão aceita envio com o campo CPF em branco. Passos: 1) abra o formulário de admissão como candidato; 2) preencha tudo, menos o CPF; 3) clique em enviar. Hoje: o envio conclui e o registro chega ao RH sem CPF, travando a etapa de contrato. Esperado: o formulário deve bloquear o envio e sinalizar o campo obrigatório. Evidência: print do registro sem CPF na base. Severidade: alta — cada ocorrência gera retrabalho de contato com o candidato."

Time de produto/engenharia

Ruim: "App quebra às vezes no checkout 😡"

Bom: "Checkout falha com cartão salvo quando o carrinho tem item de assinatura + item avulso. Passos: 1) logue com uma conta que tenha cartão salvo; 2) adicione uma assinatura mensal e um produto avulso; 3) finalize com o cartão salvo. Hoje: tela de erro genérico e pedido não criado (100% reproduzível nesse cenário; só com itens avulsos, funciona). Esperado: pedido criado com os dois itens. Evidência: vídeo da tela + texto do erro. Severidade: crítica — perda direta de venda, sem contorno para o cliente."

Repare no padrão das reescritas: nenhuma exige saber programar. Exigem apenas observação e o cuidado de responder às cinco perguntas antes que alguém precise fazê-las.

Onde o bug entra no fluxo da sprint

Reportar bem é metade do caminho; a outra metade é decidir quando corrigir. Três destinos possíveis:

• Agora, interrompendo a sprint — reservado aos críticos. O time combina de antemão o que justifica interrupção, para a decisão não virar queda de braço a cada ocorrência.
• Na próxima sprint — bugs altos e médios entram no planejamento como qualquer item, disputando espaço com as histórias. Se o time mede a saúde da sprint por métricas, vale observar a proporção de esforço indo para correções: quando ela cresce sprint após sprint, é sinal de dívida de qualidade se acumulando.
• No backlog, com registro — os baixos. Não é vergonha um bug baixo esperar; vergonha é ele esperar sem estar registrado, sendo redescoberto (e re-reportado) a cada dois meses.

Uma prática que ajuda: ao trazer um bug para a sprint, tratá-lo no board com o mesmo fluxo dos demais itens — inclusive passando por uma coluna de teste antes de concluir, onde os passos para validar são executados de verdade. Times que pulam essa etapa reabrem bugs com frequência, e bug reaberto custa o dobro: a correção, mais a confiança.

Erros comuns ao reportar bugs

• Título genérico ("erro no sistema", "problema no relatório") — impossível de buscar, priorizar ou lembrar.
• Diagnóstico no lugar de descrição — "o bug é no cache" pode até estar certo, mas descreva o comportamento observado; a causa é hipótese de quem investiga.
• Vários bugs num reporte só — cada problema ganha seu item. Três bugs num registro viram um item que nunca fecha, porque sempre falta um.
• Reportar sem tentar reproduzir — "aconteceu uma vez, semana passada" tem valor, mas diga isso explicitamente ("intermitente, não consegui reproduzir") em vez de deixar o time descobrir sozinho.
• Severidade inflada para furar fila — funciona uma vez e destrói a credibilidade da escala para sempre.
• Esquecer o comportamento esperado — o time corrige o sintoma e descobre na validação que o "certo" era outra coisa.
• Evidência solta sem contexto — um print avulso no chat não é reporte; anexe a evidência ao item, junto dos passos.
• Não fechar o ciclo — corrigiu, mas ninguém refez os passos para validar. O bug que "voltou" quase sempre é o bug que nunca foi validado.

Guarde a régua de ouro: se quem corrige consegue reproduzir o problema e validar a correção sem falar com você, o reporte está pronto. Tudo neste artigo é só o caminho para passar nesse teste.