The Bug Bang Theory

(2 votes, average: 9,00 out of 10)

 Loading ...

Estou escrevendo esse post para passar para frente um pensamento que tenho ha algum tempo sobre o nosso popular termo “BUG”.

Acredito que todo mundo já conhece essa história e nunca cansa de contar para todas as pessoas que perguntam o porquê desse termo, levando em consideração a conotação de defeito de software que é atribuído a esse termo.

O que quero perguntar é: Esse termo ainda é adequado?

Meu ponto de vista é que o nosso tradicional bug, ainda é o bug de 1945, atribuído a construção e a engenharia. Se pensarmos nas fases do RUP, o bug é identificado em um código fonte ou em um produto de trabalho derivado da fase de construção ou identificado em um produto já em testes, homologação ou produção.

O problema é que ao longo de vários anos estamos aprendendo que o bug, aquele que está no código fonte, não é o único problema proveniente da engenharia de software, na verdade, muitas das vezes ele é somente uma consequência de um defeito em outra atividade ou em outro produto de trabalho.

O que quero deixar bem claro é que não considero a nomenclatura errada, apenas acredito que o termo não é o mais adequado no cenário atual, levando em consideração a conotação de defeito de software que é atribuído a esse termo.

Acredito que existam tantos defeitos quanto papeis dentro de um processo de fabricação de software. Logo o Gerente de Projetos erra e gera defeitos de planejamento, o analista de negócios/requisitos erra e gera defeitos de requisitos e assim por diante.

Todos os papeis ou até mesmo atividades de um processo podem gerar problemas no software ou sistema desenvolvido, o problema é que muitas vezes chamamos isso de não conformidade e não fazemos a coleta adequada desses números. Mas os defeitos sempre estão gerenciados pelo Bugzilla, pelo Mantis ou por uma ferramenta “bugtracker” qualquer.

Quando acontece algum problema em um projeto, os primeiros dados medidos e comparados são os bugs, sim os que cadastramos para os desenvolvedores. Esses bugs sempre tem origem no software e sempre são de responsabilidade dos programadores.

Mas e os defeitos de requisitos? E as mudanças de cronograma? E os defeitos que podiam ser identificados antes e agora estão mais caros porque os analistas de teste não identificaram no momento mais adequado?

Bom, esses são meus argumentos para justificar o título desse post. Acho que o BUG está morto, e é tempo para pensarmos em defeitos como produtos de trabalho, exceções das atividades de todos envolvidos no processo. É tempo de aliviar um pouco os nossos desenvolvedores e fazer a equipe assumir os problemas como devem ser assumidos.

Importante, não quero dizer para apontarmos responsáveis por defeitos, ou para ficar medindo o índice de defeitos de cada colaborador, mas sim para dentro dos nossos processos termos como argumentar a entrada da equipe de teste e qualidade o mais cedo. Mostrar que podemos verificar os requisitos e identificar defeitos que mais tarde iriam virar bugs de software, mostrar que às vezes nos não conhecemos tão bem os nossos próprios processos ou pior, às vezes achamos que conhecemos bem e tomamos decisões ineficazes para resolver problemas com base nas suas conseqüências e não na sua raiz.

Sugiro uma reflexão sobre as métricas que usamos para gerir nossos defeitos, conscientização de que todos nós falhamos e aos poucos vamos conseguindo identificar onde devemos melhorar a equipe, onde podemos melhorar os processos, quem precisa de mais capacitação e investimento, etc.


This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.