Predicting fault incidence using software change history

Abstract

|This paper is an attempt to understand the processes by which software ages. We de ne code to be aged or decayed if its structure makes it unnecessarily di cult to understand or change, and we measure the extent o f d ecay by counting the number of faults in code in a period of time. Using change management data from a very large, long-lived software system, we explore the extent to which measurements from the change history are successful in predicting the distribution over modules of these incidences of faults. In general, process measures based on the change history are more useful in predicting fault rates than product metrics of the code: for instance, the number of times code has been changed is a better indication of how many faults it will contain than is its length. We also compare the fault rates of code of various ages, nding that if a module is on the average a year older than an otherwise similar module, the older module will have roughly a third fewer faults. Our most successful model measures the fault potential of a module as the sum of contributions from all of the times the module has been changed, with large, recent changes receiving the most weight. Keywords| F ault potential, code decay, change management data, metrics, statistical analysis, generalized linear models.

Using static analysis to determine where to focus dynamic testing effort

“…The work by Graves et al [4] is most similar to ours, as they also construct models to predict fault-proneness. In contrast to Graves et al, however, our model makes predictions for individual files of the system, rather than for modules that are collections of files as was done in [4].…”

“…In contrast to Graves et al, however, our model makes predictions for individual files of the system, rather than for modules that are collections of files as was done in [4]. The fact that the granularity of the entities we use in our static analysis is significantly finer than that used by Graves et al is important since it should facilitate the identification of faults in a much more localized portion of the code, thereby making debugging easier as well.…”

Influence of confirmation biases of developers on software quality: an empirical study

“…al. [36] also used metrics regarding development organization that worked on a specific code and number of developers who made changes on that code, as well as churn metrics for the prediction of defective modules. According to the results obtained by the authors, the number of developers who have changed a module did not improve the defect prediction performance.…”

A Framework for Defect Prediction in Specific Software Project Contexts

“…Implicit variable specification to predict file defect proneness Menzies et al [13] Implict goal description Implicit research question, hypotheses described later in the paper Explicit variables specification for module defect proneness Graves et al [3] Goal is implicitly described Implicit research questions with no hypotheses Explicit variables specification for module defect proneness Sunghun et al [25] Implicit goal description…”

“…Depicts the need for model calibration or refinement Nagappan et al [16] State briefly with no data N/A Li et al [11] Cross validation with different releases N/A Weyuker [27] N/A N/A Menzies [13] N/A N/A Graves [3] N/A N/A Sunghun [25] N/A N/A Pai et al [22] N/A N/A Olague et al [19] N/A N/A Table 2 outlines the collected data regarding common practices to construct prediction models. Most of these studies used variable selection prior to model construction.…”