In best practices
Bugs priority & severity. Time to stop the guessing game.
We assume that at the beginning of a career path, each tester asked these strange questions. How do I describe this bug correctly? High major? ASAP minor? When is ASAP, for God's sake? What if I set critical, and then it turns out that the bug is non-critical? Who am I to judge? Who the hell stole my cold coffee?
Let's try to clear up all (almost all) the matter in today's article.

A bug is a mismatch between the actual and expected behavior of the system. Each bug has its attributes: "Severity" and "Priority". Sometimes, when describing a bug, a tester cannot correctly set these parameters, since the difference between them is not always clear. We suggest you look at the formal definitions that are currently accepted in testing standards and are used everywhere. For a start, let's define that severity refers to the technical side of the issue, and priority – to the managerial.
The priority, like the severity of the bug, is subdivided into several levels. The number of levels depends mainly on the bug-tracking software that is used on the project. Sometimes a company has a traditional bug distribution system.

So, what's a bug's severity? This is an indicator of how crucial a bug is.

The severity is an attribute that characterizes the effect of a bug on the whole system performance. Usually, this attribute is set by the tester, as the tester can immediately understand how much the bug affects the entire system.

What are the severity levels of the bug? Let's take a look at the most common ones.
The priority, like the severity of the bug, is subdivided into several levels. The number of levels depends mainly on the bug-tracking software that is used on the project. Sometimes a company has a traditional bug distribution system.

So, what's a bug's severity? This is an indicator of how crucial a bug is.

The severity is an attribute that characterizes the effect of a bug on the whole system performance. Usually, this attribute is set by the tester, as the tester can immediately understand how much the bug affects the entire system.

What are the severity levels of the bug? Let's take a look at the most common ones.
Blocker.
A typical "blocker" situation is mainly like that:
"Kowalski, status report!"
"It's gone. We're screwed."
The website is down. The application is down. The project manager lies down and cries. It means something is blocking the whole system performance and set the business on fire.

It's important to correctly estimate the value of "blocker". For example, the tester checks the Wish List option of one of the web stores. Suddenly it turns out that it is impossible to add an item to the Wish List, but the remaining important parts of the web store work as expected. Remember that it is not necessary to assign a blocker status to a bug just because one test case is impossible to pass. This bug does not block the entire system, although it prevents the test case normal completion.
Critical.

The bug leads to large-scale disaster.

For example data leakage, confidential information disclosure, a failure in the essential application functionality, etc.

It means we're still screwed, but at least partially.
Major.

The bug brings serious inconvenience to many users during their typical activities.

For example: pasting from the clipboard is not available, conventional keyboard shortcuts do not work, or a user needs to restart the application when performing typical work scenarios.

It means we fix it and nobody dies.
Medium.

The bug has little effect on typical user scenarios, or there is a workaround to achieve the desired result. For example, the dialog box does not close automatically after pressing the "OK" / "Cancel" buttons, or the value of the "Duplex printing" field is not saved when printing several documents in a row, or there is a confusion in sorting one of the table columns.

It means we'll fix it if nothing more awesome happens.
Minor.

The bug is rarely detected by a small percentage of users and (almost) does not affect their work. For example, there is a typo in one of the minor tabs of the settings menu, or one of the application windows is inconveniently displayed on the screen (the user has to drag it to a convenient place), or the estimated time of the file copy operation is displayed incorrectly.

It means we'll fix it in a month of Sundays.
Critical.

The bug leads to large-scale disaster.

For example data leakage, confidential information disclosure, a failure in the essential application functionality, etc.

It means we're still screwed, but at least partially.

Major.

The bug brings serious inconvenience to many users during their typical activities.

For example: pasting from the clipboard is not available, conventional keyboard shortcuts do not work, or a user needs to restart the application when performing typical work scenarios.

It means we fix it and nobody dies.

Medium.

The bug has little effect on typical user scenarios, or there is a workaround to achieve the desired result. For example, the dialog box does not close automatically after pressing the "OK" / "Cancel" buttons, or the value of the "Duplex printing" field is not saved when printing several documents in a row, or there is a confusion in sorting one of the table columns.

