Defect

Management
Defect Management is the process of recognizing and
recording defects, classifying them, investigating them,
taking action to resolve them, and disposing of them
when resolved

An organization’s defect management process and the

tool used to manage this work are of critical

importance:

Information gathered by effective management of

defects allows to gain insight on the state of a project

throughout the development lifecycle

By collecting and analyzing data over time, this can

help locate areas of potential improvement for testing

and development processes

The Test Manager must:

be familiar with what data is critical

to capture

be an advocate of proper usage of

both the process and the selected

defect management tool

Organizations should:

establish a defect management process which includes a

workflow and rules for classification

define standards while other might track defects

informally

Testers should attempt to minimize the number of false

positives reported as defects as some reports may describe

false positives

Defects found during testing should be logged

Typical defect reports have the following objectives:

Provide developers and other parties with information

about any adverse event that occurred

enables to identify specific effects and to isolate the

problem with a minimal reproducing test

enables to correct the potential defect(s) as needed

or to otherwise resolve the problem

Provide test managers a means of tracking:

the quality of the work product

the impact on the testing

Provide ideas for development and test process

improvement

When logging defects, you should consider:

the context or component/system under test

the test level

the software development lifecycle

Defects may be reported during:

coding

static analysis

reviews

dynamic testing

use of a software product

Defects may be reported for issues in:

code or working system

documentation

requirements

user stories

development or test documents

user manuals or installation guides

Any defects identified should be investigated and

should be tracked from discovery and classification to
their resolution.

Dynamic defect reports may sometimes differ. Defects

found during static testing (particularly reviews) will

be documented in a different way.

An example of contents of a defect report can be found

in ISO standard (ISO/IEC/IEEE 29119-3) and refers to

it as incident reports

The defect management tools used may automatically

manage and fill in some details

Defect report = Documentation of the occurrence, nature,

and status of a defect.

Whatever the specific information determined as necessary

for defect reports, it is critical that testers enter

information that is complete, concise, accurate,

objective, relevant and timely.

Defect report filed during dynamic testing includes:

Identifier Title

Short Summary

Date Organization Author

Item tested Environment Test Phase

Severity Priority Status

Expected Results Actual Results

Description of the issue

to enable reproduction and resolution
includes logs, dumps, screenshots, recordings

Other aspects
Conclusions, recommendations and approvals
References (ex: test case that revealed the issue)
Other areas that may be affected
Defect change history
When a defect is detected (static testing), or a failure is

observed (dynamic testing) data should be gathered by the

person(s) involved and included in the defect report.

Information from a defect report should suffice for:

1. Management of the report

2. Assessment of project status (terms of product quality

and test progress)

3. Assessment of process capability

Core information gathered should be consistent across the

lifecycle and ideally across all projects in order to  allow

for meaningful comparison of process

defect data within and across all projects.

Defect data may also include the following (on top of the

already presented data for a Defect Report)

The role of the author (end user, tester, business

analyst, technical support, etc.)

Type of testing performed (usability, performance,

regression, etc.)

Sub-system or component where the issue lies besides

the System under test

Project activity occurring when the issue was found

Type of defect (based on defect taxonomy)

Quality characteristics affected by the defect

Project or product in which the problem lies

Current owner (assignee)

Business Impact

Risks, costs, opportunity and benefits for fix/no fix

Description of how the defect was resolved

Defect information should support:

defect density analysis

trend analysis of defects detected and resolved

average time from defect detection to resolution

failure intensity like mean time between failures

Even though the collection of data can assist in:

test progress monitoring

control

exit criteria evaluation

There can be a lot of challenges in properly assessing

project status, test progress and process capability when

defect report data is of low quality and not

properly managed.

Various standards as ISO 9126 being replaced by ISO

25000, IEEE 829, IEEE 1044 and Orthogonal Defect

Classification exist to help the Test Manager determine

which information to gather for defect reporting.

Defects are introduced when a person makes a mistake

during the creation of a work product:

requirements specification

a user story

a technical document

a test case

the program code

any other work product produced during a software

development or maintenance process