O que Fazer com um Relatório de Bug que Você Não Pode Agir

A maioria dos conselhos sobre relatórios de bugs é dirigida à pessoa que os escreve. Este artigo é sobre o outro lado da questão: um relatório chegou, está quase certamente descrevendo algo real, e não há informações suficientes nele para fazer qualquer coisa.

Você tem três opções honestas, e a que a maioria das equipes escolhe é a pior delas.

As três opções

Feche-o. Rápido e ocasionalmente certo. É certo quando o relatório é um duplicado, quando descreve um comportamento intencional ou quando é tão vago que nenhuma pergunta que você pudesse fazer mudaria isso.

Peça mais. A padrão e a que custa silenciosamente mais. Cada pergunta é uma volta medida em dias, e cada uma gasta um pouco da disposição do relator em contar-lhe algo na próxima vez.

Responda por conta própria. Vá e encontre as informações que faltam sem envolver o relator: em logs, em rastreamento de erros, em qualquer coisa que você possa reproduzir do fragmento que recebeu. Mais lento para você hoje. Geralmente a única que termina.

A razão pela qual a opção do meio é tratada como gratuita é que seu custo é pago por outra pessoa, depois, e nunca aparece ao lado do ticket.

Antes de perguntar, descubra o que a resposta mudaria

Esta é toda a disciplina, e leva trinta segundos.

Para cada pergunta que está prestes a fazer, complete a frase: “se eles disserem X, eu…”. Se não conseguir completá-la, a pergunta é decoração e você está fazendo porque o formulário tem um campo.

Fraco

"Você pode nos dizer seu navegador, SO, tamanho de tela, o que você estava fazendo e se acontece o tempo todo?"

Melhor

"Ainda acontece em uma janela privada? Se sim, vou ver o servidor; se não, é uma compilação em cache e vou enviar uma correção de invalidação de cache hoje."

A segunda pergunta um único bit e ambas as respostas levam a algo. A primeira é um formulário, e um formulário é respondido quando alguém tem tempo, que não é hoje.

Faça uma pergunta, não cinco. Cinco perguntas em uma mensagem retornam confiavelmente duas respostas, e você não consegue dizer quais três foram ignoradas porque eram pouco claras, irrelevantes ou simplesmente a quarta coisa em um parágrafo longo.

O que fazer enquanto espera, que é a maior parte do trabalho

O relatório é um fragmento, mas raramente é nada. Geralmente há mais nele do que parece.

Um carimbo de data/hora é uma chave para tudo o que você já coleta. Mesmo “ontem à tarde” reduz seus logs para algumas horas, e se a pessoa é nomeada em seu sistema você pode encontrar suas solicitações dentro dessa janela. Na metade das vezes, a solicitação com falha está lá com seu código de status, e você nunca precisou perguntar nada.

Uma captura de tela carrega mais do que a captura de tela. A URL está na barra de endereços, o tamanho da janela é implícito pelo layout, e o chrome do navegador geralmente revela o navegador e o sistema operacional. As pessoas enviam uma pensando que lhe enviaram uma foto de um botão quebrado.

A redação diz em qual superfície eles estavam. “O app”, “o site” e “a página” não são sinônimos na maioria dos produtos, e alguém dizendo “me desconectou” disse que a falha tinha uma sessão nela.

“Funcionava na semana passada” é uma bisecção. Se for verdade, qualquer coisa que mudou está em uma janela conhecida, e seu histórico de implementação é uma lista de suspeitos ordenados por tempo.

Se você exaurir tudo isso e ainda estiver preso, você ganhou o direito de fazer uma pergunta, e agora sabe exatamente qual.

Fechando uma sem mentir sobre isso

Às vezes a resposta realmente é não. Há uma maneira de fazer isso que mantém o relator e uma forma que o perde.

A versão que o perde é “não consegue reproduzir”, sem mais nada. Parece “Não acredito em você”, porque de onde eles estão sentados é o que diz: viram acontecer.

A versão que o mantém diz o que você fez, o que encontrou e o que mudaria a resposta. “Verifiquei os logs de terça à tarde e não encontrei solicitações com falha para sua conta, e funciona em Chrome 141 e Safari aqui. Reabrir isso no momento em que acontece novamente é genuinamente útil, e o texto do console do navegador resolveria.” Essa é a mesma decisão, e deixa alguém disposto a contar a você na próxima vez.

Isso importa mais do que qualquer ticket individual, porque as pessoas que relatam bugs para você são um grupo pequeno e totalmente voluntário, e cada relatório não respondido ou fechado de forma desdenhosa remove um deles. Um rastreador silencioso não é a mesma coisa que um produto funcionando, e no momento em que você não consegue diferenciar os dois, é muito tarde para perguntar.

O que tirar disso

Um relatório impossível de agir é um fragmento, não uma falha, e o trabalho é decidir se a peça que falta custa menos encontrar do que solicitar.

Faça uma pergunta com uma consequência, ou nenhuma. Explore o fragmento primeiro, porque o carimbo de data/hora e a captura de tela geralmente carregam mais do que a frase. E quando você fechar uma sem resolver, feche-a de uma forma que torna o próximo relatório mais provável, não menos, já que a oferta de pessoas dispostas a escrever é o que você está realmente gerenciando.