Bugtracker – Como é possível não usar?
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.
Um currículo caprichado pode fazer a diferença entre uma leitura atenta por parte do avaliador, ou uma simples análise apressada que classifica você como “mais um que copiou o modelo que saiu no jornal”, e o coloca na pilha de descarte. Você não precisa ser um designer profissional para fazer um currículo caprichado – basta ter um pouco de bom senso, e usar bem os recursos que o seu editor de texto lhe coloca à disposição.
Ao contrário do que o candidato pode pensar, isso não significa que aquele que tem o currículo mais caprichado leva vantagem (embora indiretamente leve), mas sim que aqueles que enviam um currículo desleixado ou incompleto acabam ficando para trás, porque as informações essenciais para a tomada da minha decisão acabam não estando tão acessíveis quanto deveriam – e isso certamente diz alguma coisa sobre o profissional que enviou aquele documento.