The two main elements based on which defect tracking and the resolution of the same can be effective are:
-> Defect Priority
-> Defect Severity
These terms are sometimes ambiguous and sometimes are used interchangeably amongst the Testing team and development team. There is a difference between “Priority” & “Severity” of the defect and it's vital to understand that difference.
Defect Priority:
Priority is generally referred to as a comparison between two things or conditions, wherein one of them should be given the utmost importance over the other one. The same happens with defects in software testing, any bug with high priority should be given importance for resolution. Priority of a defect generally indicates the urgency of the defect which needs to be fixed. Priority can be defined as the sequence in which a defect should be fixed. The higher the priority, the earlier the defect must be resolved. Those defects that leave the software unusable must be given higher priority over defects that cause a small functionality of software to fail.
Defect Severity:
Severity can be referred to as a description of the gravity or depth of undesirable occurrence. Concerning bugs, severity indicates the effect of the defect on the system in terms of impact. Severity in the context of testing is the degree/depth of impact a bug or a Defect has left on the software that is under test. The higher the effect of a bug/defect on system functionality, the higher the severity level. A tester usually determines the severity level of a bug/defect.
Who Defines Severity and Priority?
The testing team defines the defect under appropriate severity which is based on complexity and criticality of the same. Business stakeholders: The project manager, Product Owner, the Business analyst define the priority of the defect.
Classification of Priority of defect:
1) Priority 1: Critical/ Immediate (P1)
Such defects need to be fixed in 24 hours or as early as possible. Such kind of priority generally happens when the whole main functionality has been blocked and no testing can be carried out. Otherwise in other cases, if there are incidences like memory leak then P-1 is assigned to defect if the feature is unusable. Any defect or bug that needs the utmost attention and due to which main feature or the other depending features doesn’t work as expected then this kind of priority is given. All the Critical severity defects fall under this category (unless re-prioritized by business/stakeholders)
2) Priority 2: High (P2)
If the critical level defects are fixed by developers, the next solution is this kind of defect which needs to be fixed to match the exit criteria of test activity. Generally, when a feature is unusable as it’s supposed to be, for eg like due to a program defect in the software, or any new code needs to be written, or many times even due to some environmental problem that has to be handled through the code, a defect is qualified for a priority 2.
This is the defect that can be resolved before the release is made. After solving P1 defects, P2 is solved. Generally, Major severity defects fall into this category
3) Priority 3: Medium (P3)
A defect with this type of priority level must be in contention to get fixed as it can also deal with functionality issues that are not as per the expectation. Many times even cosmetic errors such as expecting the error message to pop up during the failure can qualify to be a priority 3 defect. These defects can be considered only after the resolution of Critical bugs. All Minor Severity bugs fall into the P3 category.
4) Priority 4: Low (P4)
A defect in this category denotes that there is an issue but it doesn’t need to be fixed to match the exit criteria for testing. Generally, issues such as typing errors or even cosmetic errors can be categorized here. Defects in this category can also be related to enhancement or requests to implement a small feature. It doesn’t require immediate attention and generally severity defects fall into this category.
Classification of Severity of Defect:
1) Critical/Blocker (S1)
A bug that causes complete blockage in the testing of software is a critical severity defect. For instance, login functionality does not work through entering the correct credentials or crashes of an application. In short, any defect that makes the software unusable or hampers test execution can be assigned Severity 1 level.
2) Major (S2)
Bugs related to any major functionality that is not behaving as per the business requirements or is different from expectation, then such bugs are classified as Severity 2 level. For example, in WhatsApp, if you can’t upload a status, that can be considered a Severity 2 Bug. The reason is that it has an impact on the application and all its features.
3) Moderate (S3)
Bugs related to any major functionality that is not behaving as per the business requirements or different from expectation, however, it has negligible impact on the software system to some extent or doesn’t have a major impact can be considered as Severity 3 defect.
For example, On the terms and conditions page if one of the links mentioned over there is not working then it can be declared as a Severity 3 defect.
4) Low (S4)
Any UI issues or cosmetic bugs such as alignment issues, color differences, spelling mistakes, or font size differences can be considered Severity 4 defects.
These kinds of bugs have no impact on the functionalities of the software. For example, if the border of a table on the website is grey instead of black is considered a Severity 4 defect.
Tips for testers to consider:
1) Understand and always differentiate between Severity and Priority. Also, never use those terms interchangeably.
2) Always select severity evaluating the issue.
3) Analyse how a particular scenario/ Test case can affect the end-user of software.
4) Always consider the time required to fix a defect based on the complexity of the same and the time to verify the bug.