How to Determine your bug’s Priority ?

Updated: Dec 2, 2020

Before we begin to review this section I want to add my personal opinion and say that the ability to determine the bug priority is a real art, the owner that needs to set the level of priority must consider multiple variables that should be calculated before he can set the relevant and appropriate priority level (you will see the complexity and involved parameters during my review).

Bug priority is a mandatory field on every Bug report, it's usually determined by the project owner and not by the tester which reports the incident.

When the owner sets the level of the priority he actually answers the basic question of; how urgently is to fix this bug? 


Remember that during a testing process, you have hundreds and maybe thousands of reported Bugs with different level of severity (I hope that it’s not your case...), when setting the “Priority” level, we determine the order that those bugs will be fixed by the Eng. Team. 


In my opinion and based on my experience, the parameters that the owner should consider before he can set the ‘Priority’ level: 

  • The level of impact that this bug has on the engineering team (QA/Dev).

  • Is this bug affecting specific functionality/components or systems?

  • The bug “Severity” level determined by the testing team.

  • Available resources that can fix and test the Bug.

  • The Bug visibility and likelihood to reproduce.

  • The project timelines and current status.

  • Based on the general project priorities.

  • The bug level of “Risk”.

  • How this bug affects other processes that don’t relate to the basic testing coding (Automation runs that failed to run due to this bug).

There are few concepts regarding the “Prioritization” levels (Depends on the company…), the generic levels that should be part of every scale are: 


Priority 1 (Low)

Bugs with this priority will be fixed only after that all the other bugs with higher priority are fixed, in many cases, such bugs are not affecting the software release(in most cases will be fixed in future releases). 


Priority 2 (Medium)

Such bugs should be fixed between the “Low” – “High” priority bugs, in most cases, will be fixed in the next software update/releases.


Priority 3 (High/Critical)

Bugs with this priority are critical and must be fixed as soon as possible, there must be a solution in the next build, bugs with this priority should be fixed previously to any lower priority bugs. In addition, bugs with this priority are crucial to the product release and must be fixed in advance.


Priority 4 (Urgent/Blocker)

Bugs with this priority must be fixed as soon as possible (in some cases the project is stuck until they fixed), such bugs will lead to a major delay in the project and must be fixed prior to any other bugs with lower priority.



16 views0 comments