Bug tracking (perseguir/acompanhar bugs) é um tópico extenso; muitos de seus aspectos são discutidos neste livro. Aqui, concentrarei-me principalmente na parte de setup e considerações técnicas, mas para chegarmos nelas devemos começar com a seguinte pergunta: exatamente que tipo de informação devemos manter em um bug tracker?
O termo bug tracker pode enganar. Sistemas de Bug tracking também são frequentemente usados para acompanhamento de pedidos de novas funcionalidades, tarefas casuais, patches não solicitados—realmente qualquer coisa que tenha estados distintos de início e fim, com transações de estados entre estes dois pontos, e que acumule informação durante seu tempo de vida. Por esta razão, bug trackers também são chamados de issue trackers(rastreadores de problemas), defect trackers (rastreadores de defeitos), artifact trackers (rastreadores de produção), request trackers (rastreadores de pedidos), trouble ticket systems (sistemas de bilhetes de problemas), etc. Veja Apêndice B, Free Bug Trackers para uma lista de softwares.
Neste livro, continuarei a usar o termo "bug tracker" como referência ao software que faz o acompanhamento, já que este é o principal termo que as pessoas usam, mas usarei issue para me referir a um único item no banco de dados do bug tracker. Isto nos permite identificar a diferença entre o comportamento ou mau comportamento que o usuário encontrou (ou seja, o bug propriamente dito), e o registro do tracker em relação à descoberta, diagnóstico e eventual solução do bug. Tenha em mente que apesar da grande maioria de issues sejam referidas à bugs propriamente ditos, issues também podem ser usadas para acompanhar outros tipos de tarefas também.
O ciclo de vida clássico de uma issue é parecido com isso:
Alguém abre a issue. É provido um sumário, uma descrição inicial (incluindo informações de reprodução do bug, caso seja adequado; veja “Treat Every User as a Potential Volunteer” em Capítulo 8, Managing Volunteers para ler sobre como encorajar bons relatórios de bug) e qualquer outra informação que o tracker pedir. A pessoa que abriu a issue pode ser completamente desconhecida ao projeto—relatos de bug e pedidos de funcionalidades podem vir tanto da comunidade de usuários quanto da de desenvolvedores.
Assim que preenchida, a issue está no que é chamado de estado aberto (open state). Como nenhuma ação foi tomada ainda, alguns trackers também a identificam como não verificada (unverified) e/ou não iniciado (unstarted). Ela ainda não é atribuída a ninguém; ou, em alguns sistemas, ela é atribuída a um usuário falso que representa a falta de real atribuição. Neste ponto, a issue está em uma área de espera: ela foi registrada, mas ainda não foi integrada à consciência do projeto.
Outras pessoas leem a issue, adicionam comentários, e talvez façam alguma pergunta à pessoa que identificou o problema caso algo precise ser esclarecido.
O bug é reproduzido. Talvez este seja o momento mais importante do seu ciclo de vida. Apesar do bug ainda não ter sido corrigido, o fato de quem alguém, além do identificador original, conseguiu fazer com que o bug se repetisse é a prova de que se trata de um defeito autêntico, e, não menos importante, confirma a quem relatou o bug que foi feita uma contribuição ao projeto através do relato de um bug genuíno.
O bug então é diagnosticado: sua causa é definida, e, se possível, o esforço requirido para sua correção é estimado. Tenha certeza que estes dados sejam registrados na issue; se a pessoa que diagnosticou o bug precise se afastar do projeto por algum tempo (como acontece frequentemente com desenvolvedores voluntários), outra pessoa deve ser capaz de continuar daonde a outra parou.
Neste estágio, ou, às vezes, no anterior, um desenvolvedor pode "ficar dono" da issue e atribuí-la para si (“Distinguish clearly between inquiry and assignment” em Capítulo 8, Managing Volunteers explora o processo de designação mais detalhadamente). A prioridade da issue também pode ser determinada neste estágio. Por exemplo, se ela é tão grave que pode atrasar a próxima release, este fato deve ser identificado cedo, e o tracker deve ter algum modo de identificar isto.
A issue então é agendada para correção. Agendar não quer dizer, necessariamente, associar uma data para a correção. Às vezes, apenas significa decidir em qual release futura (não necessariamente a próxima) o bug deverá estar corrigido, ou decidir que ele não bloqueará alguma release em particular. Agendamento também pode ser dispensado caso o bug seja de rápida correção.
O bug então é fixado (ou a tarefa concluída, ou o patch executado, ou o que quer que seja). A mudança ou conjunto de mudanças que o corrigiram devem ser registradas em um comentário na issue, e então ela é fechada e/ou marcada como resolvida.
Existem algumas variações bem comuns neste ciclo de vida. Algumas vezes uma issue é fechada muito rapidamente após ser adicionada, pois verifica-se que, na verdade, não é um bug, mas sim um mal-entendido por parte do usuário. Conforme um projeto adquirem mais usuários, mais e mais essas issues inválidas irão aparecer, e os desenvolvedores fecharão-as com mensagens cada vez mais mal-humoradas. Tente se proteger contra esta tendência. Ela não faz nenhum bem, pois o usuário em questão não é responsável por todas as issues inválidas que já foram enviadas anteriormente; esta tendência estatística é visível apenas do ponto de vista do desenvolvedor, não do usuário. (Em “Pré-filtrando o Bug Tracker”, mais para frente neste capítulo, veremos algumas técnicas para reduzir o número de issues inválidas.) Também, se diferentes usuários estão experienciando o mesmo mal-entendido repetidamente, talvez isto signifique que o software precise ser replanejado. Este padrão é mais fácil de ser notado onde existe um gerente de issues monitorando o banco de dados de issues; veja “Issue Manager” em Capítulo 8, Managing Volunteers.
Outra variação comum no ciclo de vida é a issue ser fechada como duplicata logo após a abertura. Uma duplicata acontece quando alguém abre uma issue que já é conhecida no projeto. Duplicatas não estão confinadas à issues abertas: é possível que um bug volte a aparecer depois de ter sido corrigido (isto é conhecido como regressão), em cujo caso é preferível que se reabra a issue original e feche qualquer novos relatos como duplicatas da original. O sistema de rastreamento de bugs deve manter um rastro deste relacionamento bidirecionalmente, para que a reprodução da informação nas duplicatas esteja disponível na issue original e vice versa.
Uma terceira variação é que desenvolvedores fechem a issue, pensando tê-la corrigido, apenas para que o relator rejeite a correção e reabra a issue. Isto normalmente acontece por que o o desenvolvedor simplesmente não tem acesso ao ambiente necessário para reproduzir o bug, ou por que a issue não foi testada usando a mesma receita de reprodução usada pelo relator.
Além destas variações, podem existir outros pequenos detalhes do ciclo de vida que podem variar dependendo do software de rastreamento. Mas a forma básica é a mesma, e, apesar de o ciclo de vida em si não ser específico ao software de código aberto, ele tem implicações em como projetos abertos usam os seus bug trackers.
Como o primeiro passo indica, o tracker é uma superfície pública do projeto tanto quanto mailing lists ou páginas da web. Qualquer um pode relatar uma issue, qualquer um pode olhar uma issue, e qualquer um pode navegar pela lista de issues abertas. Você nunca sabe quantas pessoas estão esperando para ver o progresso de uma específica issue. Enquanto o tamanho e a habilidade da comunidade de desenvolvimento retém o ritmo com que issues podem ser corrigidas, o projeto pelo menos tenta reconhecê-las a partir do momento em que aparecem. Até se a issue for protelada por um tempo, a resposta encoraja o relator a se manter envolvido, por que ele sente que um humano registrou o que ele fez (lembre-se que preencher uma issue normalmente envolve mais esforço que, por exemplo, mandar um email). Além do mais, assim que uma issue é vista por um desenvolvedor, ela entra na consciência do projeto, no sentido de que este desenvolvedor pode estar observando por outras instâncias desta issue, pode conversar sobre ela com outros desenvolvedores, etc.
A necessidade de respostas a tempo implica duas coisas:
O tracker deve estar conectado com uma mailing list, para que cada mudança em uma issue, incluindo o seu preenchimento inicial, causa uma mensagem a ser enviada explicando o que aconteceu. Esta mailing list normalmente é diferente da lista de desenvolvimento, já que não são todos os desenvolvedores que desejam receber mensagens automadas de bugs, mas (assim como mensagens de commit) o cabeçalho "Responder a" deve ser definido para a lista de desenvolvimento.
O formulário para preencher issues deve conter o endereço de email do relator, para que ele seja contatado para mais informações. (No entanto, ele não deve demandar o endereço de email, já que algumas pessoas podem preferir reportar issues anonimamente. Veja “Anonymity and involvement” mais à frente neste capítulo para mais sobre a importância da anonimidade.)
Tome cuidado para que o bug tracker não se transforme em um fórum de discussões. Apesar da importância de se manter a presença humana no bug tracker, ele não é fundamentalmente adequado para discussões em tempo real. Ao invés disto, pense nele como um arquivo, um modo de organizar fatos e referências para outras discussões, principalmente aquelas que acontecem nas listas de e-mail.
Existem duas razões para que se faça esta distinção. Primeiro, o bug tracker é mais incômodo de se usar do que as listas de e-mail (ou que salas de bate-papo em tempo real, por exemplo). Isto não é por que bug trackers têm uma interface de usuário ruim, mas eles foram desenvolvidos para capturar e apresentar situações discretas, e não discussões de fluxo livre. Segundo, nem todo mundo envolvido na discussão pode estar acompanhando o bug tracker. Parte de um bom gerenciamento de issues (veja “Share Management Tasks as Well as Technical Tasks” em Capítulo 8, Managing Volunteers) é confirmar que cada issue seja trazida para a atenção das pessoas ao invés de fazer com cada desenvolvedor tenha que monitorar todas as issues. Em “No Conversations in the Bug Tracker” em Capítulo 6, Communications, nós veremos modos para que as pessoas não acidentalmente levem as discussões de seus lugares apropriados para o bug tracker.
Alguns bug trackers podem monitorar as listas de e-mail e automaticamente fazer log de todos os e-mails referentes a uma issue específica. Tipicamente eles fazem isso reconhecendo o número de identificação da issue na linha de assunto do e-mail, como parte de uma palavra especial; desenvolvedores aprender a incluir essas palavras nos seus e-mails para atrair a atenção do tracker. O bug tracker pode então salvar o e-mail inteiro, ou (melhor ainda) apenas guardar um link para o email no arquivo da lista de e-mail. De qualquer modo, esta é uma característica muito útil; se o seu tracker tem ela, tenha certeza de deixá-la ativa e lembrar as pessoas de tirarem proveito da mesma.
A maioria dos bancos de dados de bugs eventualmente sofrem do mesmo problema: um monte de issues duplicadas ou inválidas preenchidas por usuários bem intencionados, no entanto inexperientes ou mal informados. O primeiro passo para combater esta tendência é normalmente colocar um aviso proeminente na primeira página do bug tracker, explicando como identificar se um bug é realmente um bug, como procurar se ele já foi informado, e, finalmente, como reportá-lo eficientemente se depois disto ainda for considerado um novo bug.
Isto reduzirá a quantidade de "sujeira" por um tempo, mas conforme o número de usuários cresce, o problema eventualmente retornará. Ninguém pode, individualmente, ser apontado como culpado por isto. Todos estão apenas contribuir para o bem-estar do projeto, e até se o primeiro relatório de bug não foi útil, você ainda quer encorajá-los a continuarem envolvidos e preencher relatórios melhores no futuro. Enquanto isto, no entanto, o projeto precisa manter o banco de dados de issues o mais limpo possível.
Duas das coisas que ajudarão muito na prevenção deste problema são: ter certeza de que existem pessoas acompanhando o bug tracker que possuam conhecimento suficiente para fechar issues como inválidas ou duplicatas no momento em que elas entrarem, e requirindo (ou fortemente encorajando) que os usuários confirmem seus bugs com outras pessoas antes de preencherem-os no tracker.
A primeira ténica parace ser usada universalmente. Até em projetos com bancos de dados enormes (por exemplo, o bug tracker do projeto Debian em http://bugs.debian.org/, que detia 315,929 issues até o momento desta escrita) ainda é possível conciliar as coisas para que alguém veja cada issue que entrar. Talvez seja uma pessoa diferente dependendo da categoria da issue. Por exemplo, o projeto Debian é uma coleção de pacotes de software, então ele automaticamente encaminha cada issue para os mantenedores apropriados destes pacotes. Claro, usuários podem, às vezes, identificar erroneamente a categoria de uma issue, fazendo com que ela seja enviada, já inicialmente, para a pessoa errada, e esta talvez precise redirecioná-la. No entanto, a parte importante é que o fardo ainda está sendo dividido—se o usuário acertou ou não no preenchimento da issue, os acompanhamentos ainda são distribuídos de modo relativamente igual entre os desenvolvedores, então cada issue pode ser respondida à tempo.
A segunda técnica é menos difundida, provavelmente por que é mais difícil de ser automatizada. A principal ideia é que cada issue nova seja "aceita" no banco. Quando um usuário acha que encontrou um problema, lhe é pedido uma descrição do problema em alguma das listas de email, ou em algum canal de IRC, e então espera-se a confirmação de alguém de que aquele é realmente um bug. Trazer este segundo par de olhos pode prevenir um monte de relatórios falsos. Às vezes, esta outra pessoa pode identificar que o compartamento não seja um bug, ou que foi corrigido em atualizações mais recentes. Ou ela pode estar familiar com os sintomas de uma issue antiga, e pode prevenir a duplicata informando o relator do bug da issue antiga. Muitas vezes é suficiente perguntar ao usuário "Você chegou a pesquisar no bug tracker para verificar se este bug já foi informado?". Muitas pessoas simplesmente não pensam nisto, mas pesquisarão satisfeitas sabendo que alguém espera isto delas.
Este sistema de aceitação pode deixar o banco de dados efetivamente limpo, mas ele também tem suas desvantagens. Muitas pessoas irão arquivar issues de qualquer modo, sem avisar outros, seja por não ver ou mesmo ignorando as instruções para achar uma duplicata. Por isto ainda é necessário que voluntários observem o banco de dados de issues. Além do mais, por conta de novos voluntários ainda não terem compreensão da dificuldade que é manter um banco de dados de issues, não é justo repreendê-los muito duramente por ignorarem as instruções. Então voluntários devem ser vigilantes, e analisar o modo de coibição que utilizarão para retornar issues sem aceitação de volta aos seus reportadores. O objetivo é treinar cada reportador a usar o sistema de aceitação no futuro, para que haja uma comunidade ascendente de pessoas que compreendem o sistema de filtro de issues. Identificando uma issue sem aceitação, os passos ideais são:
Imediatamente responder à issue, educadamente agradecendo o usuário por reportá-lo, mas destacando as regras de aceitação (que devem, é claro, estarem destacadas no web site).
Se a issue é claramente válida e não uma duplicata, aprove-a e comece o seu ciclo de vida natural. No final das contas, o usuário arquivou a issue agora está informado sobre o esquema de aceitação, então não há motivo em desperdiçar o trabalho feito fechando uma issue válida.
No entanto, se a issue não for claramente válida, feche-a, mas peça ao reportador para que reabra-a caso receba uma confirmação de aceitação. Quando receberem, eles devem colocar uma referência da confirmação (por exemplo, a URL nos arquivos da lista de emails).
Lembre-se que apesar deste sistema melhorar o controle de falsos positivos no banco de dados ao longo do tempo, mas nunca poderá completamente parar os preenchimentos incorretos de ocorrências. O único modo de controlar estes preenchimentos inválidos é fechar o bug tracker para todos e deixá-lo aberto somente para os desenvolvedores—o que se torna uma cura quase sempre pior que a doença. O melhor é aceitar que limpar issues inválidas será sempre parte da rotina de manutenção do projeto, e tente conseguir o máximo de pessoas possível para ajudar.
Veja também “Issue Manager” em Capítulo 8, Managing Volunteers.