Syntel CQA Forum
1 Identifier
♦ Each defect should be uniquely
identified
♦ Operational incidents should be
uniquely identified and subjected to
subsequent analysis to determine
whether multiple incidents are related
to a single defect.
2 Type
It is possible to classify defects into a
variety of types or classes depending upon
the nature of the defect. The IEEE Standard
Classification for Software Anomalies, 1992,
provides the following classification:
♦ Logic problem
♦ Computational problem
♦ Interface/timing problem
♦ Data handling problem
♦ Data problem
♦ Documentation problem
♦ Document quality problem
♦ Enhancement
♦ Failure caused by a previous fix
♦ Other problem
3 Severity
UKSMA recommends that defects should be
rated with respect to the severity of any
resulting failures, at four levels as follows:
Table 1: Defect/Failure Severity Scale
#Level Description of Defect / Failure
Severity Level
♦ A Critical A very severe defect that
may or has rendered the system
inoperable — that is, some business
function is now no longer possible —
manual procedures, if they exist, may
have to be brought into operation.
♦ B Major A severe defect that may or
has seriously degraded but not disabled
some business function, amounting to
failure. The business operation can
continue at a lower rate of activity or
only a portion of a business function is
disabled.
♦ C Minor A defect that may or has
resulted in low-key disruption to
business operations, causing
example, user inefficiency. The software
suffers a failure, but is still operable.
♦ D Cosmetic A defect that may or is
related to the layout or presentation of
data but which results in no corruption
of data and no wrong values.
10718237.doc
Characteristics of Defects CQA Doc No 14
♦ The severity of a defect is an indication
of the effect of the failure resulting
from (or potentially resulting from)the
defect. That is, the severity is the extent
to which a defect causes a failure that
degrades (or may degrade)the intended
and expected operational capabilities of
the system of which the software is a
component.
♦ The classification of severity should be
determined from the point of view of
business efficiency and effectiveness.
♦ The software users responsible for the
discovery of a defect (i.e. those who
experience a failure)should classify the
severity. Users should not attempt to,
and will not accurately, discriminate
between software components i.e.
business applications or systems
software, or between software and
hardware defects.
♦ The classification of defect severity
given above assumes that the software
is operational. If it is desired to classify
the severity of defects discovered
during development or testing, the
person who discovers the defect will
need to make a judgement as to the
potential severity of any resulting
failure, with respect to the activity being
conducted. For example, coding cannot
proceed until a defect in the module
design has been rectified.
4 Symptoms
The symptoms of a defect are those
features that manifest themselves to the
user when a failure results. The symptoms
form the clues and evidence needed to
enable support staff to track down and
resolve the causal defect.
5 Effect on Business
A description or local code used to describe
the specific effect of the defect on the
conduct of the business
6 Priority
The priority assigned to a defect is an
indication of the urgency with which it must
be rectified. In general, defects of the
greatest severity will be assigned the
highest priority. However, there often are
political reasons why a fix to a lower
severity defect is assigned a high priority
for
e.g. a cosmetic defect in the Managing
Director s report may need to be fixed very
urgently! Or it may be reasonable to
consolidate a number of easily resolved,
but low severity, defects with a fix to a
higher severity defect.
Page 1 of 3
Syntel CQA Forum Characteristics of Defects CQA Doc No 14

A variety of schemes for denoting priority It is recommended that practitioners record

