É viável rastrear ou medir a causa dos bugs ou isso é apenas uma questão de consequências não intencionais?

Question

Existe um método para rastrear ou medir a causa de bugs que não resulte em consequências indesejadas para os membros da equipe de desenvolvimento?Recentemente adicionamos a capacidade de atribuir a causa de um bug em nosso sistema de rastreamento.Exemplos de causas incluem:código incorreto, código perdido, requisitos incompletos, requisitos ausentes, testes incompletos, etc.Eu não era um defensor disso, pois podia ver que isso levava a comportamentos não intencionais por parte da equipe de desenvolvimento.Até o momento, esse campo esteve oculto dos membros da equipe e não foi usado ativamente.

Agora estamos no meio de um projeto onde temos um número de bugs maior que o normal e seria bom ter esse tipo de informação para entender melhor onde erramos e onde podemos fazer melhorias no futuro (ou ajustes). agora).Para obter bons dados sobre a causa dos bugs, precisaríamos abrir este campo para entrada dos membros da equipe de desenvolvimento e controle de qualidade e estou preocupado que isso possa gerar maus comportamentos.Por exemplo, as pessoas podem não querer consertar um defeito que não criaram porque sentirão que isso reflete negativamente em seu desempenho, ou podem perder tempo discutindo sobre a classificação de um defeito por razões semelhantes.

Alguém encontrou um mecanismo para fazer esse tipo de rastreamento sem gerar maus comportamentos?É possível esperar dados úteis dos membros da equipe se explicarmos à equipe o raciocínio por trás dos dados (não para gerar métricas de desempenho individuais, mas para métricas de sucesso do projeto)?Existe outra maneira melhor de fazer esse tipo de coisa (talvez uma autópsia mais ad hoc ou uma discussão aberta sobre as questões)?

Answer 1

Muitos pacotes de controle de versão têm coisas como svn blame.Esta não é uma métrica direta para rastrear um bug, mas pode dizer quem fez check-in das alterações em uma versão que contém um bug grave.

Há também programas como http://www.bugzilla.org/ que ajudam a rastrear as coisas ao longo do tempo.

Mas no que diz respeito a realmente investigar por que existem bugs, sim, definitivamente vale a pena investigar, embora eu não possa fornecer uma métrica padrão para coletar essas informações.Existem vários motivos pelos quais um sistema pode apresentar muitos bugs:

• Especificações mal escritas
• Prazos apressados
• Programação de baixa habilidade
• Moral ruim
• Falta de testes beta ou de controle de qualidade
• Falta de preparação do software para que seja viável fazer testes beta ou de controle de qualidade
• Baixa proporção de tempo gasto na limpeza de bugs versus obtenção de novas funcionalidades
• Baixa proporção de tempo gasto fazendo melhorias sem bugs versus obtendo funcionalidades
• Um sistema extremamente complexo que é fácil de quebrar
• Um ambiente em mudança que está fora da base de código, como a administração da máquina
• Culpa por erros que afetam a remuneração ou promoção do programador

Isso é só para citar alguns...Se muitos bugs forem um grande problema, então os gerentes, os programadores líderes e quaisquer outras partes interessadas em todo o processo precisam sentar e discutir o assunto.

Answer 2

Altas taxas de bugs podem ser um sintoma de uma programação que é muito apressada ou inflexível.Mudar para uma abordagem de defeito zero pode ajudar.Corrigir todos os bugs antes de trabalhar em novo código.

Atribuir motivos é uma boa técnica para ver se você tem uma área problemática.Métricas típicas que vi e encontrei são uma divisão mesmo entre:

erros de especificação
• (falta, incorreco, etc.)
• bugs de aplicativos (código incorreto, código ausente, dados ruins, etc.)
• testes incorretos / sem erro (geralmente expectativas incorretas ou especificações ainda não implementadas)

reveiwing e verificar as causas de defeitos podem ser úteis.