Friday, November 13, 2015

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 Defect priority is a real art, the owner that need 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).

Defect priority is a mandatory field on every defect report, its usually determined by the project owner and not by the tester which report the incident.
 
When the owner sets the level of priority he actually answer the basic question of; how urgently is to fixing this bug? 

Remember that during a testing process, you have hundreds and maybe thousands of reported defects 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/component or system?
  • The bug “Severity” level that determined by the testing team.
  • Available resources that can fix and test the defect.
  • The defect 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 affect other process that doesn’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 from 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 advanced.

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.


No comments:

Post a Comment

My Presentations