A Model for Defect Life Cycle

A Model for Defect Life

Cycle

By Amir Ghahrai
December 2007
Initially posted on Testing Excellence

www.testingexcellence.com

Introduction

Finding defects and reporting defects are the main activities of the testing. In this
article I endeavor to explain the Software Defect Lifecycle and the Defect Process in
general. I will list all the activities for each stage of the process that are commonly
performed in a typical software testing environment.
Also, in this article, I have assumed that the development team have developed a
software application and is at least to a stage that is ready for testing.

The process is not leaning to any particular development model as I believe this
generic process is suitable for any development model. In other words, the process
in itself is generic for all development models; however, the amount of activities,
required inputs and produced outputs will depend on the type and complexity of the
application, organization’s view on testing and the structure of the project.

Defect Lifecycle

www.testingexcellence.com Page 1 of 4
A Model for Defect Life Cycle

Generally speaking, the defect life cycle is made up of four stages. (See Figure 1,
below).

Stage 1, defects are found and reported.

Stage 2, defects are reviewed and delegated.
Stage 3, defects are debugged and removed.
Stage 4, removed defects are confirmed.

Figure 1: Showing the four stages of the defect lifecycle indicated by dark curved arrows and
the activities performed at each stage (rectangles on the arrow). The inner circle indicates the
status of the defect at each stage of the defect lifecycle.
N.B. This model is only applicable to source code errors (that are decided to get fixed) and
not document errors.

Stage 1: Defects are found and reported by the testing team

(presumably)

Software released to testing

After the development team have developed the software and is ready for testing, the
software is then released to the testing team. Items released to testing generally
include Software Requirement Specification (SRS), Software Design Specification
(SDS), application source code (for code walkthroughs and inspections), executable
application and any third party libraries that may be required to make the application
work.

Testing team prepare and setup the testing environment; install the application and
any required third party libraries.

Testing team start testing

Once the application is installed, members of the testing team will start testing the

www.testingexcellence.com Page 2 of 4
A Model for Defect Life Cycle

application based on the Test Procedures. The activities may include Functional
Testing, Non-Functional Testing, Performance Testing, etc.

Defects may be found

During testing testers may find defects either in the application or in the documents
e.g. test procedure.
If a defect is found, either in the application (source code) or in the document, a
defect report form is filled and passed on to the test team lead or test manager for
review. (There is a detailed explanation on what to include in the defect form in this
article: Defect Reporting).

Defect Status: Open and Not Reviewed

Stage 2: Defects are reviewed and delegated

Defects get reviewed first by test team lead for any obvious mistakes by the testers,
such as missing information on the defect form (see Defect Reporting) and then
reported to software development manager for further review.
A meeting is scheduled which includes members of the development team and
testing team to discuss the validity, severity and priority of the defects.
At this stage, defects are categorized into three different states:

Not a defect
Defect will be fixed
Defect won’t be fixed in this release

Defect Status: Reviewed & Assigned

Stage 3: Defects are debugged and removed

Fixing defects
After the meeting and agreed actions, the software development manager delegates
defects to different developers in the team.
For defects that are not going to be fixed in the current version of the software, an
impact analysis must be performed to identify any potential failures that may occur as
a result of the existing defects in the system.
Developers will analyse the source code to identify the root cause and ultimately
remove the defect.

Defect Status: Being Debugged

Stage 4: Removed defects are confirmed

www.testingexcellence.com Page 3 of 4
A Model for Defect Life Cycle

Confirmation Testing and Regression Testing

The “Fixed” version of the software will be released to the testing team and testers
will start to test the “fixed” software. At this stage, two types of testing are performed
by the testers: confirmation testing and regression testing.

Based on the outcome of the confirmation testing, the “fixed” defects are either
confirmed as fixed (defect is removed) or not fixed (defect still exists).

For defects that are fixed, their status is changed to fixed and can be closed.

For defects that are not fixed, i.e. they still exist in the system, they go round the
cycle again, i.e. are reported to the development team, gets reviewed by the
development team, faults are removed, a new version of software is released to
testing for confirmation + regression testing and so on.

This cycle is repeated until all the defects (that were decided to be fixed in the current
version) are fixed and verified by testers.

Defect Status: Fixed & Closed

The model explained above is a generic model explaining the defect lifecycle. Defect
management is an important aspect of software testing and if managed properly it
should reduce a lot of overheads. Following a defined lifecycle can help in managing
the defect process and increase the productivity of the testing team.

www.testingexcellence.com Page 4 of 4