How Much Effort Needed to Fix the Bug? A Data Mining Approach for Effort Estimation and Analysing of Bug Report Attributes in Firefox

Vijayakumar, K.; Bhuvaneswari, V.

doi:10.1109/icica.2014.75

Cited by 2 publications

(2 citation statements)

References 7 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Previous research compared the time it takes to repair a bug to understand the bug-fixing process with the bug's opening date [10]. Related research also considered the bug-fix times [11,[32][33][34], but, to our knowledge, none have aimed to determine a correlation between the time it takes to fix a bug, and the hour, or day, the bug was introduced. Thus, we sought to find a statistical difference between which day of the week the programmer introduced the buggy commit and the commit cycle.…”

Section: Descriptive Statisticsmentioning

confidence: 99%

Large-Scale Identification and Analysis of Factors Impacting Simple Bug Resolution Times in Open Source Software Repositories

et al. 2023

View full text Add to dashboard Cite

One of the most prominent issues the ever-growing open-source software community faces is the abundance of buggy code. Well-established version control systems and repository hosting services such as GitHub and Maven provide a checks-and-balances structure to minimize the amount of buggy code introduced. Although these platforms are effective in mitigating the problem, it still remains. To further the efforts toward a more effective and quicker response to bugs, we must understand the factors that affect the time it takes to fix one. We apply a custom traversal algorithm to commits made for open source repositories to determine when “simple stupid bugs” were first introduced to projects and explore the factors that drive the time it takes to fix them. Using the commit history from the main development branch, we are able to identify the commit that first introduced 13 different types of simple stupid bugs in 617 of the top Java projects on GitHub. Leveraging a statistical survival model and other non-parametric statistical tests, we found that there were two main categories of categorical variables that affect a bug’s life; Time Factors and Author Factors. We find that bugs are fixed quicker if they are introduced and resolved by the same developer. Further, we discuss how the day of the week and time of day a buggy code was written and fixed affects its resolution time. These findings will provide vital insight to help the open-source community mitigate the abundance of code and can be used in future research to aid in bug-finding programs.

show abstract

Section: Descriptive Statisticsmentioning

confidence: 99%

Large-Scale Identification and Analysis of Factors Impacting Simple Bug Resolution Times in Open Source Software Repositories

et al. 2023

View full text Add to dashboard Cite

show abstract

“…e score for flaws, during the dispatching step, is usually completed by the developer. However, while sending the defect to the fixer, the severity of the software defect report should be used to establish the defect's priority, and the degree of impact on software development and operation should be stated [4]. As a result, software defect severity prediction is a crucial problem in software defect correction [5].…”

Section: Introductionmentioning

confidence: 99%

An Optimized Systematic Approach to Identify Bugs in Cloud-Based Software

Marappan

Kollu²,

Keshta

et al. 2022

Scientific Programming

View full text Add to dashboard Cite

The resolution of a software bug depends on the severity of the defect report. Open-source software defect tracking solutions have taken over as the principal means of processing enormous amounts of defect information data due to the ongoing increase in software scale. Dealing with software faults requires analyzing the implications of defect report severity in the data warehouse. Thus, the authors have proposed an optimized systematic approach through the research and analysis of Bugzilla defect tracking system data in this study, where it is found that the attribute characteristics of different projects are quite different and the statistical features of the repair rate, resolution time, developers, components, and other attributes are consistent. This technique, therefore, assumes that a rise in the severity of software defect reports will result in a rise in the defect repair rate and that the severity is normally based on the severity distribution of various components and projects. According to the study’s findings, developers hold the most defects when the repair rate is low and the defect resolution time is shortest.

show abstract

How Much Effort Needed to Fix the Bug? A Data Mining Approach for Effort Estimation and Analysing of Bug Report Attributes in Firefox

Cited by 2 publications

References 7 publications

Large-Scale Identification and Analysis of Factors Impacting Simple Bug Resolution Times in Open Source Software Repositories

Large-Scale Identification and Analysis of Factors Impacting Simple Bug Resolution Times in Open Source Software Repositories

An Optimized Systematic Approach to Identify Bugs in Cloud-Based Software

Contact Info

Product

Resources

About