Algumas equipes de desenvolvimento, especialmente equipes de Agile, não se incomodam com erros de rastreamento. Em vez de usar um sistema de rastreamento de bugs, quando os testadores encontram um bug, eles falam para o desenvolvedor e o consertam, ou escrevem um teste de falha que precisa ser corrigido e o adicionam ao conjunto de testes de integração continua ou, se necessário, escrevem uma bug story em um cartão e o colocam na parede para que a equipe saiba sobre ele e alguém se comprometa a corrigi-lo.

Outras equipes vivem por seus sistemas de rastreamento de bugs, usando ferramentas como Jira, Bugzilla ou FogBugz para registrar erros, bem como alterações e outros trabalhos. Há argumentos a serem feitos para ambas as abordagens.

Argumentos para rastreamento de bugs – e para não rastrear bugs

Em Agile Testing: A Practical Guide for Testers and Agile Teams, Lisa Crispin e Janet Gregory examinam os prós e os contras do uso de um sistema de rastreamento de falhas.

Usar um sistema para rastrear bugs pode ser a única forma eficaz de gerir os problemas de equipes que não podem se encontrar face a face – por exemplo, equipes distribuídas e espalhadas por diversos fusos horários. Também pode ser útil para equipes que herdaram bugs abertos em um sistema legado; e um mal necessário para as equipes que são forcadas a acompanhar bugs, por razões de compliance. As informações em um banco de dados de bugs é uma base de conhecimento potencial para testadores e desenvolvedores novos na equipe – eles podem rever os erros que foram encontrados antes na área do código em que eles estão trabalhando para compreender os problemas com os quais têm que lidar. E os dados de bugs podem ser usados para coletar métricas e criar tendências sobre erros – se você acha que as métricas de erros são úteis.

Mas a visão Lean/Agile é que o uso de um sistema de rastreamento de falhas em sua maioria atrapalha e atrasa as pessoas. A equipe deve manter o foco na busca por erros, corrigi-los, e depois esquecê-los. Os erros são os resíduos, e tudo sobre ele é desperdício – informações mortas, e o tempo morto que seria melhor usado para entregar valor. Pior, usar um sistema de rastreamento de falhas impede testadores e desenvolvedores de falar uns com os outros e incentiva os testadores a terem uma “Política de Qualidade” mental. Sem uma ferramenta, as pessoas têm de falar umas com as outras, e têm que aprender a andar bem juntos.

Esse é um ponto de vista tático, a curto prazo, com foco no que é necessário para obter o software correto e funcionando. É um pensamento no projeto, e não no produto.

Bugs a longo prazo

Mas se você está trabalhando em um sistema por um longo tempo, como nós, se você está administrando um produto ou executando um serviço, você sabe que não é assim tão simples. Você não pode apenas olhar para o que está diante diante de você, e onde você quer estar em um ano ou mais. Você também tem que olhar para trás, para o trabalho que foi feito antes, os problemas que aconteceram antes, as decisões que foram tomadas antes, para entender por que você está onde está hoje e para onde você pode ir no futuro.

Devido a alguns problemas que nunca vão embora. E outros problemas que voltarão, a não ser que você faça alguma para impedi-los. E você vai descobrir que outros problemas que você pensou que havia liquidado nunca foram embora realmente. As informações de bugs antigos, o que aconteceu e o que foi feito para corrigi-los (ou por que não puderam ser corrigidos), que soluções alternativas trabalhadas (ou não) podem ajudá-lo a continuar a melhorar o sistema e como você pode construí-lo e mantê-lo funcionando.

Porque você deve entender o histórico de alterações e correções no código se você for modificá-lo. Se você gosta da forma como o código está hoje, você pode querer saber como e por que ele ficou assim. Se você não gostar, você vai querer saber como e por que ficou dessa forma – é arrogante supor que você não vai cometer os mesmos erros ou ser forçado para os mesmos tipos de situações. Controle de revisão irá dizer-lhe o que foi alterado, quando e quem fez isso, o sistema de reastreamento de bugs vai dizer por quê.

Porque você precisa saber onde você tem instabilidade e risco no sistema. Você precisa identificar um código propenso a bugs – código que contem muitos erros, o código que lhe irá custar muito para manter e causará muitos problemas, o código que é muito caro para manter funcionando da maneira como está hoje. O código que você deve rescrever o mais rápido possível para melhorar a estabilidade e reduzir seus custos . Mas você não consegue identificar esse código sem saber o histórico de problemas no sistema.

