5 Common Severity Levels of Software Bugs

by Nataliia Vasylyna | March 10, 2015 10:00 am

Updated in January 2021.

Have you ever wondered about the average number of bugs detected during the process of software testing? According to the book Code Complete by Steve McConnell, the number of bugs in an average code varies from 15 to 50 per 1,000 lines of code. The data provided by Statista show that 21% of all bugs reported in the process of software testing are fixed immediately. How to decide which of them require immediate fixing and which can wait for better days? Read the article to get a background for your decision.

Severity Levels of Software Bugs

Logged defects are characterized by several attributes[1]. In order to quickly sort the defects and deal with them, you should determine to which aspect of the program they belong, which defects need urgent fixing, and which ones may be corrected later.

Severity is one of the most important software bugs attributes. It can be of several types:

Blocker is a type of a bug that blocks further testing because the app or software crashes in a specific environment due to the bug.

Critical error is connected with security and leads to the program shutdown, data loss or other serious damage. Such bugs disable the app’s main functionality and are primarily fixed.

Major level of severity is assigned to a bug which negatively affects large areas of the software checked through certain types of testing. For example, in case of localization testing, bugs of major severity can be non-displayed letters, systematic omissions of spaces, text going beyond the screen bounds, untranslated text, etc.

Minor error does not influence the app’s basic functions or the process of testing. This type of a bug happens when, for instance, the text does not fit in a separate bar, there is incorrect hyphenation, a missing space in a particular place, etc.

Bugs of low severity level have little impact on the program functioning. They are generally found in the course of user interface testing[2]. A low severity level bug may be the wrong size of a button, too-bright color of an object and so on. 

[3]

Severity vs Priority: How they match

Novice testers sometimes wonder what the procedure of bug fixing is and how developers decide what errors should be corrected first. Here, the notion of priority arises. Bug-tracking tools such as Jira define the following levels of bugs priority:

These levels do not always coincide with the severity division. Bugs can be of:

• high priority, blocker severity (e.g. the page is not displaying);
• medium priority, major severity (e.g. the submission button does not work);
• critical severity, high priority (e.g. log-in field is missing);
• low severity, lowest priority (e.g. the wrong color of the submission button).

The combinations of these two levels are not restricted to those mentioned above and can vary depending on the product specifics and workloads of the employees involved in the project. Effective organization of cooperation between developers, QA, and technical specialists is one of the ways to make the workflow transparent[4] and avoid risks connected with the bugs assignment and prioritization.

Final Thoughts on Bug Severity Levels

The qualification of QA specialists depends, among other things, on their skill to correctly document the process and results of bugs analysis. It is a basic competence which is often taken for granted. Defining the true level of error severity is something every tester should know how to do. This article is here to provide you with the basics of determining bug severity levels if you are new to QA and to help you refresh your knowledge on this topic if you need it at any point.

Related Posts:

• How bugs impact your business. With real-life examples[5]
• Assessing Bug Priority and Severity[6]

Source URL: https://blog.qatestlab.com/2015/03/10/software-bugs-severity-levels/

---