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 is done.

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.

Q. What’s the difference between priority and severity?

Answer:
“Priority” is associated with scheduling, and “severity” is associated with standards.
“Priority” means something is afforded or deserves prior attention; a precedence
established by order of importance (or urgency). “Severity” is the state or quality of
being severe; severe implies adherence to rigorous standards or high principles and
often suggests harshness; severe is marked by or requires strict adherence to
rigorous standards or high principles, e.g. a severe code of behavior. The words
priority and severity do come up in bug tracking. A variety of commercial, problemtracking/
management software tools are available. These tools, with the detailed
input of software test engineers, give the team complete information so developers
can understand the bug, get an idea of its ‘severity’, reproduce it and fix it. The fixes
are based on project ‘priorities’ and ‘severity’ of bugs. The ‘severity’ of a problem is
defined in accordance to the customer’s risk assessment and recorded in their
selected tracking tool. A buggy software can ‘severely’ affect schedules, which, in
turn can lead to a reassessment and renegotiation of ‘priorities’.]
Prior to going into details of "Severity & Priority" issues of software defects, let us quickly
run through the definition of a "Software Defect or Fault"

Software Defect: A software defect is a departure in a software product from its expected
properties. These can be 1) Detected defect, 2) Residual Defect or 3) Software Failure

Detected Defect: It is a software defect detected prior to installation of the software &
before putting into operational use.

Detected Residual Defect: It is a software defect delivered into the operational

installation, either because it was not detected before installation, or may be it was detected
but not removed.

Software Failure: It is the set of symptoms coming to the surface when a residual defect
becomes prominent during operational use of the software.

It is very difficult to standardize the process of recording and analyzing software defects due
to organization dependent methods of communicating the defects, decision making &
subsequent resolution. Every organization uses its own convenient process & infrastructure
to resolve software defects.

However we can comfortably do rating of defects & prioritize their resolution according to
certain minimum guidelines described here. 

If you want to keep track of further articles on Software

Testing, I suggest you to subscribe my RSS feed. 

You can also Subscribe by E-mail and get All New

articles delivered directly to your Inbox.

Severity of Defects / Failures: Rating of defects can be done into four different levels
according to the severity of the resulting failures.

The severity is the extent to which a defect causes a failure that degrades the expected
operational capabilities of the system of which the software is a component. The severity is
classified from the point of view of effect on business efficiency.

The software users, who discover the defects, are the best judges to classify the severity of
the defect.

Following classification of defect severity assumes that the software remains operational.

A) Critical Defects: These are the extremely severe defects, which have already halted or

are capable of halting the operation of a business system. It means the defect has stopped
some business function thereby forcing the deployment of manual workaround procedures
into the operation.

Example of critical defects can be

# The software application refuses to run or stops in-between; 

# Corruption of data
# Serious impact on customer operations for which the customers is aware of the
consequences.

B) Major Defects: These are also severe defects, which have not halted the system, but
have seriously degraded the performance of some business function. Although this is also a
failure, but the business operation continues at a lower rate of performance or disable only
some portion of the business operation.

Example of critical defects in a financial application can be 

Software allows the input of customer details but refuses to confirm the credit information.
This affects the customer facing operation - although the customer may not be aware of it.

C) Minor Defects:

These types of defects are the ones, which can or have caused a low-level disruption of the
system or the business operation. Such defects can result into user inefficiency. Although a
software with a minor defect suffers from the failure, but it continues to operate. Such a
disruption or non-availability of some functionality can be acceptable for a limited period. 

Minor defects could cause corruption of some data values in a way that is tolerable for a
short period. But the business operations continue despite some degradation in performance
- although the business customer may not be aware of it.

D) Cosmetic Defects:

These types of defects are the ones, which are primarily related to the presentation or the
layout of the data. However there is no danger of corruption of data and incorrect values. 

Example of cosmetic defects are

Headings, Banners, Labels, or Colors are absent or badly chosen. These can be considered
as a failure of the software product despite the software being completely operational.

Cosmetic defects have no real effect on the customer facing operations & many times the
customers don’t come to know of any degradation in performance. But cosmetic defects can
cause frustration & annoyance among the users due to continued inefficiency of using such
defective software.

Priority of Defects: When some defect is discovered, a suitablepriority is assigned to it.

This priority is an indication of the urgency with which the defect must be fixed.
Generally, defects of the greatest severity will be assigned the highest priority. However,
due some overriding factors, a high priority may sometimes be allocated to even a minor or
a cosmetic defect. For example a cosmetic defect in a presentation by the company’s CEO
can be assigned a high priority. Or sometimes, it is wise to club many easily resolvable, but
low severity defects before undertaking fixing of a higher severity defect.

Different Levels of Priority:

1) Very Urgent: This priority is allocated to a defect that must be attended with immediate
effect.

2) Urgent: This priority is allocated to a defect that must be attended to as early as

possible generally at the next convenient break e.g. overnight or at the weekend.

3) Routine: This priority is allocated to a defect, fixing of which is scheduled by the next or

some particular release of the software.

4) Not Urgent: This priority is allocated to a defect that may be rectified whenever it is

convenient.

Tags: Software Testing, Software Quality, Software design defects, software data defects,
quality Assurance, software defects