Fonte: http://inospito.com/2007/11/01/bugtracker-como-e-possivel-nao-usar/
Uma das ferramentas básicas para o desenvolvimento de software com qualidade é o bugtracker. Tal como um bom IDE, o bugtracker é uma das ferramentas das quais não prescindo de maneira nenhuma, e considero a sua utilização como um requisito obrigatório se queremos desenvolver software com qualidade.
Infelizmente, os cursos de Engenharia Informática em Portugal não abordam este assunto, pelo que (já) não me surpreende que tenha encontrado tantos programadores ao longo dos anos que não usam nem fazem ideia da sua utilidade. Para quem não sabe, um bugtracker é simplesmente uma ferramenta onde se introduzem os bugs que encontramos numa aplicação e onde podemos depois acompanhar e controlar a evolução de cada bug: se está a ser corrigido, se já foi corrigido, em que versão foi corrigido, etc. Claro que as ferramentas de bugtracking fazem uma miríade de outras coisas, como relatórios, envio de mails de notificação ou pesquisas, mas o que realmente interessa é permitir acompanhar/controlar a evolução de um bug. Como é que uma ferramenta tão simples pode ter um papel tão importante?
Quando não usamos um bugtracker, temos o seguinte possível cenário (imaginem dois developers X e Y):
- X recebe um telefonema de um cliente, desesperado com um comportamento estranho da aplicação quando se clica duas vezes no quadrado vermelho que pisca
- X já imagina qual a linha de código que estragou a coisa e começa a corrigir
- Y que não está junto de X, recebe um telefonema de outro cliente com o mesmo problema. Claro que nós (leitores) sabemos que é o mesmo problema, mas o cliente não sabe e muito menos Y. Ainda por cima, Y nem imagina onde esteja o bug, porque ele não desenvolveu essa parte da aplicação.
- Y começa a tentar descobrir onde está o bug
- X já quase resolveu o bug, mas está a demorar imenso tempo porque está permanentemente a ser interrompido por telefones e mails de clientes a refilar por causa do bug.
- X resolve o bug e faz uma nova versão da aplicação. Claro que a nova versão não tem só a correcção do quadrado vermelho que pisca. Tem outras correcções que foram feitas recentemente. Ele tem que compilar a lista de correcções: ver os mails trocados entre os developers, telefonar aos outros developers, etc.
- Y já encontrou o sítio onde está o bug mas entretanto recebe um telefonema de X, perguntando que correcções foram feitas recentemente. Y diz-lhe que está a resolver o problema do quadrado vermelho que pisca. X responde-lhe que já foi resolvido. Y desespera. Os clientes continuam a telefonar.
- …
Se usassem um bugtracker, o cenário poderia ser algo diferente:
- X recebe um telefonema de um cliente, desesperado com um comportamento estranho da aplicação quando se clica duas vezes no quadrado vermelho que pisca
- X introduz no bugtracker a descrição do bug e comunica ao cliente o identificador do bug, para que o cliente possa acompanhar a evolução do mesmo através da web (outra hipótese seria o próprio cliente introduzir o bug no bugtracker).
- X já imagina qual a linha de código que estragou a coisa e começa a corrigir, mas primeiro marca esse bug como “Em Correcção” na ferramenta
- Y que não está junto de X, recebe um telefonema de outro cliente com o mesmo problema. Claro que nós (leitores) sabemos que é o mesmo problema e Y, após pesquisar no bugtracker, também sabe.
- X resolveu o bug rapidamente porque a maioria dos clientes, antes de telefonarem ou enviarem email a refilar, pesquisaram no bugtracker e viram que o bug estava em correcção.
- X faz uma nova versão da aplicação e consegue saber todas as correcções incluídas na versão com uma simples pesquisa “Bugs resolvidos na versão XXX”
Existem imensos bugtrackers no mercado, muitos deles open-source. E não existe razão nenhuma para não se usar um bugtracker. Claro que podemos usá-los de muitas formas, algumas mais correctas do que outra. Espero falar disso num futuro post. Mas uma coisa vos garanto. Quem já trabalhou com um bugtracker, nem se imagina a trabalhar um dia sem um.
Evandro Paes 