What makes a good bug report?

Bettenburg, Nicolas; Just, Sascha; Schröter, Adrian; Weiß, Cathrin; Premraj, Rahul; Zimmermann, Thomas

doi:10.1145/1453101.1453146

Cited by 455 publications

(289 citation statements)

References 33 publications

Supporting

Mentioning

281

Contrasting

Unclassified

Order By: Relevance

“…While user ranked incompleteness of the initial report as a comparatively less frequent reason, analysts consider it as the most frequent reason. It highlights the difference between the expectations of analyst and of the user [11]. Reasons 3 and 4 in Q4 (refer to Table 4) support the observation of having Awaiting User Inputs as a subsequent state after User Inputs Received in Fig.…”

Section: Survey Of Users and Analystsmentioning

confidence: 54%

See 1 more Smart Citation

Reducing user input requests to improve IT support ticket resolution process

et al. 2017

View full text Add to dashboard Cite

Management and maintenance of IT infrastructure resources such as hardware, software and network is an integral part of software development and maintenance projects. Service management ensures that the tickets submitted by users, i.e. software developers, are serviced within the agreed resolution times. Failure to meet those times induces penalty on the service provider. To prevent a spurious penalty on the service provider, non-working hours such as waiting for user inputs are not included in the measured resolution time, that is, a service level clock pauses its timing. Nevertheless, the user interactions slow down the resolution process, that is, add to user experienced resolution time and degrade user experience. Therefore, this work is motivated by the need to analyze and reduce user input requests in tickets' life cycle.To address this problem, we analyze user input requests and investigate their impact on user experienced resolution time. We distinguish between input requests of two types: real, seeking information from the user to process the ticket and tactical, when no information is asked but the user input request is raised merely to pause the service level clock. Next, we propose a system that preempts a user at the time of ticket submission to provide additional information that the analyst, a person responsible for servicing the ticket, is likely to ask, thus reducing real user input requests. Further, we propose a detection system to identify tactical user input requests.To evaluate the approach, we conducted a case study in a large global IT company. We observed that around 57% of the tickets have user input requests in the life cycle, causing user experienced resolution time to be almost twice as long as the measured service resolution time. The proposed preemptive system preempts the information needs with an average accuracy of 94-99% across five cross validations while traditional approaches such as logistic regression and naive Bayes have accuracy in the range of 50-60%. The detection system identifies around 15% of the total user input requests as tactical. Therefore, the proposed solution can efficiently bring down the number of user input requests and, hence, improve the user-experienced resolution time.

show abstract

Section: Survey Of Users and Analystsmentioning

confidence: 54%

“…Bettenburg et al [11] conducted a survey on developers and users from Apache, Eclipse, and Mozilla to identify the information that makes good bug reports. Further, they designed a tool Cuezilla that provides feedback to the user at the time of ticket reporting for enhancing bug quality.…”

Section: Information Needs In Software Engineeringmentioning

confidence: 99%

Reducing user input requests to improve IT support ticket resolution process

et al. 2017

View full text Add to dashboard Cite

show abstract

“…Bettenburg et al [22] perform a survey with developers from Apache, Mozilla, and Eclipse, asking them what information is important in a bug report description, and what information is frequently absent from bug reports. Developers agree that steps to reproduce and stack traces are the most important information.…”

Section: Related Workmentioning

confidence: 99%

Modelling the ‘hurried’ bug report reading process to summarize bug reports

2014

View full text Add to dashboard Cite

Abstract-Although bug reports are frequently consulted project assets, they are communication logs, by-products of bug resolution, and not artifacts created with the intent of being easy to follow. To facilitate bug report digestion, we propose a new, unsupervised, bug report summarization approach that estimates the attention a user would hypothetically give to different sentences in a bug report, when pressed with time. We pose three hypotheses on what makes a sentence relevant: discussing frequently discussed topics, being evaluated or assessed by other sentences, and keeping focused on the bug report's title and description. Our results suggest that our hypotheses are valid, since the summaries have as much as 12% improvement in standard summarization evaluation metrics compared to the previous approach. Our evaluation also asks developers to assess the quality and usefulness of the summaries created for bug reports they have worked on. Feedback from developers not only show the summaries are useful, but also point out important requirements for this, and any bug summarization approach, and indicates directions for future work.

show abstract

“…Bettenburg et al studied the impact of social structure on software quality and find a statistical relation between communication flow between developers and users and post-release defect [6]. Abreu et al investigated the Eclipse project and found a statistically significant positive correlation between communication frequency between developers and number of injected defects in the software [1].…”

Section: Impact Of Collaboration On Software Developmentmentioning

confidence: 99%

Impact of Stakeholder Type and Collaboration on Issue Resolution Time in OSS Projects

Duc¹,

Cruzes²,

Ayala³

et al. 2011

IFIP Advances in Information and Communication Technology

View full text Add to dashboard Cite

Abstract. Born as a movement of collective contribution of volunteer developers, Open source software (OSS) attracts an increasing involvement of commercial firms. Many OSS projects are composed of a mix group of firmpaid and volunteer developers, with different motivation, collaboration practices and working styles. As OSS is collaborative work in nature, it is important to know whether these differences have an impact on project outcomes. In this paper, we empirically investigate the firm-paid participation in resolving OSS evolution issues, the stakeholder collaboration and its impact on OSS issue resolution time. The results suggest that though a firm-paid developer resolves much more issues than a volunteer developer does, there is no difference in issue resolution time between firm-paid and volunteer developers. Besides, the more important factor that influences the issue resolution time comes from the collaboration among stakeholders rather than from measures of individual characteristics.

show abstract

What makes a good bug report?

Cited by 455 publications

References 33 publications

Reducing user input requests to improve IT support ticket resolution process

Reducing user input requests to improve IT support ticket resolution process

Modelling the ‘hurried’ bug report reading process to summarize bug reports

Impact of Stakeholder Type and Collaboration on Issue Resolution Time in OSS Projects

Contact Info

Product

Resources

About