defect life cycle

Contents • Defect Main Process Flows

• What is Defect Life Cycle?

• Defect Detailed Workflows

• Status Definitions

1

Defect Management Main Process Flows

2

The overall process flow divides out into the four main process steps shown below

New Validate Assigned

Fixed Deployed

Ready

For

Retest

Open

Resolved

Closed

2. Triage 1.Identification

3. Fix 4. Retest

WIP

In Test

What is Defect Life Cycle? Defect Life Cycle is a systematic process for dealing with defects

found in a software. Defects change various states from its origin to its closure, and are taken care by various teams.

3

This colour section and the status blocks used to denote that the Defect is with triage team for further analysis.

This colour status blocks used to denote that the Defect is found and raised or got re-occurred.

This colour status blocks used to denote that no further action require on the defect as it is marked as Duplicate or got Cancelled.

Defect Triage

New defect

No further action

Development This colour section and the status blocks used to denote that the Defect is with development team for fixing.

Release Management

This colour section and the status blocks used to denote that the Defect got fixed and with the release management team for deployment.

Testing Team This colour section and the status blocks used to denote that the Defect got deployed to the test environment and under test.

Defect Lifecycle and Status Transition

4

Validate

Duplicate

Tria

ge T

eam

Open

Assigned

Rejected

Cancelled

Dev

elo

pm

en

t T

eam

WIP

Fixed

Testin

g Team

Return

Deployed

Deployment Team

Ready for Retest

In Test

Resolved

Closed

Closed New Open New

Deferred

Change Control

Step 1 - Identification

Step 2 - Triage Step 3 - Fix Step 4 - Retest

Failed

Step 1 - Identification

5

Step 1 -

Identification

Execute Test

Script

Record

Actual

Results

Is it as

Expected

Mark test

script as

“Passed”

Mark test

script as

“Failed”

Log a Defect

in HP ALM

Defect Status

“New”

Step 2 -

Triage

Yes

No

Step 2 - Triage – Level 1

6

Defect Status updated

to “Validate”

Is it a Valid

Defect?

Defect status Updated

to “Cancelled”

No

Yes

Is it already

raised?


to “Duplicate”

Yes


to “Open”

No

Triage – Level 1

Triage – Level 2


7

Defect Status is “Open”

Is it

found to be a

Valid

Defect?

Defect Assigned to defect co-

ordinator with the analysis in

defect comments.

No

Yes

Is it

in scope of

current release?


to “Deferred”

No

Yes

Triage – Level 2

Development, Solution

and Environment Leads

analyse the defect

Defect is re-validated by Test

Lead with the help of Business

Analyst

Agreed? No


to “Rejected”

Yes

Is it

as per the current

Requirement?

Yes

Triage – Level 3


to “Assigned”

Solution Owner/Business

Analyst review the

defect.

No


to “Change Control”

Is

Change Request

Raised?

Yes

No


8

Defect Status is

“Assigned”

Is it

found to be a

Valid

Defect?

Defect Assigned to defect co-

ordinator with the analysis in

defect comments.

No

Yes

Triage – Level 3

Development Team

further analyse the

defect

Defect is re-validated by Test

Lead with the help of Business

Analyst

Agreed? No


to “Rejected”

Yes

Is

Any further input

required?

No

Development team able to

reproduce the issue and

making progress on fix

Defect status updated to

“Return” and assigned to

Test Analyst.

Yes

Defect updated by the

Test Analyst and assign

back to development

team


to “WIP”

Step 3 - Fix

Step 3 - Fix

9

Fix Defect

WIP

De

fect

St

atu

s

Require

more

details?

No

Return

Yes

Fixed Defect

Fixed

Review Changes

Deployed

Deploy Fix In Test

Env

Ready for Retest

Ste

p 4

Re

-Test

Deployment or Release Team

Development Team

Step 4 - Retest Defect Status updated

to “Ready for Retest” Step 4

Re-Test

Type

of Build or defect

fixed provided?

System build or

Main release build Patch Fix

Deployed

Defect status is “In Test” and

assigned to Tester for retesting

Defect status is “In Test” and

assigned to Tester for retesting

Retest

result

Passed?

Retest

Result

Passed?

