BT

Epidemia dos bugs: corrigir agora ou postergar?

por Michael Stal , traduzido por Leandro Guimarães em 21 Set 2012 |

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?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Prevenção by Marcio Silva

Uma solução só pode ser considerada se estiver comprovada a sua efetividade. A comprovação, por sua vez, é obtida pela aplicação, que é quando se investiga a fundo o problema. Se não se corrige os problemas não se adquire domínio dos mesmos e das repectivas soluções. Dados isto, como será possível agir preventivamente?

Re: Prevenção by Giulliano Morroni

É uma pena saber que ainda existem empresas (que perdem tempo) agendando reunião para discutir assuntos tão pequenos....e o que me deixa mais triste é saber que nessas reuniões, sempre levam uma pessoa da área técnica para ficar divagando sobre as 10 maneiras de se corrigir um bug. Sim, os bugs sempre existirão, e quase nunca, são problemas técnicos e sim comercias, normalmente por falta de entendimento entre as partes envolvidas.

Esse tipo de atitude (reuniões sobre bugs) só deveria existir em caminhos críticos onde o bug afeta a empresa ou o sistema de forma grave. Nesses casos não considero como perca de tempo.

Re: Prevenção by Paulo Tiago Castanho Mariano

Se não se corrige os problemas não se adquire domínio dos mesmos e das respectivas soluções. Dados isto, como será possível agir preventivamente?


Marcio, sua colocação parece que está com Elizabeth, que só se adquire domínio se corrigir os problemas.

Na minha opinião para agir preventivamente deve sempre procurar a causa raiz dos problemas.
Agindo somente corrigindo problemas sem questionar gera sim um "caos" pois nem tudo que é solicitado é válido. Claro que as reuniões para discutir se vai ser corrigido ou não alguma coisa deve ser rápida, dentro também é importante ter um processo que seja possível rastrear os problemas levantados, onde não haja retrabalho de discutir uma coisa já discutida.

Esse assunto me lembrou de XGH

Vale lembrar também que qualquer pensamento "fanático" é condenável.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

3 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT