Empirical Studies on Reducing Developers' Effort Spent on Resolving Software Issues

Abstract

Software issue resolving process is one of the most frequent maintenance activities during the software development process. An issue tracking system (ITS) is often used to better manage the software issues. However, previous research work has shown that the issue resolving process needs development teams to put a large amount of effort to address the reported issues. When developers raise questions to clarify the description of issue reports during the issue resolving process, it takes time for developers to receive the response for the questions. Hence, the raised questions may negatively affect the efficiency of the issue resolving process. Moreover, a large proportion (e.g., 80% in Firefox) of the reported issues are rejected (e.g., the issue is not reproducible). The issue reports might exist in the ITS for a long time before they are rejected (e.g., over 50% of rejected issue reports are rejected after 6.73 days in Firefox). Even though these reports are rejected eventually, developers must have wasted valuable resources on triaging, inspecting and rejecting such reports.

In this thesis, we conduct two empirical studies to reduce the effort spent on the software issue resolving process. In the first study, we investigate how the process of resolving issues is impacted by the questions raised from the issue reports in the resolving process and apply machine learning techniques to predict if developers will raise questions from a new issue report. Our prediction result can give developers an early warning whether questions will be raised when the issue report is created. Developers can take proper actions to handle the issue reports that are likely to have questions raised, in order to improve the effectiveness of the issue resolving process. In the second study, we investigate the characteristics of issue reports that can be rejected by developers in the resolving process. We propose to prioritize the valid issue reports at higher positions and the predicted rejected issue reports at lower positions so that developers can put more effort on the valid issue reports.