Defect will be

“Closed” and “New”

defect will be raised

No No

Defect co-ordinator validate and

update the status as “Open”

providing ref of original defect

Step 3 -

Fix

Yes Yes

Defect status updated

to “Passed in Patch”

Regression performed after

Main release or build

Regression

result?

Passed Defect status updated

to “Closed” with no

further action

Step 1 -

Identification

Defect will be “Closed” and

“New” defect will be raised

Defect status updated

to “Resolved”

Defect co-ordinator

update the defect

comments and release

End of

Process

Failed

Definition of Defect Status

11

New

When a defect is identified it is raised with “New” status. Generally a defect is raised by the testing team. However, during unit testing and system testing it will also be raised by the development team to keep a track of the identified defect at every phase of testing. In case of any failure in defect re-test the orignal defect will get closed and “New” defect will be raised.

Validate

Defect co-ordinator and test leads validate the defect and ensure that all the require details has been captured on the defect. To acknowledge the defect status updated as “Validate”. Once all the require details has been captured then it is ready for discussion during defect triage meetings.

Open

After initial triage discussion the defect status updated to “Open” and will be assigned to development lead for further analysis. Also this status is used when any re-test got failed. New defect will be raised and makred as “Open” after updating the reference of the orignal defect.

12

Defect can be marked as “Duplicate” by the defect co-orinator if there is already an outstanding defect exist for the same issue or problem. Defect is marked with the orignal defect id before marking it as duplicate.

Duplicate

Defect can be marked as “Cancelled” it has been raised in error and no further action require. Cancelled defect normally does not included in the defect triage discussion. Cancelled

Development leads after performing initial analysis can request defect co-ordinator to mark the defect as “Rejected” if it is working according to the requirement documents and design specifications. However this status will only be used in the circumstances where there is disagreement between development and testing team with respect to difference in understanding the requirements. In some scenario it may require design leads and solution owner to get involved and provide their feedback on the analysis and description mention by testing and development team.

Rejected

Assigned

Development lead update the status to “Assinged” after they have got all the requrie details to identify the problem area. This status is also used if it needs to assigned back to defect co-ordinator for any further action by mentioning their analysis summary in the comment section of the defect.

WIP Defect status updated as “WIP” (Work In Progress) after the devlopment team starts working on the defect fix.

13

Defect can be marked under “Change Control” if it has been raised to report any issue or problem which has not been build or not included in the requirements or design specifications. It can only be marked under change control after it got agreed with the solution owner and to build and test that functionality Change Request (CR) need to be raised.

Change Control

Fixed Once the defect has been resolved in the development environment, developer mark the defect as “Fixed”. However the defect still not ready for deployed by release team.

Release or deployment team update the defect status as “Deployed” after the code fix has been made available in the testing environment. All the defect will be assigned to defect co-ordinator along with the release notes.

Deployed

Valid defects for which the deployment or fix will be made available in future releases are marked with status as “Deferred” and mentioning the appropriate reason in the comment section of the defect.

Deferred

Defect co-ordinator updated the status as “Ready for Retest” and assign those defects to test team for re-testing the functionality.

Ready for Retest

Defect status “Return” is used by the development team during there code fix if they need any further details from the testing team or wanted to get the workaround tested before they provide actual fix.

Return

14

Testing team leads update the status of defects that are under re-test as “In Test”. We need this intermediate status for the scenarios where it took more than a day to reach to the point of defect re-test.

In Test

Tester update the defect status to “Resolved” after it got successfully re-tested and assigned it to defect co-ordinator. In case of patch approach the defect Status changes to “Resolved” until all patches consolidated into System build and go through regression test and passed.

Resolved

Closed The final status of any defect that when through the complete defect life cycle is Closed. However this status is used in both the cases if the defect got re-tested by testing team irrespective of the re-test outcome.

Defect fixes that will be made through patch release will be marked as “Passed in Patch” on successful retest. However they will be only marked as closed until all patches consolidated into System build (Main release) and go through regression test and passed.

Passed in Patch

Failed Defect status “Failed” is only used in the situation where retesting failed. Tester will assign the defect in “Failed” status which will be closed by defect coordinator after providing reference to new defect.

defect life cycle

Software