Doc 14 Characteristics of Defects

8/14/2019 Doc 14 Characteristics of Defects

1/3

Syntel CQA Forum Characteristics of Defects CQA Doc No 14

1 Identifier

Each defect should be uniquelyidentified

Operational incidents should be

uniquely identified and subjected tosubsequent analysis to determine

whether multiple incidents are relatedto a single defect.

2 Type

It is possible to classify defects into avariety of types or classes depending uponthe nature of the defect. The IEEE StandardClassification 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 anyresulting failures, at four levels as follows:

Table 1: Defect/Failure Severity Scale

#Level Description of Defect / FailureSeverity Level

A Critical A very severe defect thatmay or has rendered the systeminoperable that is, some businessfunction is now no longer possible manual procedures, if they exist, mayhave to be brought into operation.

B Major A severe defect that may orhas seriously degraded but not disabledsome business function, amounting tofailure. The business operation cancontinue at a lower rate of activity oronly a portion of a business function isdisabled.

C Minor A defect that may or has

resulted in low-key disruption tobusiness operations, causing forexample, user inefficiency. The softwaresuffers a failure, but is still operable.

D Cosmetic A defect that may or isrelated to the layout or presentation ofdata but which results in no corruptionof data and no wrong values.

The severity of a defect is an indication

of the effect of the failure resultingfrom (or potentially resulting from)thedefect. That is, the severity is the extentto which a defect causes a failure thatdegrades (or may degrade)the intendedand expected operational capabilities ofthe system of which the software is acomponent.

The classification of severity should be

determined from the point of view ofbusiness efficiency and effectiveness.

The software users responsible for the

discovery of a defect (i.e. those whoexperience a failure)should classify theseverity. Users should not attempt to,and will not accurately, discriminatebetween software components i.e.business applications or systems

software, or between software andhardware defects.

The classification of defect severitygiven above assumes that the softwareis operational. If it is desired to classifythe severity of defects discoveredduring development or testing, theperson who discovers the defect willneed to make a judgement as to thepotential severity of any resultingfailure, with respect to the activity beingconducted. For example, coding cannotproceed until a defect in the moduledesign has been rectified.

4 Symptoms

The symptoms of a defect are thosefeatures that manifest themselves to theuser when a failure results. The symptomsform the clues and evidence needed toenable support staff to track down andresolve the causal defect.

5 Effect on Business

A description or local code used to describethe specific effect of the defect on theconduct of the business

6 Priority

The priority assigned to a defect is anindication of the urgency with which it mustbe rectified. In general, defects of thegreatest severity will be assigned thehighest priority. However, there often arepolitical reasons why a fix to a lowerseverity defect is assigned a high prioritye.g. a cosmetic defect in the ManagingDirector s report may need to be fixed very

urgently! Or it may be reasonable toconsolidate a number of easily resolved,but low severity, defects with a fix to ahigher severity defect.

10718237.doc Page 1 of 3


2/3


A variety of schemes for denoting priorityare in common use. UKSMA recommendspriority levels should be numbered fromone to four

Table 2:Defect Priority Scale

#Level Description of Defect PriorityLevel

1 Very Urgent A defect that must beattended to immediately

2 Urgent A defect that must beattended to rapidly usually atthe next convenient breake.g. overnight or at theweekend

3 Routine A defect that should bescheduled to be fixed by thenext or a specified release ofthe software

4 Not Urgent A defect that may berectified whenever it isconvenient

The combination of the coding of defectsproposed for Severity and for Prioritymeans that defects can be coded ase.g.A1,C2,D4,etc.

7 Status

The status of a defect is an indication ofhow far the defect has progressed throughthe rectification process Status

classification will vary betweenorganisations, depending on the exactstructure of their processes. Typically, thestatus of a defect will take on one of thevalues given below, which are related to thedefect life history discussed earlier

Incident reported (user reports incident)

Confirmed (multiple instances

eliminated and repeatable defect typerecognised)

Classified by source (identified ashardware, software, operational, etc.)

Resolution in progress (i.e. responsibility

allocated for the necessary fix)

Scheduled for work

Work-around provided

Solution developed

Tested

Installed

Resolved

Defect types covered by the abovemodel include, under resolution inprogress ,corrections to documentationor the provision of user training, etc.

It is recommended that practitioners recordthe dates and times on which a defect sstatus changes in order that measures ofresponsiveness, such as Mean Time ToResolve (MTTR),may be derived.

8 Origin where detected

The origin of a defect, incident or failure is

the point at which it was first detected.There are three main stages of a softwarelife cycle where a defect is likely to bedetected.

These are:

During Development, Enhancement orCorrective Maintenance

During Testing

During Normal Operation

9 Source System Component

Any failure reported by users will beassociated by them with the applicationthey are using at the time the failurebecomes evident. Clearly however it ispossible that the defect causing the failuremay lie in another application, theoperating system, infrastructure software orthe hardware associated with any of these.

When a failure is reported an analysisshould be performed to allocate the defectto the correct defective component.

10 Source Module(s) Fixed

When a defect is resolved, the fix is appliedto (a)specific software component(s)ormodule(s).It is often useful to record thecomponent(s)or module(s)affected so thatdefect-prone modules can be identified andrebuilt or replaced.

The engineer who is responsible for the fixshould record this information.

11 Source Injection Stage

In addition to recording the componentwhere a failure is evidenced and the

module that must be fixed, it is also veryworthwhile to determine the specific lifecycle stage or activity in which the defectwas first introduced.

12 Root Cause

As noted above, a defect is the result of anerror. This causal error itself has some rootcause and it is sometimes of greatimportance to determine this.

The root cause can be classified as one ofthe following:

Objectives e.g. wrong terms ofreference, misunderstood goals, over-ambitious objectives

10718237.doc Page 2 of 3


3/3


Processes, tools and methods e.g. an

ineffective requirements gatheringprocess, an out-of-date riskmanagement process, non-scalableproject management method (e.g.having to use full blown PRINCE for arelatively small project),no estimatingprocess, an ineffective change controlprocess

People e.g. management requesting

that the project team cut corners, lackof training, inexperienced project team,poor morale or motivation

Failure of organisation orcommunication e.g. through lack of userinvolvement, poorly defined or agreedresponsibilities, failure of management,

Hardware e.g. processor bug that losesarithmetical precision, insufficient

memory

Software e.g. operating system bug that

doesn't release resources, bug in toolssoftware, bug in compiler,Y2K failure

Environment e.g. major organisationalchange, budget changes, strikes, noise,interruptions, poor work habitat

13 Estimated Cost Of Repair (ECOR)

The Estimated Cost Of Repair is usuallyexpressed as the staff effort (in hours ofproductive work)required to resolve aconfirmed defect.

The Estimated Cost Of Repair is typicallyrecorded at the time that a defect isclassified and responsibility for itsresolution is allocated.

14 Actual Cost Of Repair (ACOR)

The Actual Cost Of Repair is usuallyexpressed as the staff effort (in hours ofproductive work) expended in resolving aconfirmed defect. It is recorded after adefect is resolved and the fix installed. The

Actual Cost Of Repair should be inclusive ofall efforts expended from the time that thefirst related incident is reported to the timethat the defect is resolved.

10718237.doc Page 3 of 3

Documents

Doc 14 Characteristics of Defects