It means we'll fix it if nothing more awesome happens.

Minor.

The bug is rarely detected by a small percentage of users and (almost) does not affect their work. For example, there is a typo in one of the minor tabs of the settings menu, or one of the application windows is inconveniently displayed on the screen (the user has to drag it to a convenient place), or the estimated time of the file copy operation is displayed incorrectly.

It means we'll fix it in a month of Sundays.

Priority.
The priority attribute indicates how quickly the bug should be fixed. Usually, this attribute is set by the project manager.

There are several levels of priority that are most often used on projects.

The highest (ASAP, as soon as possible). The bug needs to be fixed as quickly as possible. Depending on the context, "as soon as possible" can vary from "in the next build" to "right this instant".
High.

The bug should be fixed out of turn, because its existence either objectively interferes with the application performance, or will interfere in the very near future.
Normal.

The bug should be fixed in order of priority. This parameter is assigned to most bugs.
Low.

This bug fix will not have a significant impact on the quality of the product in the nearest future.
Priority.
The priority attribute indicates how quickly the bug should be fixed. Usually, this attribute is set by the project manager.

There are several levels of priority that are most often used on projects.

The highest (ASAP, as soon as possible). The bug needs to be fixed as quickly as possible. Depending on the context, "as soon as possible" can vary from "in the next build" to "right this instant".
High.

The bug should be fixed out of turn, because its existence either objectively interferes with the application performance, or will interfere in the very near future.
Normal.

The bug should be fixed in order of priority. This parameter is assigned to most bugs.
Low.

This bug fix will not have a significant impact on the quality of the product in the nearest future.
But why do we need all these levels?
Is it possible to use only one attribute, for example, severity? Well, if you are working on a small project and there are not so many errors, then you can use any one distribution system. But for large projects, the combination of these attributes in the bug description is very important.
But why do we need all these levels?
Is it possible to use only one attribute, for example, severity? Well, if you are working on a small project and there are not so many errors, then you can use any one distribution system. But for large projects, the combination of these attributes in the bug description is very important.
Let's assume you found a major issue in the reporting module.
This is a defect with a critical severity level. However, you'll need this module at the end of the year only. If it's summer, then this functionality will not be used for a few more months. As a result, the project manager or decision maker may assign a low priority to a bug. So this bug is "Critical Low".

Here's one more example. The company logo disappears from the main page. And now, instead of a super-pricey design solution, there is a chief executive meme face. God knows how this picture got there, but that's not the point right now. Changing the logo is unlikely to affect the operation of the entire system. Therefore, the tester will identify this bug as minor. But such an issue can affect the company's reputation seriously. It is necessary to solve the problem as soon as possible because removing the screenshots from the Reddit will be really problematic. So this bug is "Minor ASAP".
Let's assume you found a major issue in the reporting module.
This is a defect with a critical severity level. However, you'll need this module at the end of the year only. If it's summer, then this functionality will not be used for a few more months. As a result, the project manager or decision maker may assign a low priority to a bug. So this bug is "Critical Low".

Here's one more example. The company logo disappears from the main page. And now, instead of a super-pricey design solution, there is a chief executive meme face. God knows how this picture got there, but that's not the point right now. Changing the logo is unlikely to affect the operation of the entire system. Therefore, the tester will identify this bug as minor. But such an issue can affect the company's reputation seriously. It is necessary to solve the problem as soon as possible because removing the screenshots from the Reddit will be really problematic. So this bug is "Minor ASAP".
Let's sum up.

Attributes classify all the bugs by type: the degree of influence on the system and the fixing sequence. It is very important to remember that assigning different statuses to bugs is an important part of developing and testing software products. Assigning the correct statuses to bugs allows you to quickly search or sort in a bug-tracker, and generate informative reports without wasting your valuable time.

So let's stop playing this endless guessing game and set the bug's attributes correctly. Long live the system!

Kowalski, next article!

We love what we do and do it with pleasure.
QA Camp team

You may also like: