How to Determine your bug’s Priority ?

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 put 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 who reports the incident.

When the owner sets the priority level, he answers the fundamental question of; how urgently is it to fix this bug? 

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

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

• This bug's level of impact on the engineering team (QA/Dev).

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

• The testing team determines the bug “Severity” level.

• 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.”

• 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 a 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 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 are fixed); such bugs will significantly delay the project and must be fixed before any other bugs with lower priority.