Severity and Priority in Testing with Real-time Examples

Even if you are new to the testing field, there are fair chances, you must have heard of the term bug, quite a few times. But, in case you haven’t, let me explain what exactly it is.

The word bug is a term associated with defects or glitches in a system. When a person says, there is a bug in the system it refers to a failure, fault, or defect in the system. These cause the software to behave in a way it shouldn’t.

A bug is a very important aspect of a software testing life cycle and priority and severity are the two of the most common attributes assigned to it.

However, in my personal experience, people do get confused between the two. Or assign them incorrect values.

In this article, we will learn about the priority and severity of bugs along with real-life examples.

Severity and Priority of a Defect

Let’s check the formal definition of defect priority and severity. According to the ISTQB–

Severity means – “The degree of impact that a defect has on the development or operation of a component or system.”

Priority means – “The level of (business) importance assigned to an item, e.g., defect”.

Let us now understand both the terms in detail.

Bug Severity

Severity defines how impactful can a bug be to the system. Basically how severe it is. For example, an application crashing defect will be considered highly severe as compared to a simple spelling mistake defect.

It is divided under 4 stages – low, minor, major, and critical.

Bug Severity Levels

LOW – As the name suggests, these bugs do not harm the system in any critical way. Although they are harmless, yet valid and need to be removed.

MINOR – These bugs do affect the system in a certain manner. However, do not restrict its functioning in any way. The system might behave in an undesirable manner but does not stop the functioning of the system.

MAJOR – These bugs too do not collapse the whole system. None the less hamper major parts of it. Thus disrupting basic functions of the system.

CRITICAL – These bugs might cause the complete shutdown of the system. Or affect the application in a way that the user cannot proceed to the next task. Such bugs need immediate attention.

Bug Priority

Priority defines the urgency of fixing the bug. As an example consider a defect about the logo not getting clearly displayed. This bug is not critical from a technical point of view. Still, it would carry high priority as compared to some defects about words overlapping on non-critical pages like “about us” or “contact us” pages.

We can divide priority into 3 levels – High, Medium, and Low.

Bug Priority Levels

HIGH – Such defect needs immediate attention as it might lead to complete failure of the system. The earliest resolution of such defects should be conducted.
Delay in finding the solution might affect the system adversely. Often leading to even more complications

MEDIUM – Such bugs do not affect the working of the system. These can be solved simultaneously with the testing as well as the design phase.
These bugs do need to be fixed but do not need any immediate attention.

LOW – These bugs are at the lowest priority. These are fixed once the developer is done with the high and medium-priority bugs.

Difference between Severity and Priority

We have talked about various forms of both terms. Now, lets look at the key differences which make them distinct.

• The term severity defines, to what degree the system is impacted. Whereas, priority is all about scheduling or urgency.
  
• Usually, it is the test engineer who determines the severity. While the product owners decide the priorities of defects.
  
• It is very unlikely that the severity might change. Whereas, the priorities change from time to time.
  
• The severity is usually determined in terms of a technical point of view. Whereas, priority depends upon the user experience.
  
• The severity affects the technical working of the system. Whereas the latter affects business.
  
  

Severity and Priority Real-time Examples

The priority and severity are combined in four different ways to determine which defect needs immediate attention and which one the least.  Let’s look at some real-time examples to make this concept even clearer.

High Priority and High Severity Examples

1. The products added to the cart of an e-commerce website are not visible on the payment page.
2. The login button of the application is not working.
   
   

High Priority and Low Severity Examples

1. The logo of the company’s welcome page is distorted.
2. The action buttons are not visually appealing or the information on the page appears hazy.
   
   

Low Priority and High Severity Examples

1. If the application is crashing on passing very large input for processing (which is very rarely done).
2. There are some buttons on the website which are overlapping. Although clickable, are creating a fuss.
   
   

Low Priority and Low Severity Examples

1. A spelling mistake on the page of the site which is not frequently visited.
2. The color of any text does not match the theme of the website.
   
   

Conclusion

In a nutshell, it can be said that knowing the difference between bug priority and severity is equally important as knowing the other aspects of testing.

Be it manual testing or automated, a tester can only log bugs effectively, if and only if the nature of the bugs is known.

I hope you will keep all these points in mind and are now clear with these concepts.