_edited_edited.png)
Bug is the most buzzing entity of Software Testing Life Cycle. After all, the main goal of a tester is to ensure and deliver a bug-free product. Bug is a flaw in the software that can cause it to fail to perform its required functions.
Bug Severity and Bug Priority are the most important attributes that can be assigned to a bug. While testing a software, testing team finds and logs many defects and managing these defects can be a daunting task. As part of defect management process, testers need to provide many details related to bug like description, steps to reproduce the bug, expected and actual output, system configurations etc. But Severity and priority of bug are the fields that help categorize the defects. The process of categorizing the defect into priority and severity is known as Defect Triage.
Many times severity and priority are used interchangeably, which is not correct. In this blog, we will understand more about each, their differences with examples and more.
Severity refers to the impact that a defect has on application's functionality.
Severity measures how severe the issue is and how critical is to fix it. Severity is decided by a tester. On the basis of the impact, Severity can be categorized as -
Critical (S1) - A defect that completely blocks the testing of the application is a Critical defect. If the application is down or a functionality is inaccessible, it is Critical severity defect and needs to be fixed immediately. For eg - User is not able to login even after providing correct credentials, means the whole application is inaccessible to the user.
Major (S2) - When a bug is not impacting the whole application but impacting a significant functionality from working as expected, it is categorized as Major Severity. Eg - User is not able to transfer money to new beneficiaries. This is a Major severity defect as user is able to transfer money to old added beneficiaries and able to add new ones.
Minor (S3) - When there is an unexpected behavior in some of the functionalities, but not enough to disrupt the system function, its a Minor severity bug. For eg - User is not able to download a help document, but they are able to read it online.
Low (S4) - Any cosmetic defects that don't impact any application functionality are Low severity defects. For eg - any spelling mistakes. Even though they don't the functionality but need to be fixed.
Priority refers to urgency of fixing a defect.
It is about prioritizing a defect based on business needs and its severity. Priority is initially set by a tester while logging the defect. But it is later reevaluated by the product owner subjected with other defects. Priority determines which defect needs to fixed immediately and what can be picked up later. Below are the categories for defect priority -
Immediate (P1) - Any defect that needs immediate attention and needs to be fixed within next 24 hours is a P1 defect. For eg - When application functionality is blocked and testing can't proceed then it needs to be fixed immediately. Any Critical severity defect is a P1, unless reevaluated by business owners.
High (P2) - These are defects which have to be fixed for any test to match the 'exit' criteria and before a release is made. These are fixed after the P1s.
Medium (P3) - Defects which don't affect business or customers get Medium priority. They are fixed when development team has the bandwidth, and can even go to the next release.
Low (P4) - These defects are picked up after all high and medium priority bugs are fixed. The fixes for these defects usually go with fixes of P2s and P3s. P4s don't have to fixed to match the 'exit' criteria and sometimes these defects are raised to suggest a some enhancement or a small feature to improve user experience.
After looking at these classifications, it is also clear that a critical severity defect will not necessarily be a immediate priority one, and a low severity one will have to be picked up first to fix. Let us look at few of such examples.
It is quite typical to have defects with high severity, high priority and low severity, low priority. But finding examples for high severity, low priority and low severity, high severity can be difficult to judge sometimes. Below are few of such examples -
High Severity, Low Priority -
Application crashes after clicking on a remote link
Application not working on few older versions
etc.
Low Severity, High Priority -
A spelling mistake in website name on main page on some browsers.
Company logo not loading properly
etc.
Severity vs Priority
Severity | Priority |
|---|---|
Impact on a specific functionality | Impact on business |
Categorized by Testers or end users | Categorized by product owners or developers |
Deals with technical aspects of the appplication | Deals with order of fixing the defect |
Fixed value | Subjective to other defects at that time |
Conclusion
Classifying a bug with proper severity and priority is really essential. While logging any defects, it is a tester's responsibility to assign right value of severity to the defect, which further decides the priority as well. They should be well aware about the significance of each of these terms. This directly impacts the whole STLC and SDLC. Proper triage is the key for a good Testing.