O que é o registo de bugs? A diferença entre um registo e uma mensagem

Registar bugs é manter todos os defeitos conhecidos num só sítio, numa forma que sobreviva a que a pessoa que o encontrou vá de férias. É essa a ideia toda. O software em que as pessoas pensam quando dizem “bug tracker” é apenas o arquivo que torna isso possível.

A distinção que interessa é entre um registo e uma mensagem. Uma mensagem é o que se envia quando se repara em alguma coisa: uma linha de chat, um email, um comentário dito ao passar pela secretária de alguém. É dirigida a uma pessoa, é lida uma vez, e desaparece. Um registo não é dirigido a ninguém em particular e é lido sempre que alguém faz a pergunta certa. Registar bugs é a prática de transformar a primeira no segundo.

O que um sistema de registo tem de fazer

Quatro coisas. Tudo o resto é conveniência.

• Guardar uma entrada por problema, para que duas pessoas que encontram a mesma coisa se encontrem uma à outra em vez de reportarem duas vezes.
• Dizer em que ponto está cada uma - aberta, em curso, corrigida, verificada, fechada - de uma forma que seja verdadeira e não apenas desejada.
• Nomear um responsável, porque um defeito que pertence à equipa não pertence a ninguém.
• Continuar pesquisável mais tarde, que é aquilo que se salta na escolha e se lamenta ao quarto mês.

Uma folha de cálculo faz mal as três primeiras e a quarta não faz de todo. Um canal de chat não faz nenhuma, o que não é uma crítica ao chat: é um meio de mensagens a fazer exatamente aquilo para que serve.

O que vai numa entrada

Menos do que a maioria dos modelos pede e mais do que a maioria dos relatórios traz.

As partes que merecem o seu lugar são as de que outra pessoa precisa para agir: o que aconteceu, o que se esperava em vez disso, como voltar lá, e onde aconteceu - navegador, versão, conta, URL. O nosso guia para escrever um relatório de bug é a versão longa dessa lista, e traz um modelo que pode colar num formulário.

Tudo o resto num formulário típico são metadados do processo e não do problema: gravidade, prioridade, componente, marco, a pessoa responsável. Úteis, mas pertencem a quem trata da gestão de defeitos, não a quem reparou que o botão estava avariado. Pedi-los a quem reporta, no momento em que reporta, é a maneira mais comum de tornar o reportar caro ao ponto de as pessoas deixarem de o fazer.

Três maneiras de falhar

Quase todos os sistemas de registo que deixam de merecer confiança lá chegaram por uma de três vias.

O cemitério. Nunca se fecha nada, por isso a contagem só cresce, por isso ninguém lê a lista, por isso chegam defeitos reais e nunca são vistos. Um atraso de oitocentas entradas que ninguém abriu este ano não é o registo de coisa nenhuma; é um sítio para onde as coisas vão.

Estados que mentem. Todas as entradas dizem “aberta” porque movê-las é o trabalho de alguém e ninguém o tem. A essa altura o campo de estado é decoração e a única forma de saber em que ponto está seja o que for é perguntar a uma pessoa, que era justamente o que o sistema devia substituir.

A pilha de duplicados. O mesmo defeito reportado seis vezes porque procurar custa mais do que escrever. Costuma culpar-se disto quem reporta e costuma ser um problema de pesquisa: se procurar pelas palavras que uma pessoa normal usaria não encontra a entrada que já existe, o sistema ensinou-a a reportar outra vez.

De onde vêm as entradas conta mais do que qual a ferramenta que as guarda

As equipas passam muito tempo a escolher entre sistemas de registo e quase nenhum no passo anterior, que é como um defeito chega da pessoa que o viu até dentro do sistema.

É nesse percurso que os relatórios morrem. Alguém repara num problema e, entre reparar e ter escrito uma entrada útil, há um vazio: que navegador era, o que dizia a consola, qual era o URL, em que cliquei primeiro. A maioria das pessoas, na maioria das vezes, escreve duas frases e segue em frente, porque a alternativa são quinze minutos de investigação por um bug que não é seu.

Tudo o que encurta esse vazio eleva a qualidade de tudo o que vem a seguir. Um formulário na página onde o bug aconteceu ganha a um link para o sistema de registo. Uma captura que recolhe sozinha a metade técnica ganha a pedir a um agente de apoio que abra as ferramentas de programador. Capturar o relatório onde está o bug é o mesmo problema visto da outra ponta.

Escolher um

O conselho honesto é que a escolha conta menos do que o hábito. Jira, Linear, GitHub Issues, Bugzilla, Trello com uma coluna chamada Bugs: as quatro coisas acima são possíveis em qualquer um deles, e nenhum as fará por si.

Vale a pena fazer duas perguntas a um candidato, e não são as das páginas de comparação:

Pergunta fraca

Qual tem mais integrações e os melhores painéis de relatórios?

Pergunta melhor

Alguém que não esteja na equipa de engenharia consegue reportar lá sem ajuda, e alguém consegue encontrar uma entrada de há dois anos a partir das palavras de que se lembra?

Se reportar exigir uma conta, um projeto, um componente e um tipo de entrada, as pessoas mais próximas dos seus clientes - apoio, vendas, QA, o próprio cliente - não vão reportar. Os bugs delas chegarão como mensagens, e a diferença entre um registo e uma mensagem era exatamente o que estava a tentar comprar.

Registo, testes e o resto

Registar bugs fica a jusante de tudo o que encontra bugs, e é por isso que acaba por recolher o vocabulário de tudo. Um plano de testes diz como os defeitos são reportados e quem decide se um deles trava um lançamento. Os testes de regressão existem porque um sistema cheio de entradas fechadas é uma lista de coisas que dantes funcionavam. Os testes instáveis são o que acontece quando aquilo que está a ser registado não consegue decidir se é um defeito.

Um sistema de registo não melhora o software. Impede que a mesma tarde seja gasta duas vezes.