Buginnings

Sinha, Vibha Singhal; Sinha, Saurabh; Rao, Swathi

doi:10.1145/1730874.1730879

Cited by 15 publications

(1 citation statement)

References 30 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Nagappan showed a strong correlation between the static analysis defect density and the pre-release defect density determined by testing. Sinha, Sinha, and Rao (2010) presented a new approach for determining the origins of a bug, based on the effects a bug fix has on program dependencies, and based on those effects, attempts to determine the previous bug-introducing version.…”

Section: Motivation and Related Workmentioning

confidence: 99%

Faults and Their Relationship to Implemented Patterns, Coupling and Cohesion in Commercial C# Software

Counsell

Gatrell

2012

International Journal of Information System Modeling and Design

View full text Add to dashboard Cite

This paper documents a study of fault proneness in commercial, proprietary software and attempts to determine whether a relationship exists between class faults and the design context of a class, namely the coupling and cohesion of a class, and whether the class is a participant of common design patterns. The authors studied a commercial software system for a 24 month period and identified design pattern participants by inspecting the design documentation and source code; coupling and cohesion metrics were measured by inspecting the source code with a tool; we also extracted fault data for the same period to determine whether a relationship existed between the design context and the fault propensity of a class. Results showed that design pattern participant classes were marginally more fault-prone than non-participant classes, The Adaptor, Method and Singleton patterns were found to be the most fault-prone of thirteen patterns explored. Coupling was found to have a significant relationship with the fault proneness of classes in the system; efferent coupling was a stronger indicator of fault propensity than afferent coupling. Cohesion, when measured using the LCOM(HS) metric, was not found to have a strong relationship with fault proneness.

show abstract

Section: Motivation and Related Workmentioning

confidence: 99%

Faults and Their Relationship to Implemented Patterns, Coupling and Cohesion in Commercial C# Software

Counsell

Gatrell

2012

International Journal of Information System Modeling and Design

View full text Add to dashboard Cite

show abstract

Comparing text‐based and dependence‐based approaches for determining the origins of bugs

Davies

Roper

Wood

2013

J Software Evolu Process

View full text Add to dashboard Cite

This version is available at https://strathprints.strath.ac.uk/45285/ Strathprints is designed to allow users to access the research output of the University of Strathclyde. Unless otherwise explicitly stated on the manuscript, Copyright © and Moral Rights for the papers on this site are retained by the individual authors and/or other copyright owners. Please check the manuscript for details of any other licences that may have been applied. You may not engage in further distribution of the material for any profitmaking activities or any commercial gain. You may freely distribute both the url (https://strathprints.strath.ac.uk/) and the content of this paper for research or private study, educational, or not-for-profit purposes without prior permission or charge.Any correspondence concerning this service should be sent to the Strathprints administrator: strathprints@strath.ac.ukThe Strathprints institutional repository (https://strathprints.strath.ac.uk) is a digital archive of University of Strathclyde research outputs. It has been developed to disseminate open access research outputs, expose data about those outputs, and enable the management and persistent access to Strathclyde's intellectual output. SUMMARYIdentifying bug origins -the point where erroneous code was introduced -is crucial for many software engineering activities, from identifying process weaknesses and improvements to gathering data to support tool development for bug detection. Unfortunately this information is not usually recorded when fixes are made, and recovering it later is challenging. Recently the text approach and the dependence approach have been developed to tackle this problem. Respectively, they examine textual and dependence-related changes that occurred prior to a bug fix. However, only limited evaluation has been carried out, partially due to the lack of data-sets linking bugs to origins, and a lack of available implementations. To address this, origins of 174 bugs in three open-source projects were manually identified and compared to a simulation of the approaches. Both approaches were partially successful across a variety of different bugsachieving precision of 29%-79% and recall of 40%-70%. Results suggested the precise definition of program dependence could affect performance, as could the decision on whether to identify a single or multiple origins. A number of potential improvements are explored in detail and serve to identify pragmatic strategies for combining the techniques along with relatively simple modifications. Even after adopting these improvements there remain many challenges: large commits, unrelated changes and long periods between origins and fixes all reduce effectiveness.

show abstract

How bugs are born: a model to identify how bugs are introduced in software components

et al. 2020

View full text Add to dashboard Cite

When identifying the origin of software bugs, many studies assume that "a bug was introduced by the lines of code that were modified to fix it". However, this assumption does not always hold and at least in some cases, these modified lines are not responsible for introducing the bug. For example, when the bug was caused by a change in an external API. The lack of empirical evidence makes it impossible to assess how important these cases are and therefore, to which extent the assumption is valid. To advance in this direction, and better understand how bugs "are born", we propose a model for defining criteria to identify the first snapshot of an evolving software system that exhibits a bug. This model, based on the perfect test idea, decides whether a bug is observed after a change to the software. Furthermore, we studied the model's criteria by carefully analyzing how 116 bugs were introduced in two different open source software projects. The manual analysis helped classify the root cause of those bugs and created manually curated datasets with bug-introducing changes and with bugs that were not introduced by any change in the source code. Finally, we used these datasets to evaluate the performance of four existing SZZ-based algorithms for detecting bug-introducing changes. We found that SZZ-based algorithms are not very accurate, especially when multiple commits are found; the F-Score varies from 0.44 to 0.77, while the percentage of true positives does not exceed 63%. Our results show empirical evidence that the prevalent assumption, "a bug was introduced by the lines of code that were modified to fix it", is just one case of how bugs are introduced in a software system. Finding what introduced a bug is not trivial: bugs can be introduced by the developers and be in the code, or be created irrespective of the code. Thus, further research towards a better understanding of the origin of bugs in software projects could help to improve design integration tests and to design other procedures to make software development more robust. Keywords Bug origins • Bug-introducing changes • First-failing change • SZZ algorithm • Extrinsic bugs • Intrinsic bugs Communicated by: Per Runeson

show abstract

Buginnings

Cited by 15 publications

References 30 publications

Faults and Their Relationship to Implemented Patterns, Coupling and Cohesion in Commercial C# Software

Faults and Their Relationship to Implemented Patterns, Coupling and Cohesion in Commercial C# Software

Comparing text‐based and dependence‐based approaches for determining the origins of bugs

How bugs are born: a model to identify how bugs are introduced in software components

Contact Info

Product

Resources

About