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.

Friday, November 6, 2015

Software Defects - The relation between Priority and severity



Results/Suggested solution


This combination, is created when a critical component/function is broken in the tested application (All blocker bugs that cause major delays, Loss of critical data Etc.), and will affect the Engineering progress, Business reputation or the end clients.

Examples :
-          Credential window that failed to transfer the log in command.
-          An Application that failed to be installed on a supported platform.
-          Functionality that creates memory leaks.
-          Etc.


This combination, is created when the bug doesn’t have any major effect on the tested software, in most cases, it’s a minor issue or cosmetic bug, that will severely affect the company reputation.

-          Company logo that displayed with the wrong colors.
-          Spelling mistakes on major locations in the software.


This combination, is created when a bug will affect a specific functionality that doesn’t affect the testing effort, the bug will occur in rare situations that in many cases are not reproducible.

-          Error notification that occurs when the user press two times on the same button.
-          Log In operation that will fail if the user insert a user name with 20 chars.


This combination, is created when a minor bug is found and doesn’t affect the functionality or any related aspects that may arm the company reputation.

-          Wrong Font size on specific location/error notification.
-          Minor notification that displayed with delay of 0.5 Sec.

My Presentations