are in common use. UKSMA recommends the dates and times on which a defect s
priority levels should be numbered from status changes in order that measures of
one to four responsiveness, such as Mean Time To
Resolve (MTTR),may be derived.
Table 2:Defect Priority Scale
8 Origin — where detected
#Level Description of Defect Priority
Level The origin of a defect, incident or failure is
the point at which it was first detected.
1 Very Urgent A defect that must be
There are three main stages of a software
attended to immediately
life cycle where a defect is likely to be
2 Urgent A defect that must be detected.
attended to rapidly usually at
These are:
the next convenient break
e.g. overnight or at the ♦ During Development, Enhancement or
weekend Corrective Maintenance
3 Routine A defect that should be ♦ During Testing
scheduled to be fixed by the ♦ During Normal Operation
next or a specified release of
the software 9 Source — System Component
4 Not Urgent A defect that may be Any failure reported by users will be
rectified whenever it is associated by them with the application
convenient they are using at the time the failure
becomes evident. Clearly however it is
The combination of the coding of defects possible that the defect causing the failure
proposed for Severity and for Priority may lie in another application, the
means that defects can be coded as operating system, infrastructure software or
e.g.A1,C2,D4,etc. the hardware associated with any of these.
7 Status When a failure is reported an analysis
The status of a defect is an indication of should be performed to allocate the defect
how far the defect has progressed through to the correct defective component.
the rectification process Status 10 Source — Module(s) Fixed
classification will vary between
organisations, depending on the exact When a defect is resolved, the fix is applied
structure of their processes. Typically, the to (a)specific software component(s)or
status of a defect will take on one of the module(s).It is often useful to record the
values given below, which are related to the component(s)or module(s)affected so that
defect life history discussed earlier defect-prone modules can be identified and
rebuilt or replaced.
♦ Incident reported (user reports incident)
The engineer who is responsible for the fix
♦ Confirmed (multiple instances should record this information.
eliminated and repeatable defect type
recognised) 11 Source — Injection Stage
In addition to recording the component
♦ Classified by source (identified as
where a failure is evidenced and the
hardware, software, operational, etc.)
module that must be fixed, it is also very
♦ Resolution in progress (i.e. responsibility worthwhile to determine the specific life
allocated for the necessary fix) cycle stage or activity in which the defect
was first introduced.
♦ Scheduled for work
12 Root Cause
♦ Work-around provided
As noted above, a defect is the result of an
♦ Solution developed error. This causal error itself has some root
♦ Tested cause and it is sometimes of great
importance to determine this.
♦ Installed
The root cause can be classified as one of
♦ Resolved the following:
♦ Defect types covered by the above ♦ Objectives e.g. wrong terms of
model include, under resolution in reference, misunderstood goals, over-
progress ,corrections to documentation ambitious objectives
or the provision of user training, etc.

10718237.doc Page 2 of 3
Syntel CQA Forum Characteristics of Defects CQA Doc No 14

♦ Processes, tools and methods e.g. an

ineffective requirements gathering
process, an out-of-date risk
management process, non-scalable
project management method (e.g.
having to use full blown PRINCE for a
relatively small project),no estimating
process, an ineffective change control
process
♦ People e.g. management requesting
that the project team cut corners, lack
of training, inexperienced project team,
poor morale or motivation
♦ Failure of organisation or
communication e.g. through lack of user
involvement, poorly defined or agreed
responsibilities, failure of management,
♦ Hardware e.g. processor bug that loses
arithmetical precision, insufficient
memory
♦ Software e.g. operating system bug that
doesn't release resources, bug in tools
software, bug in compiler,Y2K failure
♦ Environment e.g. major organisational
change, budget changes, strikes, noise,
interruptions, poor work habitat
13 Estimated Cost Of Repair (ECOR)
The Estimated Cost Of Repair is usually
expressed as the staff effort (in hours of
productive work)required to resolve a
confirmed defect.
The Estimated Cost Of Repair is typically
recorded at the time that a defect is
classified and responsibility for its
resolution is allocated.
14 Actual Cost Of Repair (ACOR)
The Actual Cost Of Repair is usually
expressed as the staff effort (in hours of
productive work) expended in resolving a
confirmed defect. It is recorded after a
defect is resolved and the fix installed. The
Actual Cost Of Repair should be inclusive of
all efforts expended from the time that the
first related incident is reported to the time
that the defect is resolved.

10718237.doc Page 3 of 3