How to categorize defects?

Question

Many project managers and other non-tester roles search for proper categorization according to severity (A-B-C) of the defects and they search for description how to distinguish between each category.

What are best practices? What is the Ideal description of categories?

Answer 1

There is no one "right" answer. The number and type of categories of defects that would be appropriate to your context depend upon several factors, including:

• Type of application
• Your team size
• The level and frequency of "in the hallways" conversations between people on the team
• The number of bugs you have "hanging around" waiting to be taken care of
• etc.

Having said that, one of the most important considerations you have to make involve: - Should we have two main categories or one per bug? - The "two main categories for each bug" approach often has, e.g., specific comments about 'what percentage of users will see this?' and 'how large is the impact?' - A "one main category for each bug" could be a blend of those two items (e.g., Sev 1, Sev 2, Sev 3) as described in Ivor McCormack's approach shown below.

Personally, I would consider Ivor McCormack's approach as a possible starting point, discuss options with your stakeholders, and adjust as necessary for your context.

Answer 2

Let's step back a moment and try to look at this from a different perspective.

If your team is using a defect tracking database to track bug backlog, then we should agree that the primary purpose of the defect tracking database is to

• triage new bugs/work as it comes in
• manage the 'triaged' backlog of bugs/work (assign, prioritize, etc the work)

You started by stating "many project managers..." and this is the perspective that you should be approaching the problem from because it is usually the project managers (and hopefully dev and test managers/leads) who are triaging the backlog on a daily (or frequent) basis.

So, the categories you choose should be those that most help the project manager and other managers query on the types of bugs that are most important to them.

Severity is a subjective rating that reflects the negative impact on a customer. Priority (usually assigned by the triage team) is used to indicate how quickly or the order in which the bug/work item should be addressed. But, there are many other ways to slice and dice bugs/work items.

For example, we track test code defects, product code defects, documentation issues, etc in our databases. So, to differentiate between bug types categorize by "issue type."

Other categories we often use for triage include Blocking branch, feature path, milestone or sprint, triage, and status (active, in-work, resolved, closed).

I agree the number of categories should be kept to a minimum. Filling out a lot of unnecessary/unused fields in a dB is often pointless noise and clutters the important information.

IMHO, work with your project manager and understand what types of queries they want to run on the defect tracking database and use that to identify the categories important for your team.

Answer 3

In addition to all the high / medium / low priority types of rankings I also find we consider the following categorizations, both separately and as factors leading to the ranking level:

• Affect on bottom line revenue, e.g. this will double our revenue!
• Number of users affected, e.g. will help 70% of our user base
• Platform, e.g. we don't fix ie8 issues
• Future business plans, e.g. that feature ends next month anyway
• Investment in the business, e.g. if we fix this bug it'll help our IPO!
• Quality of data that we send to our business partners, e.g. lead generation

In many cases we use labels to mark tickets for the above categories and are then able to search based on the labels we've previously applied.

Answer 4

Choose the smallest number of categories that you can get away with. If you don't know how many you can get away with, start with two. If you can't decide on two categories, you may not need any. And if you need more, your stakeholders will let you know.

Answer 5

If this area is not clear then, in my opinion, you should speak to him and figure out what they want. It is similar to risk based approach where the tester's (test manager) responsibility to find the consensus which item represents higher risk and which not.

On the other hand, from communication viewpoint the defects, the whole, are "playing" multiple role and sometimes the list of defects, and the defects itself should be able to provide non-technical information.

• they are technical information for the developers what to focus on, even for a little time
• information for the tester to define defect areas, defect clusters, controlling and reporting
• they may represent other information aspects, e.g. non-technical, fiscal, etc., for the managers and product owners and this can be huge, especially if they are not technical people

If you are in the position to create how to organize your defects you should consider a lot of things. On the other hand, Justing is right. There is no "right" answer. Every situation is different in a way and the devil is in the details.

Answer 6

According to ISTQB certification the categorization according severity and priority is defined as follows:

http://istqbexamcertification.com/what-is-severity-and-priority-in-software-testing/

Severity (measures the impact of the bug to the software):

• Critical: The defect that results in the termination of the complete system or one or more component of the system and causes extensive corruption of the data. The failed function is unusable and there is no acceptable alternative method to achieve the required results then the severity will be stated as critical.
• Major: The defect that results in the termination of the complete system or one or more component of the system and causes extensive corruption of the data. The failed function is unusable but there exists an acceptable alternative method to achieve the required results then the severity will be stated as major.
• Moderate: The defect that does not result in the termination, but causes the system to produce incorrect, incomplete or inconsistent results then the severity will be stated as moderate.
• Minor: The defect that does not result in the termination and does not damage the usability of the system and the desired results can be easily obtained by working around the defects then the severity is stated as minor.
• Cosmetic: The defect that is related to the enhancement of the system where the changes are related to the look and field of the application then the severity is stated as cosmetic.

Priority (defines the desired order of fixing the bugs):

• Low: The defect is an irritant which should be repaired, but repair can be deferred until after more serious defect have been fixed.
• Medium: The defect should be resolved in the normal course of development activities. It can wait until a new build or version is created.
• High: The defect must be resolved as soon as possible because the defect is affecting the application or the product severely. The system cannot be used until the repair has been done.