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.
| Severity | Severity Value | Example |
| High | 4 | Data loss, missing feature, security violation |
| Medium | 3 | Feature is missing but workaround is there, if high profiles users like management will get an impact, then it would be of high severity 4 |
| Low | 2 | It is impacting minor things, but, user is able to do the work |
| Lowest | 1 | A 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.
| Priority | Priority Value | Example |
| Critical | 4 | Application is getting started, Critical business flow got stuck, Data loss, business loss, loss of end user, a security violation, system is very unstable |
| High | 3 | Feature 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 |
| Medium | 2 | Feature 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 |
| Lowest | 1 | A 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 Id | Bug Description | Severity Value | Priority Value | Priority |
| Bug_1 | Bug Description 1 | 2 | 4 | 8 |
| Bug_2 | Bug Description 2 | 3 | 2 | 6 |
| Bug_3 | Bug Description 3 | 1 | 1 | 1 |
| Bug_4 | Bug Description 4 | 4 | 3 | 12 |
| Bug_5 | Bug Description 5 | 2 | 4 | 8 |
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.
