Não é um bug, é uma feature

Em um exame manual em uma base de dados de mais de 7.000 relatórios de bugs de cinco projetos de código aberto, foi encontrado 33,8% dos relatórios de bugs classificados de maneira incorreta, isto é, em vez de se referir a uma correção de código (correção de bug), que resultou em um “novo recurso”, uma “atualização de documentação”, ou até mesmo uma refatoração.

Este erro de classificação permaneceu frequente nos modelos de previsão de erro, confundindo bugs com funcionalidades: Em média, 39% dos arquivos marcados como defeituosos, na verdade nunca possuíram um bug.

Através da Engenharia de Software, tornou-se comum explorar bancos de dados de Manutenções e de Erros de software para detectar onde os bugs ocorreram no passado, e/ou para prever onde eles irão ocorrer no futuro. A precisão das medições e as possíveis previsões dependem da qualidade destes dados.

Um desafio na Mineração de Dados geralmente é separar não-bugs de bugs. É muito comum em bases de dados de bugs, a maioria dos relatórios serem classificados como erros, ou seja, pedidos de código de manutenção corretiva.
No entanto, um relatório de problema pode referir-se a “manutenção de aperfeiçoamento, adaptação, refatoração, discussões, pedidos de ajuda, e assim por diante”, isto é, as atividades não estão relacionados com os erros no código, e deveriam ser classificadas em uma categoria de não-bugs.

Uma das principais questões abordadas neste artigo é que, de cinco projetos de código aberto, foram classificamos manualmente mais de 7.000 relatórios em um conjunto fixo de alternativas para claramente distinguir o tipo de trabalhos de manutenção necessários para resolver tal tarefa (algumas delas erroneamente classificadas como bug).
No entanto surgiu um problema de confiabilidade. Nas bases de dados de bugs investigadas, mais de 40% dos relatórios foram erroneamente classificados. Um em cada três bug não deveria ter sido classificado como tal, onde 33,8% de todos os relatórios de erros não se referem a código de manutenção corretiva (correção de bugs).

Para classificar melhor o sujeito da analise, foi realizado o estudo em cinco projetos Java open source. O objetivo foi selecionar projetos que estavam em desenvolvimento ativo e foram desenvolvidos por equipes que seguem rigorosos padrões de rastreamento de bugs. Também foi priorizando um conjunto de dados homogêneo que aliviou na fase de inspeção manual. Projetos como APACHE e Mozilla se encaixaram melhor as necessidades . Além disso, foram selecionados cinco projetos de tal forma que cubram pelo menos dois sistemas de rastreamento de bugs diferentes e mais populares, como o: Bugzilla e o Jira.

Depois de analisados todos os cinco projetos pesquisados​​, foram encontrados 42,6% de relatórios de bugs erroneamente digitados.
Entre 13% e 6% dos relatórios arquivados (status de finalizado), são de solicitações de melhoria (manutenção corretiva) e 10% contem problemas de documentação. A fração de relatórios de bugs que continham pedidos de novos recurso encontram-se entre 2% e 7%. Um número impressionante, porém, em média, 33,8% de todos os relatórios foram classificados erroneamente.

Mecanismos de Mineração de Software tem sido vistos como o segredo da automatização completa de software, tudo o que teoricamente precisa fazer é apontar a ferramenta de mineração, uma nova fonte de dados, estabelecer as correlações e recomendações. Os resultados deste trabalho sugerem problemas generalizados com a separação de bugs e não-bugs em arquivos de software, o que pode afetar seriamente a precisão de qualquer ferramenta e de estudo que utiliza desses dados, principalmente em larga escala.

Esta foi uma análise do artigo: It’s not a bug, it’s a feature: how misclassification impacts bug prediction