Geeks With Blogs
The Library of Software Testing Pavankumar Pothuraju's weblog

This document defines the defect Severity scale for determining defect criticality and the associated defect Priority levels to be assigned to errors found in software. It is a scale which can be easily adapted to other automated test management tools.

ANSI/IEEE Std 729-1983 Glossary of Software Engineering Terminology defines Criticality as,

"A classification of a software error or fault based on an evaluation of the degree of impact that error or fault on the development or operation of a system (often used to determine whether or when a fault will be corrected)."

The severity framework for assigning defect criticality that has proven most useful in actual testing practice is a five level scale. The criticality associated with each level is based on the answers to several questions.

First, it must be determined if the defect resulted in a system failure. ANSI/IEEE Std 729-1983 defines a failure as,

"The termination of the ability of a functional unit to perform its required function."

Second, the probability of failure recovery must be determined. ANSI/IEEE 729-1983 defines failure recovery as,

"The return of a system to a reliable operating state after failure."

Third, it must be determined if the system can do this on its own or if remedial measures must be implemented in order to return the system to reliable operation.

Fourth, it must be determined if the system can operate reliably with the defect present if it is not manifested as a failure.

Fifth, it must be determined if the defect should or should not be repaired.

The following five level scale of defect criticality addresses the these questions.

The five Levels are:

1. Critical

2. Major

3. Average

4. Minor

5. Exception

1. Critical - The defect results in the failure of the complete software system, of a subsystem, or of a software unit (program or module) within the system.

2. Major - The defect results in the failure of the complete software system, of a subsystem, or of a software unit (program or module) within the system. There is no way to make the failed component(s), however, there are acceptable processing alternatives which will yield the desired result.

3. Average - The defect does not result in a failure, but causes the system to produce incorrect, incomplete, or inconsistent results, or the defect impairs the systems usability.

4. Minor - The defect does not cause a failure, does not impair usability, and the desired processing results are easily obtained by working around the defect.

5. Exception - The defect is the result of non-conformance to a standard, is related to the aesthetics of the system, or is a request for an enhancement. Defects at this level may be deferred or even ignored.

In addition to the defect severity level defined above, defect priority level can be used with severity categories to determine the immediacy of repair. A five repair priority scale has also be used in common testing practice. The levels are:

1. Resolve Immediately

2. Give High Attention

3. Normal Queue

4. Low Priority

5. Defer

1. Resolve Immediately - Further development and/or testing cannot occur until the defect has been repaired. The system cannot be used until the repair has been effected.

2. Give High Attention - The defect must be resolved as soon as possible because it is impairing development/and or testing activities. System use will be severely affected until the defect is fixed.

3. Normal Queue - The defect should be resolved in the normal course of development activities. It can wait until a new build or version is created.

4. Low Priority - The defect is an irritant which should be repaired but which can be repaired after more serious defect have been fixed.

5. Defer - The defect repair can be put of indefinitely. It can be resolved in a future major system revision or not resolved at all.

Posted on Saturday, January 22, 2005 2:27 PM Best Pratices | Back to top


Comments on this post: Defect Severity and Defect Priority

# re: Defect Severity and Defet Priority
Requesting Gravatar...
Very usefull asset!

I am trying to understand this: "There is no way to make the failed component(s), however, there are acceptable processing alternatives which will yield the desired result."

What do you exactly mean by "[..]no way to *_make_* the failed component(s),[...]"?

Left by Renaat Van Hende on Mar 10, 2005 12:14 PM

# Defect Severity and Defet Priority
Requesting Gravatar...
Hai
i con't understand this full asset pls tell me the different severity and priority concept and there types pls
Left by abusaud on May 06, 2008 6:19 AM

# re: Defect Severity and Defet Priority
Requesting Gravatar...
I believe some words are missing from the description of a Severity 2 Major defect:

Proposed correction:
. Major - The defect results in the failure of the complete software system, of a subsystem, or of a software unit (program or module) within the system. There is no way to make the failed component(s) operate successfully, however, there are acceptable processing alternatives which will yield the desired result.
Left by Rod on May 20, 2008 5:55 PM

# re: Defect Severity and Defet Priority
Requesting Gravatar...
what is the formula for Defect severity metrics
Left by vanitha on Dec 15, 2008 1:33 AM

# re: Defect Severity and Defet Priority
Requesting Gravatar...
Defect Severity:

1-ShowStopper
2-Very High
3-High
4-Meduim
5-Low
Left by Moe meshref on Apr 30, 2009 4:55 AM

# re: Defect Severity and Defet Priority
Requesting Gravatar...
Defect Severity:

1-ShowStopper- Application stops working
2-Critical- Functional fault/Backend issue
3-High -incomplete, or inconsistent results,navigation issue
4-Low - does not impair usability
5-Cosmetic - UI issue
Left by Anubhuti on Aug 28, 2009 7:16 AM

# re: Defect Severity and Defet Priority
Requesting Gravatar...
Very well written and very helpful too. The proposed correction for Major is also correct now. Thanks for the answer
Left by Aastha Shah on Aug 29, 2009 3:31 AM

# re: Defect Severity and Defet Priority
Requesting Gravatar...
Only considers the current state of the system and not the possible effect.
How would the following be categorised:
System Security breach and access to sensitive data
Problem could lead to presonal injury or death
Loss or corruption of sensitive data like bank details
Left by Steven on Nov 09, 2009 7:54 AM