Porque você pode precisar provar aos auditores, reguladores, clientes e investidores que está fazendo um trabalho responsável de testar e encontrar os erros, corrigi-los e acabar com as correções.

E porque você quer saber o quão eficaz a equipe é em encontrar, corrigir e prevenir erros. Você está vendo menos bugs hoje? Ou mais bugs? Você está vendo os mesmos tipos de erros – você está cometendo os mesmo erros? Ou erros diferentes?

Você precisa controlar todos os bugs?

Enquanto os bugs são encontrados cedo o suficiente, há pouco valor em monitorá-los. É quando os erros escapam que eles precisam ser monitorados: erros que o desenvolvedor não encontra de imediato por conta própria, ou em emparelhamento, ou através do controles automáticos padrão e os testes que são executados em Integração Continua.

Não fazemos log de

• defeitos encontrados em testes unitários ou outros testes automatizados – a menos que, por algum motivo, o problema não possa ser corrigido imediatamente;
• problemas encontrados em avaliações pelos pares – a menos que algo na revisão seja considerado significativo e não possa ser abordado imediatamente. Ou um problema é encontrado em uma revisão final, após os testes começarem, e o código terá que ser testado novamente. Ou o revisor encontra algo errado no código que não foi alterado, um bug antigo – ainda é um problema que precisa ser olhado, mas ele pode estar preparado para lidar com ele agora. Todos os problemas encontrados nas revisões externas, como uma revisão de segurança ou uma auditoria, são registrados;
• resultados de analise estática – a maioria dos problemas capturados por essas ferramentas são simples erros de codificação que podem ser vistos e corrigidos imediatamente, e também costuma haver uma boa quantidade de ruídos (falsos positivos) que deve ser filtrada. Nós executamos verificações de análise estática e as revisamos diariamente, e registramos apenas os resultados se concordamos que a descoberta é real, mas o desenvolvedor não está preparado para corrigi-lo imediatamente (o que quase nunca acontece, a menos que estejamos executando uma nova ferramenta contra uma base de dados já existente pela primeira vez). De qualquer forma, muitas ferramentas de análise estática têm seus próprios sistemas para rastrear resultados de análise estática, por isso sempre podemos voltar e rever questões pendentes depois;
• erros encontrados quando os desenvolvedores e testadores decidem se juntar para testar mudanças no início do desenvolvimento, principalmente quando estão explorando como algo deveria funcionar – não costumamos registrar erres erros, a menos que não possam ser/não serão corrigidos (podem ser reproduzidos mais tarde, por exemplo)

Bug é algo terrível de se desperdiçar

Nós registramos todos os outros erros, independentemente de eles serem encontrados em produção, em testes internos, testes de parceiros, testes de aceitação do usuário, ou teste externo (como um pen test). Porque na maioria das vezes, quando o software é entregue a um testador, ele deveria estar funcionando. Se o testador encontra bugs, especialmente sérios, então essa é uma informação importante para o testador, para o desenvolvedor, e para o resto da equipe. Ele destacar os riscos. Ele pode mostrar onde são necessários mais testes e opiniões. Ele pode destacar problemas mais profundos no projeto, a falta de compreensão que poderia causar outros problemas.

Se você acredita que o teste fornece informações importantes não apenas sobre o estado do seu software, mas também sobre como você o está projetando e construindo – então todo mundo precisa ser capaz de ver essa informação, e compreendê-la ao longo do tempo. Alguns problemas podem não ser vistos ou compreendidos de imediato, ou no tempo de 1 ou 2 semanas. Pode demorar um pouco antes de você reconhecer que tem uma grave deficiência no projeto ou que algo está quebrado em sua abordagem de desenvolvimento ou em sua cultura. Você precisa experimentar alguns problemas antes de começar a encontrar relações entre eles e antes que você possa olhar para a raiz de seu problema. Você vai precisar de dados do passado, afim de resolver os problemas no futuro.

Rastrear bugs não é um desperdício se você aprender com os bugs. Jogar fora as informações sobre bugs é o verdadeiro desperdício.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em   http://swreflections.blogspot.com.br/2013/02/a-bug-is-terrible-thing-to-waste.html