Gerencie os bugs com o Mantis Bug Tracker

Bom este artigo é indicado à você que não conhece o Mantis e que não costuma gerenciar os bugs do seu software.

Não sei se você tem algum time de testers em sua empresa, caso tenha é interessante uma boa ferramenta para relatar e registrar bugs.

O mantis é nada mais que uma ferramenta web gratuíta para gerenciar os bugs de softwares e possuíndo uma versão paga mobile (MantisTouch), que não será o foco desse post. Criado no ano de 2000, com o tempo ele adquiriu popularidade e amadurecimento, sendo hoje um dos mais populares software open source para bugs. Seu desenvolvimento foi feito em PHP e funciona em parceria com diversos bancos de dados entre eles MySQL e PostgreSQL.

MantisBT está disponível em várias distribuições Linux , incluindo: Debian , Ubuntu, Fedora, Gentoo, Frugalware e outros. Para usuário Windows ou Mac basta fazer o download do próprio site.

Se você não testa, você não é ágil!

O colega Robson Pelegrini reportou na lista [scrum-brasil] uma situação que é comum, principalmente em equipes que estão iniciando no desenvolvimento ágil de software e que (com a devida autorização) transcrevo abaixo:

Pessoal,

Gostaria de saber como vocês tratam a questão dos bugs que surgem dentro do SPRINT, por exemplo:

• Criam um item no SPRINT BACKLOG, “correção de bugs”
• Bugs é responsabilidade do time concertar, não podendo esse impactar na entrega do SPRINT

Acredito que a partir da 1ª entrega feito ao PO, temos o que podemos chamar de “legado”, e então começam a surgir bugs e mudanças de requisitos e funcionalidades que geralmente afetam o planejamento feito para o próximo SPRINT.

– Isso costuma ocorrer com vocês ? Como vocês lidam com essas situações ?

Necessário pontuar algumas coisas num cenário como este.  Vamos a elas.

O QUE VEM A SER UM “BUG” DE SOFTWARE?

Como seres humanos, todos estamos sujeitos a erros.  Assim, mais ainda quando estamos lidando com um produto em desenvolvimento, ou seja, que está sendo construindo.  Muitos projetos de software mantém dois ramos do produto –um estável e um em desenvolvimento– justamente para diferir a quantidade de bugs em potencial que podem estar contidos no produto.

Se por um lado tudo isso é verdade, por outro, quando tratamos de desenvolvimento ágil de software, deve-se partir da premissa de que a cada iteração no ciclo de desenvolvimento um item de valor deve ser entregue ao cliente.  São os releases curtos.

Isto posto, cabe nos perguntarmos: afinal o que é um “bug” de software?