Every error (serious discrepancy between the real and expected results of software behavior) has particular attributes: “severity” and “priority” with numerical or alphabetical values.

But not everyone can say exactly what is the difference between these two notions.

Severity corresponds more to the technical side of the matter and priority – to the managerial side.

To make this clear, we will further analyze a formal definition currently used in many standards of testing.

Dividing Priorities and Severity into Levels

Today the priorities are divided into 3 levels, and severity – into 5 levels.

[highlight dark=”no”]The bug’s priority[/highlight] is a special attribute which shows the sequence of task execution and bug fixing. Priority is marked only by a project manager or a company director.

The levels of priority:

• P1 – High – a defect must be primarily fixed;
• P2 (Medium) – it can be fixed later when a bug report contains no bugs with a high level of priority;
• P3 – Low – it’s fixed last when all the bugs with a higher level of priority have been fixed.

[highlight dark=”no”]Severity[/highlight] is a special attribute which describes the influence of a bug on the general functionality of the developed application. It is marked by a QA specialist or technical worker who can assess the influence of a bug on the general work of the tested software.

• S1 – Blocker – a bug completely blocks the execution of defined functionality and we can’t miss it. If we make an analogy with a room with a closed door, then if the door is closed and you don’t have a key to it, you will never open it and leave the room. The windows are missing and the keys are lost;
• S2 – Critical – an error blocks some part of the functionality but there is another way to overpass it. And we can make again an analogy with the room and the door: you can leave the room with the help of the window, though the door is still closed and the key has not been found;
• S3 – Major – a bug which shows incorrect work of a particular part of the developed functionality. It happens not because a particular function is not working but because it works not properly. All the same, there is more than one point of initiation of the necessary functionality. In other words, you can leave a place not using the key and the lock (a certain hole in security), with the help of ventilation (another entry point) or the door can be opened in another direction (as a result, it folds back against a corner and can be opened only to some extent – a good example of incorrect implementation of the developed functionality). The bugs that can be compared to this level of severity happen frequently.
• S4 – Minor – a bug which doesn’t actually belong to the functionality of the product. Usually, Minor severity is marked for those errors which mostly belong to the usability of the developed software (graphical interface and the logic of interaction with the front-end part). It’s usually particular grammatical errors in the technical documents of the product. Sometimes it belongs to the invisible issues from the point of view of using a product by a client. In the analogy with the room and the door – the key and a bolt are from different manufacturers, there is some noise in a room (it’s not connected with the structure of this bug).

But why should we use such division, why can’t we use only one main attribute, such as the notion of severity?

Let’s imagine that the reporting module stopped working in a particular system. It’s a bug with a nominal level of severity – Blocked.

But a client will start working with this module only at the end of the year. And now there is summer and therefore, this functionality won’t be necessary at least half a year.

As a result, a project manager easily marks the lowest priority of fixing such functionality.

Another situation: a company tagline is not properly displayed in a graphical part of a website. This bug can greatly influence the future client confidence in the company services: potential clients can suspect that the quality of company services is low since even a name of a tagline has a serious grammatical error – and completely refuse to cooperate in future.

From the point of view of approaching the software quality, even non-functional bugs with the “Trivial” severity can greatly influence the current reputation of the company. And thus, this bug will have the highest level of priority.

To sum up, we should understand that the process of marking the attributes of the priority and severity of a bug is an integral part of developing any software since the attributes clearly categorize all the bugs according to a level of their negative influence on the work of the system and the sequence of their fixing.

As a result, there is a possibility to quickly search for bugs and sort them, form clear bug reports and don’t waste time on unnecessary communication.

Mark the attributes of severity and priority correctly and may your software be in a good state and function properly!