Todo software tem bugs. Isso não é descuido — é parte de construir algo que muita gente usa, de jeitos que ninguém previu. O que separa um problema resolvido hoje de um problema que fica uma semana em ping-pong não costuma ser a gravidade do erro. É a qualidade do relato.
Quando o chamado chega como "não está funcionando, corrige urgente", quem desenvolve gasta o primeiro dia só descobrindo o que você quis dizer. Cada pergunta de volta — "onde?", "o que apareceu?", "consegue mandar um print?" — é mais um dia com o problema no ar. Um bom report entrega essas respostas de antemão. Ele não é formalidade: é o atalho até a solução.
E a boa notícia é que você não precisa saber programar para escrever um. Precisa só contar a história certa, na ordem certa. Este é o roteiro.
1. Um título que já diz o problema
O título é a primeira coisa que quem desenvolve lê — e, numa lista de dez chamados, às vezes a única. Ele precisa dizer onde e o quê, curto e específico. Um bom título também evita duplicados: fica fácil perceber que aquele problema já foi relatado antes.
Ruim: "Não consigo ver o paciente quando cadastro, clico e não vai. Corrigir urgente!"
Esse título é vago, emocional e não localiza nada. Compare:
Bom: "Cadastro de pacientes — pacientes novos não aparecem na lista"
O segundo já entrega a área do sistema e o comportamento errado. Dá para decidir a urgência e saber por onde começar só de bater o olho.
2. Um resumo com quando e onde
Se o título não conta a história toda, acrescente um resumo curto. A regra é: o mínimo de palavras, incluindo quando e onde aconteceu. Pense que esse texto pode ser buscado depois — use as palavras que você mesmo usaria para procurá-lo.
Ruim: "De manhã eu tentei trocar minha foto mas não consegui clicar."
Bom: "Terça de manhã, ao atualizar o perfil, tentei trocar a foto e o botão 'Trocar foto' não apareceu."
E descreva o problema, não o remédio. "O formulário está feio e esticado" ajuda menos do que "o formulário não está respeitando a fonte padrão e os campos poderiam ficar lado a lado em vez de empilhados". O primeiro é uma reclamação; o segundo é uma informação com a qual dá para trabalhar.
3. Uma imagem vale mil chamados
Um print vale mais que três parágrafos. Um vídeo curto vale mais que o print. Eles mostram de uma vez o que aconteceu, em que tela, com quais dados — coisas que a gente sempre esquece de escrever. Se dá para gravar a tela reproduzindo o erro, grave. É o tipo de esforço de dez segundos que economiza horas do outro lado.
4. O que você esperava vs. o que aconteceu
Este é o coração do report. Diga, em duas linhas, o que deveria ter acontecido e o que de fato aconteceu. Essa diferença é o bug.
Resultado esperado: ao clicar em "Trocar foto", abrir a janela para escolher a imagem.
Resultado atual: o botão "Trocar foto" nem aparece.
Sem essa comparação, quem desenvolve precisa adivinhar qual era a sua expectativa — e às vezes o "erro" é só uma tela funcionando diferente do que você imaginava.
5. O passo a passo para reproduzir
Essa é a parte mais valiosa e a mais esquecida. Assuma que quem vai consertar não faz ideia de como chegar no erro. Como você chegou lá?
- Entrar em "Meu perfil"
- Clicar em "Trocar foto"
- Passar o mouse sobre a foto atual
- Clicar para trocar
Use uma lista numerada. E, se você testou algumas vezes, diga com que frequência o erro aparece — "acontece toda vez" é uma informação diferente de "aconteceu uma vez só".
Se você mesmo não consegue reproduzir o erro de novo, quem desenvolve dificilmente vai conseguir. Tente refazer o caminho antes de abrir o chamado.
Bug que se reproduz sempre é bem mais fácil de caçar do que bug que aparece de vez em quando.
6. O ambiente onde aconteceu
O mesmo sistema pode se comportar de formas diferentes dependendo de onde é usado. Alguns detalhes fazem muita diferença:
- Navegador (Chrome, Safari, Firefox…) e, se souber, a versão.
- Aparelho e sistema — celular ou computador, Android, iPhone, Windows.
- Tamanho da tela — vários bugs só aparecem no celular ou só na tela grande.
Você não precisa virar especialista. Só diga de onde estava acessando quando o problema apareceu.
7. A URL e, se der, os logs do console
A URL é simples e quase sempre esquecida. O endereço da página (aquele https://... lá
em cima) diz exatamente em que ponto do sistema você estava. Copie e cole.
Os logs do console são um bônus técnico. Muitos erros deixam um rastro escondido que
aparece ao apertar F12 (ou Ctrl + Shift + I) no navegador, na aba "Console". Se você se
sentir à vontade para tirar um print dessa tela, ótimo — pode conter a resposta exata. Se não,
tudo bem: os itens anteriores já resolvem a maioria dos casos.
8. Diga o quanto dói
Ajude a definir a prioridade. Nem todo bug é urgente, e tratar tudo como emergência faz o que é realmente crítico se perder no meio. Vale separar duas coisas:
- Gravidade — o quanto atrapalha. Impede de trabalhar? Trava uma venda? Ou é um detalhe visual que incomoda mas dá para conviver?
- Urgência — o quão rápido precisa ser resolvido para o seu negócio.
"O botão de finalizar pedido não funciona, ninguém consegue comprar" e "a fonte do rodapé está um pouco grande" são os dois bugs — mas não disputam a mesma fila.
9. Cinco hábitos que fazem a diferença
- Um bug, um chamado. Não junte três problemas num relato só; cada um vira difícil de acompanhar e de fechar.
- Procure antes de abrir. Talvez o problema já tenha sido relatado — evita trabalho repetido dos dois lados.
- Reproduza antes de relatar. Se você mesmo não consegue refazer o erro, quem desenvolve dificilmente vai conseguir.
- Foque no problema técnico. Deixe ideias e sugestões de melhoria para outro momento; no chamado, o que importa é o que quebrou.
- Registre num lugar só. Um canal combinado — e-mail, uma ferramenta, uma planilha — vale mais do que mensagens espalhadas em três aplicativos.
O report é uma conversa
No fim, reportar bug bem é uma forma de colaboração. Bugs acontecem; o que decide a rapidez da solução é quão claro chega a informação. Um relato caprichado poupa idas e vindas, respeita o tempo de quem desenvolve e devolve o problema resolvido mais cedo para você.
Na ChavesTech, esse ping-pong quase não existe: como você fala direto com quem desenvolve, um print no lugar certo e duas frases bem colocadas já colocam a correção em andamento. Não há uma camada de suporte traduzindo o seu problema para outra pessoa — a sua descrição chega inteira em quem vai resolver. E é assim que bug deixa de ser dor de cabeça e volta a ser o que sempre foi: parte normal de manter um software vivo.