Article Preview
Top1. 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 Levels | Severity Weight | Severity Level |
| Blocker, Critical | 10 | Most Severe |
| Major | 3 | Medium |
| Minor, Trivial | 1 | Minor |