Cruel Preeminence - severity and priority in software development

Order of impacts

The meaning of severity and priority is often confused not only by the development team but by project management and clients as well. There is a fine line between these two and it is important to use them correctly.

To put it simply, think about severity as an impact and priority as an order, or succession.

Severity is a parameter that can express the impact of a particular defect on the software in development and how it is affecting the functionality of the application. A higher effect on the system functionality will lead to the assignment of higher severity of the bug. 

When it comes to categorizing the severity of the defects, there is a basic 4-point scale:

• Critical (blocker) - a serious problem that blocks progress; testing or development;
• Major - has the potential to affect progress;
• Minor - a problem that can be easily worked around;
• Trivial (low) - a trivial problem with little or no impact on progress.

Categorizing severity is associated with functionality or standards. It is mostly QA engineers who determine the severity of the defect - the value is objective and rarely changes, as the functionalities tend to stay the same. For instance, a defect of the checkout or payment in the e-commerce website will always have the same (high) severity, and it will not change along with the progression of development.

On the other hand, there is a priority - the parameter that determines which defects should be fixed first and how fast we should get rid of them. Defects that leave the software system unusable are given higher priority over defects that cause a small functionality of the software to fail.

Categorizing priority uses a 3-point scale:

• High - the defect must be resolved “as ASAP as possible”, as it seriously affects the system and could render it unusable,
• Medium -  the defect should be resolved after high priority issues had been dealt with. Should be fixed before next release,
• Low - the defect can be resolved after higher priority tasks, as it does not need immediate attention.

Prioritizing defines the order in which the development team should resolve a defect. Contrary to severity, priority is set by the project management or customer itself, as it is driven by the business value and requirements. 

Wondering how PMs prioritize tasks? Check Radek’s article about prioritization in web projects

The status can change over time - as the development progresses, some tasks can change their priority - after higher priority tasks have been resolved.

Cruel preeminence criss-cross

Most people would say that defect with high severity will have high priority as well. Usually, it is true, but it is not always the case. There are plenty of issues that can be given a high priority and low severity at the same time and vice versa.

This graph should help you visualize the concept: 

Let us start with the obvious - high priority, critical severity. It is an issue that occurs on the basic or key functionality of the application, and it will not allow the user to use the system - for example - changing the amount of money after transaction without actually processing the transaction itself in the banking application.

Another classic cross, and also the other one that covers the “priority is basically severity” stereotype, is an issue with low priority and trivial severity. Using the wrong font in the rarely visited part of the application would not be a big problem (unless it is comic sans), and can wait a bit for a chance to be fixed, as it will not affect using the core functionalities of the application.

Less obvious - high priority, trivial severity like a misspelt company name on the company web page. It may not be hard to process but should be fixed as soon as possible, as such mistake could make the company lose customers (not everyone would like to develop their dream application with a company called “Mirexstudio”), or even appear as a fake or phishing website.

Also, a minor bug that occurs frequently can also get higher priority, as it affects user experience - a pop up that should appear only once per visit can be a real issue if it is triggered on every subpage.

Low priority, critical severity is a tricky one, but the easiest way to describe such an issue is the example of using legacy browsers or old mobile devices that will not cooperate with or support modern technologies and frameworks, therefore rendering them unusable. However, since we’re talking about outdated software and hardware, there is a major chance that it will not affect the end-user at all, so it may be considered as a low priority task.

Taking all that into consideration, let us take a look at this quick key differences cheat-sheet:

SeverityPriority Impact of the defect Order of work Determined by QA Determined by PM Driven by functionality Driven by business value Does not change Can change depending on the progress High severity and low priority means that issue needs to be fixed, but not immediately High priority and low severity means that issue needs to be fixed immediately, but the application is usable

Before you will call the shots

In the development process, the selection of both severity and priority has a great impact on the overall performance of the team and understanding the concept of both is crucial. Assigning wrong levels can destabilize the work of developers and shift attention from tasks with greater impact. Proper use of prioritization and severity helps to organize the work in agile methodologies and plan ahead in terms of future releases. 

Looking for a proper place to raise your QA skills and share the knowledge with experienced testers - check our job offers an join our team!