Target Audience: All beautiful people on this planet.
(it may help us in categorizing and prioritizing our daily life problems and tasks)
“Most of us spend too much time on what is urgent and not enough time on what is important.” – Stephen R. Covey
Determining the relative importance of the problems you find is an essential step in the quality assurance process.
Identifying and assigning Priority and Severity of defects are often a confused concept and are almost used interchangeably amongst not only testing teams but also development teams. There’s a thin line between the two and it’s important to understand that there are indeed differences between the two.
Different teams and different organizations are going to have different ways of approaching prioritization; Let’s outline a maneuver that is simple and consistent, and able to handle across-the-board circumstances.
What is Defect Severity?
Severity by the English definition is used to describe the gravity of an undesirable occurrence. Hence when it comes to bugs, the severity of a bug would indicate the effect it has on the system in terms of its impact.
The Bug severity specifies how considerable effect a bug is having on the application. Severity takes different values depending on the immensity of the impact/failure the defect us causing. It’s the first step is to determine the scope or extent of the problem — how much of the site is affected? How many pages are broken? How important is the broken functionality?
Classification of Defect Severity:
1. BLOCKER (also known as Show-stopper):
Anything which is stopping QA to test the further application with no workaround is marked as BLOCKER.
Ex:
a). 503 Service unavailable error.
b). Memory leak issue, due to which system crashes after every 5-10 minutes.
c). Database connectivity failure
2. MAJOR:
“Important functionality is unavailable with no workaround”
Ex:
a) The payment system is not working fine, but a person can at least search a product and add it to a cart for future reference.
b) Profile update functionality is not working.
3. NORMAL:
“Important functionality is unavailable but has a reasonable workaround”
and
“Secondary functionality is unavailable and has no workaround”
Ex:
a) Cart update feature is not working. (User has a workaround for the same, he can remove or add products)
b) Reset password link gets expired in 5 minutes instead of 20 minutes.
4. MINOR:
“Secondary functionality is unavailable but has a reasonable workaround”
Ex:
a) Mobile number field is an optional field, But the application is forcing the user to put one.
b) Mouse hover on Drop-downs is not working fine, User needs to click on the Menu item in order to see the drop-down items.
5. COSMETIC: (also known as Trivial)
“Look and Feel Issues or a Typo in the application”
Ex:
a) Spelling mistake on a Web page.
b) Colors of sections are not meeting with what mentioned in the requirement.
c) Loading image is not getting displayed properly.
Who manages severity assignments?
I strongly believe that the quality assurance team should manage severity assignments for reported problems. The QA team will tend to log most of the problems, so they need to be careful and straight from the shoulder in their assessment of severity. Do not give anybody the chance to use thoughtless severity assignments against your QA methodology.
The QA team should also review bugs logged by people outside the team, checking for accuracy, validity, reproducibility, and of course severity. If you do revise somebody’s severity assignment on a bug, be sure to notify them and explain the reason for the reassignment.
Feeling bored? So, Before moving to the Priority section, Let’s refuel us by reading the below joke:
An employee goes to see his supervisor in the front office.
“Boss,” he says, “we’re doing some heavy house-cleaning at home tomorrow, and my wife needs me to help with the attic and the garage, moving and hauling stuff.”
“We’re short-handed,” the boss replies. “I can’t give you the day off.”
“Thanks, boss,” says the employee “I knew I could count on you!”
What is Defect Priority?
Defect Priority signifies how important it is to fix this defect. Can the fixing of the defect wait? It generally gives the ranking to all defects and describes when to fix them.
Priority by the English definition is used in the comparison of two things or conditions, where one has to be given more importance than the other(s) and has to be tackled with/resolved first before proceeding to the next one(s). Therefore in the context of defects, priority of a defect would indicate the urgency with which it would need to be fixed
Classification of Defect Priority:
1. URGENT:
“Affects most or all users and/or a very larger range of system functionality”
This needs to be fixed right now, everything else can wait, the build cannot be released with this defect.
Any problem that has an “aukat” to halt your business then and there is an urgent priority.
Ex:
1. Checkout functionality is not working.
2. Login or Registration Functionality not working fine.
3. Database connectivity failure.
2. HIGH:
“Affects a large set of users and/or large range of system functionality”
Any problem that will make you or your site look stupid or incompetent or untrustworthy is a high priority and should be fixed in current or next sprint.
Ex:
1. The system is not accepting valid Coupon codes while checkout.
2. Customer’s Name is not getting displayed correctly throughout the application.
3. MEDIUM:
“Affects a moderate set of users and/or moderate range of system functionality”
Should be fixed after 2-3 sprints.
Ex:
1. Profile Completion percentage is not showing correct figure on the page.
2. Forgot Password feature is not working fine.
3. Carousel on a homepage is not working.
4. LOW:
“Affects a minimal set of users and/or a very small range of system functionality”
Should be fixed when is Available.
Ex:
1. A system crashes while using the legacy feature of “XYZ” functionality when used with a non-recommended browser (say IE)
2. The download Quarterly statement is not generating correctly from the website & user is already entered in the quarter in last month. We have time to fix the bug as the report is generated at the end of the quarter so priority to fix the bug is Low.
Who manages priority assignments?
I believe that the QA team should not assign priority, for two reasons. First, priority is a subjective assessment. While QA folks will always have an opinion about how important a problem is, the QA team’s assignment of importance should be the objective severity ranking; stick with the objective and keep subjective opinion out of any potential arguments about importance.
Second, priority is usually a tool for guiding development and maintenance work. The issues considered in the decision of what gets built (or fixed) when can range far and wide outside of the QA team’s focus. The QA team does have a say in the decision implicitly because severity plays a role, and the team can lobby for certain problems to be fixed sooner; the QA team’s opinion can play a role in what priority gets assigned, but I don’t think that the primary assignment of priority should come from the QA team.
Who so ever is managing the timelines and milestones of a project plus communicating with clients on daily basis would be the appropriate person to define the priority. Typically, the Product team is responsible for marking the priority – as they communicate with stakeholders on daily basis.
Let discuss few examples of Priority & Severity from High to Low:
High Priority & High Severity:
- Upon login to system “Runtime error” displayed on the page, so due to which tester is not able to proceed the testing further.
High Priority & Low Severity:
On the home page of the company’s website spelling mistake in the name of the company is surely a High Priority issue. In terms of functionality, it is not breaking anything so we can mark as Low Severity, but make a bad impact on the reputation of the company site. So it’s highest priority to fix this.
Low Priority & High Severity:
System is crashing in one of the corner scenarios, it is impacting major functionality of system so the Severity of the defect is high but as it is corner scenario so many of the user not seeing this page we can mark it as Low Priority by project manager since many other important bugs are likely to fix before doing high priority bugs because high priority bugs are can be visible to client or end user first
Low Priority & Low Severity:
Spelling mistake in the confirmation error message like “You have registered success” instead of successfully, success is written.
Point to be remembered: There are many dissimilar terminologies and methodologies that are followed in various firms. The above content is as per best practices in the industry.
Time to evaluate the Takeaway:
Now that we are clear with the concept of Defect Priority and Defect Severity, how about solving this exercise. Assuming we have 5 defects with the below-mentioned defect priority and defect severity, in what order would you fix them?
Bibliography:
1. http://philosophe.com/qa/priority/
2. http://bettersoftwaretesting.blogspot.in/2009/12/defect-priority-defect-severity-and.html
3. http://wiki.c2.com/?DifferentiatePriorityAndSeverity