How to prioritize bugs numerically

How to prioritize bugs numerically – An effective way of prioritization of bugs

You must have seen developers & testers fighting with each others on priority of bugs. Testers log the bug as high priority or critical and sometimes, developers surprised to see the priority. Most of the times, both developer & tester will not agree on the priority set by each other. I’ve seen sometimes, even product manager / project manager / business analyst are not able to prioritize the defects or bugs EFFECTIVELY. Even in many process oriented organizations, it becomes a challenge.
Since, these bugs are risk to the application and project delivery, so, let’s apply basic principle of risk management here. i.e. Risk Value = Probability x Impact

In case of bugs, Priority = Severity Value x Priority Value

Now, you can use this priority number to actually prioritize your bugs and fix them in the required order. Lets see the entire process in the below example:
1. Dear Testers – Please do not set priority of the bug. Do it only if you are interacting with the customer and thoroughly understand the business flow implemented in the application. Priority should be set based on the criticality of the business / functional requirement. Also, set severity only after doing a through impact analysis. Best is if we can have bug triage meeting at this stage, so that everyone can provide their inputs to identify the correct severity level.
2. Set four severity levels: High, Medium, Low, Lowest. Set their values as 4, 3, 2, 1. 4 as highest and 1 as lowest.

SeveritySeverity ValueExample
High4Data loss, missing feature, security violation
Medium3Feature is missing but workaround is there, if high profiles users like management will get an impact, then it would be of high severity 4
Low2It is impacting minor things, but, user is able to do the work
Lowest1A cosmetic error, spelling mistake, typo etc..

3. Set four priority levels: Critical, High, Medium, Low. Set them values as 4, 3, 2, 1. 4 as Critical and 1 as low. Please ask the business analyst to set the priority.

PriorityPriority ValueExample
Critical4Application is getting started, Critical business flow got stuck, Data loss, business loss, loss of end user, a security violation, system is very unstable
High3Feature is missing which is not critical for only very few users that do not have much impact on business, if high profiles users like management will get an impact, then it would be of high severity 4
Medium2Feature is missing but workaround is there. If users from management group are getting impacted, then it can be of priority 3 or 4. It can also be some feature of the functionality is not working
Lowest1A cosmetic error, spelling mistake, typo. Here, one important point to note is that even a spelling mistake or typo can also be of high priority or critical. e.g. If there is a spelling mistake of name of a person from senior management, then it may have high priority.

Priority can be calculated as

Bug IdBug DescriptionSeverity ValuePriority ValuePriority
Bug_1Bug Description 1248
Bug_2Bug Description 2326
Bug_3Bug Description 3111
Bug_4Bug Description 44312
Bug_5Bug Description 5248

Now, the bug with highest priority should be fixed first. In this case bug “Bug_4” should be fixed first. Then Bug_1 and Bug_5 should be fixed and so on.

This way we will have a number defining the priority of the based on the two logical facts.

You do not need to follow this practice all the time. After development, initial during testing/bug fixing phase, you may skip this process. Eventually, at that time, we have to fix all the bugs.
When you see there is a production release in next 2-4 days or more or less depending upon the size of release and there are lot of open bugs, you may prioritize bugs based on this approach. Best is do this exercise 5-7 days before the final release. Also, I would suggest this kind of exercise for all customer reported bugs during UAT or post production release.
As a pilot, I’ve applied this technique to one of my project. Let’s see how practical is this. Please share your views as well on this approach.

Rahnuma is a technical content writer at software testing stuff. A software engineer by degree and a dynamic content creator by passion, she brings to table over 3 years of writing experience in tech niche. Combining her enthusiasm for writing and technology, she loves to share her thoughts on the latest tech trends.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top