Assuming you are involved in assessing bugs in your organization, how do you define the different severity levels of these bugs? What criteria do you use to assign priority values for bugs?
When a bug is discovered and created, there are generally 2 fields: Severity and Priority. These 2 concepts are often confused. However, there are essential differences between them. In this article, we will define each term and its levels.
What’s a bug?
Bug, error, anomaly, defect, failure, bad behaviour and so on. These terms are often used synonymously to indicate that the system or an application acts abnormally. In the first section, we are going to discuss the difference between all these terms.
According to ISTQB CFTL “A person can make an error (mistake), which can lead to the introduction of a defect (fault or bug) in the software code or in some other related work product“
Error/mistake:
Error is a human action to make it easier The mistake made by the programmer is known as an ‘Error’. This could happen, for example, because of Some confusion in understanding the requirement of the software
Bug/fault/defect
A bug is the informal name of a defect, which means that software or application is not working as per the requirement. When we have some coding error, it leads a program to malfunction, which is known as a bug.
Failure
Failure is a deviation of the software from its intended results. It is the inability of a system or a component to perform its required functions within specified performance requirements. Failure occurs when fault executes.
Severity & Priority
In the second section, we will go through this article’s main subject, the classification of bugs based on Severity and Priority.
Severity
The severity of the bug must be identified based on the technical impact of the defect on the system.
S1- Critical Bugs: The bug blocks critical functionality or even causes a website crash. There is no way around this bug.
S2- Major Bugs: The bug hinders less critical but important functionality, and there are a way or several ways to work around it.
S3- Minor Bugs: The bug affects minor functionality, and it’s easy to work around.
Priority
The priority of bug fixes depends on their business impact. And it’s defined by the Product Owner or the stakeholders.
P1-High: The bug should be fixed as soon as possible.
P2-Medium: The bug fix can wait for a short while.
P3-Low: The bug fix can wait longer.
Conclusion
Basically, you need two things to classify a bug;
Severity: Is this a critical bug? Or less critical, like a cosmetic error.
Priority: How urgent is a solution?
The severity of the bug has clear technical explanations. It is guided by the aspects of website behaviour.
Priority is given to the Product Owner or Project Manager. This is a very subjective definition and is often tied to current circumstances, project budget, customer requirements and expectations.
Software QA engineer, blogger |ISTQB®|SMC™
Leave a Reply