Como reportar um bug que o desenvolvedor vai querer corrigir

A resposta curta: um bom reporte de defeito é corrigido rápido porque o desenvolvedor consegue reproduzi-lo na própria máquina sem adivinhar nada. Para isso ele precisa de três coisas: os passos exatos para provocar a falha, o que você esperava que acontecesse, e o que aconteceu de verdade. Se o seu reporte tem essas três, já vale mais que 80% dos que chegam a um quadro. Se ainda incluir ambiente, evidência e uma severidade honesta, você acabou de poupar meia hora de idas e vindas para alguém.

Existe um custo escondido no "não funciona, conserta". O desenvolvedor lê isso, não consegue reproduzir, e devolve a bola: "em qual navegador?", "qual usuário?", "me manda um print?". Essa conversa pode durar dois dias por um bug que se resolvia em vinte minutos. O reporte não é burocracia: é o artefato que decide se o defeito fecha hoje ou fica quicando por uma semana.

01 · o mínimo inegociávelOs três dados sem os quais não há reporte

Um reporte de defeito que não pode ser reproduzido é uma anedota, não um defeito. Por isso o padrão internacional de testes, a ISO/IEC/IEEE 29119, define o incident report com campos obrigatórios, e no centro estão sempre os mesmos três: passos para reproduzir, resultado esperado e resultado obtido. Esse trio é o coração do oráculo: sem o "esperado", ninguém sabe se o que você viu é um bug ou o comportamento correto que você não conhecia.

Os passos para reproduzir são escritos numerados, a partir de um estado conhecido, com dados concretos. Não "fiz login e falhou", mas "1. Entro em /login. 2. Uso o usuário demo@qirava.io. 3. Deixo a senha em branco. 4. Clico em Entrar". Qualquer pessoa com esses passos chega ao mesmo ponto. Esse é o teste de fogo: se você não consegue reproduzir duas vezes seguidas seguindo os seus próprios passos, ainda não tem um reporte, tem uma suspeita.

Sem "resultado esperado", ninguém consegue distinguir um defeito de uma função que você não entendeu.

O resultado esperado é o que mais se esquece e o que mais briga evita. Diga de onde vem a sua expectativa: a história de usuário, a especificação, uma regra de negócio, o bom senso documentado. "Esperava que rejeitasse o envio com uma mensagem de erro" é uma afirmação verificável. O resultado obtido é o que de fato aconteceu, tal como foi, sem interpretar: "a página ficou em branco e o console mostrou um erro 500".

02 · o contexto que poupa a ida e voltaAmbiente, evidência e um título que se entende num relance

O trio te dá um reporte válido. O contexto te dá um reporte que não quica de volta. Primeiro vem o ambiente: número de build ou versão, navegador e sistema operacional, tipo de usuário ou papel, e dados de teste usados. Metade dos "na minha máquina funciona" se resolve aqui, porque o bug morava numa versão, num navegador ou numa permissão que o desenvolvedor não estava olhando.

Depois vem a evidência. Um print com a área do erro marcada, um vídeo curto se a falha é de sequência, e sobretudo o log ou a mensagem de erro literal. Copie o texto do erro, não parafraseie: esse stack trace costuma apontar para a linha exata do código. Anexar o erro real pode ser a diferença entre uma correção de dez minutos e uma tarde de rastreio às cegas.

Copie a mensagem de erro literal. Esse texto costuma ser o mapa que leva à linha culpada.

Um detalhe que separa quem reporta bem: tente isolar antes de enviar. Acontece sempre ou de vez em quando? Com qualquer usuário ou só com um? Numa única tela ou em várias? Reduzir o bug às suas condições mínimas é, na prática, metade do trabalho de depuração já feito. O desenvolvedor agradece porque você entrega o problema delimitado, não o caos inteiro.

03 · severidade honesta e o tom que não queima pontesComo classificar sem inflar e sem culpar

A ISTQB distingue duas coisas que as pessoas misturam: severidade é o quanto o defeito prejudica o sistema; prioridade é o quão urgente é corrigi-lo. Não são a mesma coisa. Um erro de ortografia no logo da home é severidade baixa mas prioridade alta, porque todo mundo vê. Um cálculo errado num caso extremo que quase ninguém toca pode ser severidade alta e prioridade baixa. Separar as duas evita a guerra do "tudo é crítico".

E aí está a tentação: inflar. Se você marca tudo como bloqueante, em duas semanas ninguém acredita em você e os seus bloqueantes reais se perdem entre os falsos. A severidade honesta é um ativo de confiança. Reporte o impacto real, com dados: "afeta todos os usuários que pagam com cartão", não "é urgentíssimo". O dado convence; o adjetivo cansa.

Resta o tom, que é o que decide se o desenvolvedor quer te ajudar ou fica na defensiva. Um reporte de defeito descreve o comportamento do software, não a incompetência de uma pessoa. "O formulário salva o preço sem o imposto" abre uma conversa; "de novo você quebrou o checkout" a encerra. O defeito é contra o sistema, nunca contra quem o escreveu. Essa pequena troca de sujeito, do "você" para "o sistema", é o que mantém o time do mesmo lado da mesa.

Junte tudo e o reporte deixa de ser uma reclamação. Vira um pequeno experimento reproduzível: aqui estão os passos, isto eu esperava, isto obtive, neste ambiente, com esta evidência, e este é o dano real. Com isso na mão, o desenvolvedor não adivinha: reproduz, entende e corrige. E na próxima vez que você abrir um ticket, em vez de quicar de volta, ele fecha no mesmo dia. Essa é toda a diferença entre reportar um bug e só avisar que algo está errado.