What is a Defect Life Cycle or a Bug lifecycle in

software testing?
Defect life cycle is a cycle which a defect goes through during its lifetime. It starts when defect
is found and ends when a defect is closed, after ensuring its not reproduced. Defect life cycle is
related to the bug found during testing.
The bug has different states in the Life Cycle. The Life cycle of the bug can be shown
diagrammatically as follows:

Bug or defect life cycle includes following steps or status:

1. New
When the bug is identified and logged in bug tracking tool for the first time, its state will be
"NEW".
2. Open / Closed
After a QA has posted a bug, the QA lead validates the bug. If bug is valid then he changes
the state as "OPEN" and if the bug is invalid then the lead changes its state to "CLOSED".
3. Assign
After QA lead changes the state as "OPEN", he assigns the bug to corresponding developer
or developer team lead and the bug status is changed to "ASSIGN".
4. Rejected:
If the developer feels that the bug is not valid or it has some technical limitations and cannot
be fixed, he rejects the bug. He changes the state of bug to "REJECTED".
5. Duplicate:
If the bug is logged is repeated twice or the two bugs reported has alike results and steps to
reproduce, then one bug status is changed to "DUPLICATE".
6. Deferred:
If the development team lead decides to fix the bug in next release due to lack of time or the
priority of the bug is low then he changes the state to "DEFERRED", which is later changes to
"ASSIGN" when the bug is taken in consideration to be fixed.
7. InTest
Once the developer fixes the bug, he assigns the bug to the testing team for next round of

testing. Before that he changes the state of bug to "IN TEST". It specifies that the bug has been
fixed and is released to testing team.
8. Verified
Once the bug is fixed and the status is changed to "IN TEST", the tester tests the bug. If the
bug is not reproducible in the software, he changes the status to "VERIFIED".
9. Reopened
Once the bug is fixed and the status is changed to "IN TEST", the tester tests the bug. If the
bug is reproducible in the software, he changes the status to "REOPENED".
10. Closed
After the bug status is changes to "REJECTED" or "DUPLICATE" or "VERIFIED" the QA
Lead verifies the comments added by the development or Testing team. When he is satisfied
with the comments he changes the state to "CLOSED".

Test Plan
TEST PLAN DEFINITION
A Software Test Plan is a document describing the testing scope and activities. It is the basis for
formally testing any software/product in a project.
ISTQB Definition

test plan: A document describing the scope, approach, resources and schedule of intended test
activities. It identifies amongst others test items, the features to be tested, the testing tasks,
who will do each task, degree of tester independence, the test environment, the test design
techniques and entry and exit criteria to be used, and the rationale for their choice,and any risks
requiring contingency planning. It is a record of the test planning process.
master test plan: A test plan that typically addresses multiple test levels.
phase test plan: A test plan that typically addresses one test phase.

TEST PLAN TYPES

One can have the following types of test plans:

Master Test Plan: A single high-level test plan for a project/product that unifies all other test
plans.
Testing Level Specific Test Plans:Plans for each level of testing.
o Unit Test Plan
o Integration Test Plan
o System Test Plan
o Acceptance Test Plan
Testing Type Specific Test Plans: Plans for major types of testing like Performance Test Plan and
Security Test Plan.

TEST PLAN TEMPLATE

The format and content of a software test plan vary depending on the processes, standards, and
test management tools being implemented. Nevertheless, the following format, which is based on
IEEE standard for software test documentation, provides a summary of what a test plan
can/should contain.

IT Solutions
Project Name
Product Name
Product Release Version

PDES
Feedback System
3.2.1

Master Test Plan

Document Version: 1.1
Date: 07/08/2013
Prepared By: Mr. Sachin M

Test Plan Identifier:

Provide a unique identifier for the document. (Adhere to the Configuration Management System
if you have one.)

Introduction:

Provide an overview of the test plan.

Specify the goals/objectives.
Specify any constraints.

References:

List the related documents, with links to them if available, including the following:
o Project Plan
o Configuration Management Plan

Test Items:

List the test items (software/products) and their versions.

Features to be Tested:

List the features of the software/product to be tested.

Provide references to the Requirements and/or Design specifications of the features to be
tested

Features Not to Be Tested:

List the features of the software/product which will not be tested.

Specify the reasons these features wont be tested.

Approach:

Mention the overall approach to testing.

Specify the testing levels [if it's a Master Test Plan], the testing types, and the testing methods
[Manual/Automated; White Box/Black Box/Gray Box]

Item Pass/Fail Criteria:

Specify the criteria that will be used to determine whether each test item (software/product)
has passed or failed testing.

Suspension Criteria and Resumption Requirements:

Specify criteria to be used to suspend the testing activity.

Specify testing activities which must be redone when testing is resumed.

Test Deliverables:

o
o
o
o
o

List test deliverables, and links to them if available, including the following:
Test Plan (this document itself)
Test Cases
Test Scripts
Defect/Enhancement Logs
Test Reports

Test Environment:

Specify the properties of test environment: hardware, software, network etc.

List any testing or related tools.

Estimate:

Provide a summary of test estimates (cost or effort) and/or provide a link to the detailed
estimation.

Schedule:

Provide a summary of the schedule, specifying key test milestones, and/or provide a link to the
detailed schedule.

Staffing and Training Needs:

Specify staffing needs by role and required skills.

Identify training that is necessary to provide those skills, if not already acquired.

Responsibilities:

List the responsibilities of each team/role/individual.

Risks:

List the risks that have been identified.

Specify the mitigation plan and the contingency plan for each risk.

Assumptions and Dependencies:

List the assumptions that have been made during the preparation of this plan.
List the dependencies.

Approvals:

Specify the names and roles of all persons who must approve the plan.
Provide space for signatures and dates. (If the document is to be printed.)

TEST PLAN GUIDELINES

Make the plan concise. Avoid redundancy and superfluousness. If you think you do not need a
section that has been mentioned in the template above, go ahead and delete that section in
your test plan.
Be specific. For example, when you specify an operating system as a property of a test
environment, mention the OS Edition/Version as well, not just the OS Name.
Make use of lists and tables wherever possible. Avoid lengthy paragraphs.
Have the test plan reviewed a number of times prior to baselining it or sending it for approval.
The quality of your test plan speaks volumes about the quality of the testing you or your team is
going to perform.
Update the plan as and when necessary. An out-dated and unused document stinks and is worse
than not having the document in the first place.