Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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?

share|improve this question
2  
In your previous question sqa.stackexchange.com/questions/7531/… you get answers not only on possible labels for severity categories but also for descriptions. Why are they not enough? Maybe you should describe specifics of your project to get answers more relevant for your problem. –  dzieciou Jan 15 at 7:42

5 Answers 5

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.

enter image description here

share|improve this answer
    
+1 i especially like the combination of visibility and impact. –  Dee Jan 15 at 18:49

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.

share|improve this answer
    
Issue type is applicable more to Issues, not Bugs. So you do mixed issues and bugs and that is actually not right as there should be different worflow and usually also different audience. On the other hand you mentioned othe microsoft like parameters (feature path, milestone, status) therefore +1 –  Dee Feb 12 at 19:53
1  
We use 1 database to track all "bugs" which we identify as any anomaly in the entire software development lifecycle. Therefore I could have a bug against automated test code (which is compiled with the product code) as an issue type "Test Code Defect," or a bug in the product code which would be an issue type of "Product Code Defect," or a bug in the spec which would be a "Spec Issue" etc. Essentially, "Issue type" is a way to classify the type of bug it is and who is involved and the workflow. –  Bj Rollison Feb 25 at 18:48

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.

share|improve this answer
    
I cant imagine that I would not need any category according to severity. As test people should tell to projet people how to do it, not the opposite, i do not agree with your answer. –  Dee Jan 15 at 5:26

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.

share|improve this answer
    
Risk is applicable more to Issues, not Bugs and in Test analysis to decide which part should be tested most. And if there is some glue, usually risk is transformed to priority of the bug (how quickly the bug should be repaired) or to severity of the bug (in case of business risks, caused by error). So i do not agree completely. –  Dee Feb 12 at 19:47

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.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.