Severity Assessment of a Reported Bug by Considering its Uncertainty and Irregular State

Severity Assessment of a Reported Bug by Considering its Uncertainty and Irregular State

Madhu Kumari (Delhi College of Arts and Commerce, University of Delhi, New Delhi, India), Meera Sharma (Swami Shraddhanand College, University of Delhi, New Delhi, India) and V. B. Singh (Delhi College of Arts and Commerce, University of Delhi, New Delhi, India)
Copyright: © 2018 |Pages: 27
DOI: 10.4018/IJOSSP.2018100102

Abstract

An accurate bug severity assessment is an important factor in bug fixing. Bugs are reported on the bug tracking system by different users with a fast speed. The size of software repositories is also increasing at an enormous rate. This increased size often has much uncertainty and irregularities. The factors that cause uncertainty are biases, noise and abnormality in data. The authors consider that software bug report phenomena on the bug tracking system keeps an irregular state. Without proper handling of these uncertainties and irregularities, the performance of learning strategies can be significantly reduced. To incorporate and consider these two phenomena, they have used entropy as an attribute to assess bug severity. The authors have predicted the bug severity by using machine learning techniques, namely KNN, J48, RF, RNG, NB, CNN and MLR. They have validated the classifiers using PITS, Eclipse and Mozilla projects. The results show that the proposed entropy-based approaches improves the performance as compared to the state of the art approach considered in this article.
Article Preview
Top

1. Introduction

In the software maintenance process, the essence of bug resolution is widely accepted. With increase in number of software and their intricacies, a large number of bugs are generated in the software development process. A software bug is a failure or defect in the program that may generate unwanted or incorrect results. It is the deviation from the desired results. The main reason for occurrence of bugs may be (i) errors generated by programmers (ii) incorrect understanding of the requirements (iii) incorrect implementation of the requirements and (iv) miscommunication between programmers and requirement analysis team/users/customers. Bug tracking systems are adopted by various open source and commercial software projects. These bug tracking systems effectively maintain the huge data about bugs reported by different users. This bug data is analyzed by bug triager to resolve different bugs. Triager is the person who analyzes and refines the bugs by using his knowledge and experience. This process is known as bug triaging. Bug triaging is an important part of the bug resolution process. The two main tasks of bug triaging are bug severity identification and fixer assignment (Zhang et al., 2016). Bug severity indicates the impact of the bug on the functionality of the software or its components. In bug repositories, severity is labeled as “blocker”, “critical” and “major” representing high severity bugs. Low severity bugs are represented by “minor” and “trivial” severity labels (Yang et al., 2014). Severity labels “normal” and “enhancement” represents improvements in existing features of the software. Triager reads a bug report to understand the details of the bug and verifies whether the labeled severity level is correct or not. This process is known as “severity identification”. There is a clear guideline to assign a severity level to a reported bug. But, due to lack of awareness, people make mistakes to define the level of severity at the time of bug reporting (Chaturvedi& Singh, 2012a). Manual identification and verification of bug severity is a tedious and time-consuming task. In order to correctly identify the severity of a bug we need to automate the process of severity prediction (Roy & Rossi, 2014). Mozilla and Firefox define the seven levels of severity, namely blocker, critical, major, normal, minor, trivial and enhancement from 1to 7 in terms of numerical value. In case of NASA projects, five levels of severity are defined from 1 to 5. The value 1 represents the most serious bug whereas the value 5 shows cosmetic changes or messages. In this study, we have not considered bugs with normal and enhancement severity levels since normal is the default level specified in submitted reports and enhancement do not represent real bug reports.

IEEE Standard Classification Levels have fixed the severity weights and levels into different severity categories as mentioned in Table 1 (IEEE std 92, 1989).

Table 1.
Different categories of severity levels
From the IEEE Standard Severity Classification LevelsSeverity WeightSeverity Level
Blocker, Critical10Most Severe
Major3Medium
Minor, Trivial1Minor

Complete Article List

Search this Journal:
Reset
Open Access Articles
Volume 11: 4 Issues (2020): Forthcoming, Available for Pre-Order
Volume 10: 4 Issues (2019)
Volume 9: 4 Issues (2018)
Volume 8: 4 Issues (2017)
Volume 7: 4 Issues (2016)
Volume 6: 1 Issue (2015)
Volume 5: 3 Issues (2014)
Volume 4: 4 Issues (2012)
Volume 3: 4 Issues (2011)
Volume 2: 4 Issues (2010)
Volume 1: 4 Issues (2009)
View Complete Journal Contents Listing