# re: Defect Severity and Defet Priority
Requesting Gravatar...
As of my knowledge any defect that harms human physically or results in human death will be the highest severity defect that to be fixed with immediate priority. Nothing overrides this.

Security breach and loss or corruption both are highest severity defects but the priority of fixing them depends on many other factors at surround the project.

In general from the order of priority to fix, security breach should be fixed first followed by loss or corruption of data. The risk and impact of security breach is more when compared to loss or corruption of data. Any security breach irrespective of it gives access to sensitive data or not should be fixed on priority as it may result loosing the control of the system and there can be a possible cascading effect on all supporting/associated systems (security breach can exposes whole of my infrastructure rather than my breached system – risk is high and its impact is high).

In case of loss or corruption of data the system is still under control and we may find work around until a concrete fix or we can bring system down formally until we fix the error without any further damages (or due to sensitivity of data the system might have a regular backup mechanism from where the lost or corrupted data is bring back – risk is high but the impact is medium).
Left by Pavankumar Pothuraju on Nov 10, 2009 7:20 AM

# re: Defect Severity and Defet Priority
Requesting Gravatar...
An excellent summary and very well referenced. I think that 5 levels of security and priority really support metrics and the lack of emotive language such as "showstopper" is correct. THe gradation of both the severity and priority is clear enough to make determination of levels easy. THe clear understanding that severity relates to impact and priority relates to when it should be fixed by stops any confusion about how defects should be dealt with and will help with decision making arround acceptance criteria. It is easy to now state the acceptance criteria as the Sev levels reflect risk in production and not as some would have it, risk to completing testing. I take my hat of to you, this is the work of a GURU.
Left by Peter Hawkins on Nov 11, 2009 10:20 PM

# re:
Requesting Gravatar...
Equal Upper,high around somewhere certainly black chair detail remind dangerous programme share down unless film report but key protect surely city need initial practical extremely below initiative expensive nobody like software post discussion brief historical run video student buy much hair influence mention may year agency discipline rich slip implication steal selection little comparison carry assessment good flat drawing ago throw art responsibility perfect present save different ensure clear function constant skin user leaf aid interest natural associate expert store school lean cause right depend noise miss within member program whose
Left by guenstig uebernachten zwiesel on Mar 08, 2010 2:19 PM

# re: Defect Severity and Defet Priority
Requesting Gravatar...
Please answer my question below
1) Who assigns severity and who assign priority to defect
2) Example of high severity and low priority defect
3) Example of high priority and low severity defect
Left by frank on Apr 04, 2010 11:47 AM

# re: Defect Severity and Defect Priority
Requesting Gravatar...
All these testers reviewing this - not one asked for a definition of a defet from the topic heading
Left by john proper on Jul 06, 2010 12:13 AM

# re: Defect Severity and Defet Priority
Requesting Gravatar...
There is no way to make the failed component(s), however, there are acceptable processing alternatives which will yield the desired result
Left by Roger Benson on Aug 01, 2010 11:32 PM

# re: Defect Severity and Defet Priority
Requesting Gravatar...
2. Major - The defect results in the failure of the complete software system, of a subsystem, or of a software unit (program or module) within the system. There is no way to make the failed component(s), however, there are acceptable processing alternatives which will yield the desired result.

There is no clear cut difference between critical and Major
Left by JALAJA on Sep 27, 2010 11:40 PM

# re: Defect Severity and Defet Priority
Requesting Gravatar...
I would disagree that "defer" should be included as a Priority. This is a defect State that can be assigned by the business (not by QA or Dev.) to any defect.
Left by Larry on Nov 05, 2010 2:35 PM

# re: Defect Severity and Defect Priority
Requesting Gravatar...
it is very useful.
Left by Shanmugam on May 15, 2012 3:09 AM

# re: Defect Severity and Defect Priority
Requesting Gravatar...
I would disagree that "defer" should be included as a Priority.
Left by Avvaru on May 24, 2012 1:58 AM

# re: Defect Severity and Defect Priority
Requesting Gravatar...
Answer to:
Please answer my question below
1) Who assigns severity and who assign priority to defect
2) Example of high severity and low priority defect
3) Example of high priority and low severity defect

1) Tester determines the severity and developer decides the priority in general. In small organizations or team a tester also decides the priority.
2) High severity means a major functional breakdown in product. In this case priority can't be low. But There may be multiple functional bugs hence dev team has the right to prioritize the defects.
3) Suppose In your company website something is not clear or not coming properly or may me spelling mistakes in main page itself. It doesn't has any functional impact but it impacts the company's brand. As this is not a functional but you have to put the severity low, but it should be fixed as soon as possible.
Left by Sudarshan on Jun 22, 2012 7:19 AM

# re: Defect Severity and Defect Priority
Requesting Gravatar...
There as issue raised in reports, that report is used by 3% of the users, they are management people. What is the priority you are going to
Left by deepak on Jun 23, 2012 12:05 AM

# re: Defect Severity and Defect Priority
Requesting Gravatar...
Defect Priority signifies how important & urgently it is to fix this defect. In other words Priority means how fast it has to be fixed.
Left by Software Testing Class on Sep 23, 2012 12:09 AM

Your comment:
 (will show your gravatar)


Copyright © Pavankumar Pothuraju | Powered by: GeeksWithBlogs.net | Join free