Elizabeth Hendrickson, consultora norte-americana focada em automação de testes e desenvolvimento ágil, publicou recentemente em seu blog uma análise a respeito do tempo desperdiçado em reuniões para a análise de bugs. Em seu post, a autora cita empresas que gastam muito tempo e dinheiro realizando testes, sem aproveitar bem as informações reveladas por eles.
Hendrickson relata que há uma concepção comum, mas equivocada, na comunidade de engenharia de software, de que os bugs são inevitáveis e que nem todos podem ser corrigidos. Isso justificaria a tomada de decisões de se fazer a correção ou postergá-la, com base em ROI (retorno do investimento) do projeto.
A autora trabalhou em duas companhias em que essa linha de pensamento tornou-se uma armadilha. Segundo Hendrickson, as empresas não faliram diretamente por causa dos bugs, mas esses bugs se tornaram uma "infecção generalizada" que derrubou a produtividade e paralisou times de testes e de engenheiros.
Foram os custos ocultos que nos esgotaram: horas perdidas argumentando sobre bugs em reuniões de análise; horas perdidas debatendo sobre assuntos já discutidos várias outras vezes; lutando contra um código frágil e propenso a gerar erros mesmo com alterações simples; registrando e categorizando o backlog. Isso era desmoralizante e extremamente caro.
A autora elabora algumas conclusões, de acordo com as suas experiências:
Cancele todas as reuniões para avaliação de bugs; gaste seu tempo prevenindo e corrigindo defeitos. Teste cedo e frequentemente para encontrar os bugs o quanto antes. Corrija os bugs assim que forem identificados; cuide cedo de suas janelas quebradas.
Leitores do blog registraram seus comentários a respeito do artigo. Jim Gay, por exemplo, disse:
Vi bugs que indicavam que o processo de desenvolvimento estava errado. Por exemplo, um analista diz que você deve fazer X e você implementa X, e depois os usuários perguntam porque o programa não está fazendo Y. Um erro no código ou um erro no processo significam que alguma coisa deve ser corrigida.
Gabe Newcomb não concorda com todas as considerações de Hendrickson:
O texto deixa a entender que todos os bugs devem ser corridos e o esforço para fazer isso é mais importante que o desenvolvimento de novas funcionalidades. Mas isso não bate com a minha experiência. O processo de triagem de bugs responde a questões importantes como: quando (e se) o bug deverá ser corrigido e onde se encaixa em relação a outras atividades.
Steve Fenton é um desenvolvedor que acredita que todos os bugs devem ser corrigidos:
O tempo gasto para corrigir um bug é quase sempre menor que o tempo necessário para discutir se deve ou não ser corrigido. Além do impacto no cliente, um defeito já existente pode ser lançado novamente pelo time de testes e ser fechado como duplicado diversas vezes pelos desenvolvedores. Quanto mais tempo se postergar uma correção, maiores são as chances de que custe mais do que se o defeito tivesse sido corrigido rapidamente.
O assunto relatado por Hendrickson é polêmico e sempre rende boas discussões. Você acredita que os bugs são inevitáveis? Considera que essa mentalidade pode ser classificada como uma armadilha?