One Simple Way a Bug Can Be Prioritized

You are here
One Simple Way a Bug Can Be Prioritized

Software development requires Quality assurance as users require solid and stable solutions. However, eliminating every single defect software may seems impossible, because such an approach will take too much time and resources. No business will actually be able to afford such an activity. Hence we face the need to prioritize defects in order not to miss anything valuable. But, how should such decisions be made?

High? Low? Medium? Do those words even mean as much as the damage any mistreated bug in your code may cause? What is ‘Low’? How do we define ‘Medium’? Is an app crash higher than user data exposure or is it of less priority? Those questions do have an answer, but it will only be available after the following three principals are considered:

  • How are users affected with a defect? Have a precise measurement scale, let’s say, from one to ten, where ten is user SSN exposure and one is a typo on a website page. Work with that data and make sure users do not have to go around obstacles while using your solution and are ensured with a friendly overall experience.
  • How is your business affected with the defect? Is your business in danger because of possible information leaks or overloads which lead to massive malfunctions? Use the very same scale described earlier to determine priority levels.
  • How many users are actually affected? Just conduct a research in order to determine the precise amount of your customers who are experiencing this or that defect on a daily/weekly basis, etc. gain from that data.

Answers to these questions will get you going in the right direction, considering any level 10 bug from any of the mentioned above categories is of High Priority, level 5’s are Medium and 1’s are Low. But this is still not all, as your resources are limited. Hence you are also to consider all the following factors before making the final decision on this or that defect priority.

  • Consider the risks. Do you know most defects come from fixes? OK, a feature was redesigned to eliminate one particular bug, code changed, one thing led to the other and now you have 5 defects? Was the process worth it? Especially if you demand fixes right before the release; when new defects may become even more devastating, and time just runes out on you?
  • Consider the expanses. How much will a fix be worth? Can you afford it, and if it is expensive, is it really that necessary or it can wait until you gain more money from first app sales?
  • Are people already fixing anything in the area a defect was located? If yes, the most practical step would be to make them fix a new defect as well.
  • PS: Defects in older software versions should always have lower priority.
  • PPS: Security defect are always of highest priority and have to be dealt with immediately.

Created: 30 Apr 2015