Characterization Study of Developers in Non-Reproducible Bugs

Software bugs are inevitable. Increasing size and complexity of software systems makes bug handling a cumbersome and time-consuming task. In such scenarios, Non-Reproducible (NR) bug reports are an additional overhead for software developers as these bugs are hard-to-reproduce. This difficulty in reproducing NR bugs is due to varied reasons such as the absence of information required to create the same test environment, resource and time constraints, inability of the assigned developer to fix the issue, etc. However, when NR marked bug reports are reconsidered, a few percentages of these bug reports get Fixed (NRF). This fixation occurs either due to the trial of new solutions to reproduce the bug or due to the assignment of a different developer for the bug report. To find whether a change in developer helps in resolving NR bugs, this paper investigates the developers associated with NR bug reports. We gauged developer similarity (in terms of developer marking bug report as NR and Fix), tossing trends, presence of isBack and expertise level of developers who marked NRF bug reports as NR and Fix. We studied the change history of 24, 995 NR bug reports of Mozilla Firefox project. Our results show that 87.34% NRF bug reports are fixed by a developer who had not marked the bug report initially as NR. Also, we found that average tossing path length in NRF bug reports is three times higher than tossing path length in NR bug reports. This higher rate of bug tossing results in higher fixation probability of NR bug reports. It has also been observed that developers who fix NR bugs possess higher expertise than developers who marks bug reports as NR.