What's in a bug report?

Context: Bug reports are the primary means by which users of a system are able to communicate a problem to the developers, and their contents are important - not only to support developers in maintaining the system, but also as the basis of automated tools to assist in the challenging tasks of finding and fixing bugs. Goal: This paper aims to investigate how users report bugs in systems: what information is provided, how frequently, and the consequences of this. Method: The study examined the quality and quantity of information provided in 1600 bugs reports drawn from four open-source projects (Eclipse, Firefox, Apache HTTP, and Facebook API), recorded what information users actually provide, how and when users provide the information, and how this affects the outcome of the bug. Results: Of the recorded sources of information, only observed behaviour and expected results appeared in more than 50% of reports. Those sources deemed highly useful by developers and tools such as stack traces and test cases appeared very infrequently. However, no strong relationship was observed between the provided information and the outcome of the bug. Conclusions: The paper demonstrates a clear mismatch between the information that developers would wish to appear in a bug report, and the information that actually appears. Furthermore, the quality of bug reports has an important impact on research which might rely on extracting this information automatically.

[1]  Thomas Zimmermann,et al.  What Makes a Good Bug Report? , 2008, IEEE Transactions on Software Engineering.

[2]  Marc Roper,et al.  Using Bug Report Similarity to Enhance Bug Localisation , 2012, 2012 19th Working Conference on Reverse Engineering.

[3]  Philip J. Guo,et al.  Characterizing and predicting which bugs get fixed: an empirical study of Microsoft Windows , 2010, 2010 ACM/IEEE 32nd International Conference on Software Engineering.

[4]  K. Barraclough Eclipse , 2006, BMJ : British Medical Journal.

[5]  Janice Singer,et al.  An examination of software engineering work practices , 1997, CASCON.

[6]  Rui Abreu,et al.  A Survey on Software Fault Localization , 2016, IEEE Transactions on Software Engineering.

[7]  Gina Venolia,et al.  The secret life of bugs: Going past the errors and omissions in software repositories , 2009, 2009 IEEE 31st International Conference on Software Engineering.

[8]  Nachiappan Nagappan,et al.  Global Software Servicing: Observational Experiences at Microsoft , 2008, 2008 IEEE International Conference on Global Software Engineering.

[9]  Thomas Zimmermann,et al.  Information needs in bug reports: improving cooperation between developers and users , 2010, CSCW '10.

[10]  Amy J. Ko,et al.  How power users help and hinder open bug reporting , 2010, CHI.

[11]  Gail C. Murphy,et al.  Automatic bug triage using text categorization , 2004, SEKE.

[12]  Marc Roper,et al.  Bug localisation through diverse sources of information , 2013, 2013 IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW).

[13]  Thomas Zimmermann,et al.  Extracting structural information from bug reports , 2008, MSR '08.

[14]  Westley Weimer,et al.  Modeling bug report quality , 2007, ASE '07.

[15]  Rahul Premraj,et al.  Do stack traces help developers fix bugs? , 2010, 2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010).

[16]  Bogdan Dit,et al.  Feature location in source code: a taxonomy and survey , 2013, J. Softw. Evol. Process..

[17]  Thomas D. LaToza,et al.  Maintaining mental models: a study of developer work habits , 2006, ICSE.

[18]  Thomas Zimmermann,et al.  Duplicate bug reports considered harmful … really? , 2008, 2008 IEEE International Conference on Software Maintenance.

[19]  Akif Günes Koru,et al.  Defect handling in medium and large open source projects , 2004, IEEE Software.

[20]  Ding Yuan,et al.  SherLog: error diagnosis by connecting clues from run-time logs , 2010, ASPLOS XV.