Defect Life cycel

What is a Bug Life Cycle?

The duration or time span between the first time bug is found (‘New’) and closed successfully
(status: ‘Closed’), rejected, postponed or deferred is called as ‘Bug/Error Life Cycle’.

(Right from the first time any bug is detected till the point when the bug is fixed and closed, it is
assigned various statuses which are New, Open, Postpone, Pending Retest, Retest, Pending
Reject, Reject, Deferred, and Closed. For more information about various statuses used for a bug
during a bug life cycle, you can refer to article ‘Software Testing – Bug & Statuses Used During
A Bug Life Cycle’)

There are seven different life cycles that a bug can passes through:

< I > Cycle I:

1) A tester finds a bug and reports it to Test Lead.
2) The Test lead verifies if the bug is valid or not.
3) Test lead finds that the bug is not valid and the bug is ‘Rejected’.

< II > Cycle II:

1) A tester finds a bug and reports it to Test Lead.
2) The Test lead verifies if the bug is valid or not.
3) The bug is verified and reported to development team with status as ‘New’.
4) The development leader and team verify if it is a valid bug. The bug is invalid and is marked
with a status of ‘Pending Reject’ before passing it back to the testing team.
5) After getting a satisfactory reply from the development side, the test leader marks the bug as
‘Rejected’.

< III > Cycle III:

1) A tester finds a bug and reports it to Test Lead.
2) The Test lead verifies if the bug is valid or not.
3) The bug is verified and reported to development team with status as ‘New’.
4) The development leader and team verify if it is a valid bug. The bug is valid and the
development leader assigns a developer to it marking the status as ‘Assigned’.
5) The developer solves the problem and marks the bug as ‘Fixed’ and passes it back to the
Development leader.
6) The development leader changes the status of the bug to ‘Pending Retest’ and passes on to the
testing team for retest.
7) The test leader changes the status of the bug to ‘Retest’ and passes it to a tester for retest.
8) The tester retests the bug and it is working fine, so the tester closes the bug and marks it as
‘Closed’.

< IV > Cycle IV:

1) A tester finds a bug and reports it to Test Lead.
2) The Test lead verifies if the bug is valid or not.
3) The bug is verified and reported to development team with status as ‘New’.
4) The development leader and team verify if it is a valid bug. The bug is valid and the
development leader assigns a developer to it marking the status as ‘Assigned’.
5) The developer solves the problem and marks the bug as ‘Fixed’ and passes it back to the
Development leader.
6) The development leader changes the status of the bug to ‘Pending Retest’ and passes on to the
testing team for retest.
7) The test leader changes the status of the bug to ‘Retest’ and passes it to a tester for retest.
8) The tester retests the bug and the same problem persists, so the tester after confirmation from
test leader reopens the bug and marks it with ‘Reopen’ status. And the bug is passed back to the
development team for fixing.

< V > Cycle V:

1) A tester finds a bug and reports it to Test Lead.
2) The Test lead verifies if the bug is valid or not.
3) The bug is verified and reported to development team with status as ‘New’.
4) The developer tries to verify if the bug is valid but fails in replicate the same scenario as was
at the time of testing, but fails in that and asks for help from testing team.
5) The tester also fails to re-generate the scenario in which the bug was found. And developer
rejects the bug marking it ‘Rejected’.
< VI > Cycle VI:
1) After confirmation that the data is unavailable or certain functionality is unavailable, the
solution and retest of the bug is postponed for indefinite time and it is marked as ‘Postponed’.

< VII > Cycle VII:

1) If the bug does not stand importance and can be/needed to be postponed, then it is given a
status as ‘Deferred’.

This way, any bug that is found ends up with a status of Closed, Rejected, Deferred or
Postponed.

Defects Status description

The main purpose behind any Software Development process is to provide the client (Final/End User of
the software product) with a complete solution (software product), which will help him in managing his
business/work in cost effective and efficient way. A software product developed is considered successful
if it satisfies all the requirements stated by the end user.

Any software development process is incomplete if the most important phase of Testing of the developed
product is excluded. Software testing is a process carried out in order to find out and fix previously
undetected bugs/errors in the software product. It helps in improving the quality of the software product
and make it secure for client to use.

What is a bug/error?
A bug or error in software product is any exception that can hinder the functionality of either the whole
software or part of it.

How do I find out a BUG/ERROR?

Basically, test cases/scripts are run in order to find out any unexpected behavior of the software product
under test. If any such unexpected behavior or exception occurs, it is called as a bug.

What is a Test Case?

A test case is a noted/documented set of steps/activities that are carried out or executed on the software
in order to confirm its functionality/behavior to certain set of inputs.

What do I do if I find a bug/error?

In normal terms, if a bug or error is detected in a system, it needs to be communicated to the developer in
order to get it fixed.

Right from the first time any bug is detected till the point when the bug is fixed and closed, it is assigned
various statuses which are New, Open, Postpone, Pending Retest, Retest, Pending Reject, Reject,
Deferred, and Closed.

(Please note that there are various ways to communicate the bug to the developer and track the bug
status)

Statuses associated with a bug:

New:
When a bug is found/revealed for the first time, the software tester communicates it to his/her team leader
(Test Leader) in order to confirm if that is a valid bug. After getting confirmation from the Test Lead, the
software tester logs the bug and the status of ‘New’ is assigned to the bug.

Assigned:
After the bug is reported as ‘New’, it comes to the Development Team. The development team verifies if
the bug is valid. If the bug is valid, development leader assigns it to a developer to fix it and a status of
‘Assigned’ is assigned to it.
Open:
Once the developer starts working on the bug, he/she changes the status of the bug to ‘Open’ to indicate
that he/she is working on it to find a solution.

Fixed:
Once the developer makes necessary changes in the code and verifies the code, he/she marks the bug
as ‘Fixed’ and passes it over to the Development Lead in order to pass it to the Testing team.

Pending Retest:
After the bug is fixed, it is passed back to the testing team to get retested and the status of ‘Pending
Retest’ is assigned to it.

Retest:
The testing team leader changes the status of the bug, which is previously marked with ‘Pending Retest’
to ‘Retest’ and assigns it to a tester for retesting.

Closed:
After the bug is assigned a status of ‘Retest’, it is again tested. If the problem is solved, the tester closes it
and marks it with ‘Closed’ status.

Reopen:
If after retesting the software for the bug opened, if the system behaves in the same way or same bug
arises once again, then the tester reopens the bug and again sends it back to the developer marking its
status as ‘Reopen’.

Pending Reject:
If the developers think that a particular behavior of the system, which the tester reports as a bug has to be
same and the bug is invalid, in that case, the bug is rejected and marked as ‘Pending Reject’.

Rejected:
If the Testing Leader finds that the system is working according to the specifications or the bug is invalid
as per the explanation from the development, he/she rejects the bug and marks its status as ‘Rejected’.

Postponed:
Sometimes, testing of a particular bug has to be postponed for an indefinite period. This situation may
occur because of many reasons, such as unavailability of Test data, unavailability of particular
functionality etc. That time, the bug is marked with ‘Postponed’ status.

Deferred:
In some cases a particular bug stands no importance and is needed to be/can be avoided, that time it is
marked with ‘Deferred’ status.

Report Defect
---------------------

As we already have discussed importance of Software Testing in any software development project (Just
to summarize: Software testing helps in improving quality of software and deliver a cost effective solution
which meet customer requirements), it becomes necessary to log a defect in a proper way, track the
defect, and keep a log of defects for future reference etc.

As a tester tests an application and if he/she finds any defect, the life cycle of the defect starts and it
becomes very important to communicate the defect to the developers in order to get it fixed, keep track of
current status of the defect, find out if any such defect (similar defect) was ever found in last attempts of
testing etc. For this purpose, previously manually created documents were used, which were circulated to
everyone associated with the software project (developers and testers), now a days many Bug Reporting
Tools are available, which help in tracking and managing bugs in an effective way.

How to report a bug?

It’s a good practice to take screen shots of execution of every step during software testing. If any test
case fails during execution, it needs to be failed in the bug-reporting tool and a bug has to be
reported/logged for the same. The tester can choose to first report a bug and then fail the test case in the
bug-reporting tool or fail a test case and report a bug. In any case, the Bug ID that is generated for the
reported bug should be attached to the test case that is failed.

At the time of reporting a bug, all the mandatory fields from the contents of bug (such as Project,
Summary, Description, Status, Detected By, Assigned To, Date Detected, Test Lead, Detected in
Version, Closed in Version, Expected Date of Closure, Actual Date of Closure, Severity, Priority and Bug
ID etc.) are filled and detailed description of the bug is given along with the expected and actual results.
The screen-shots taken at the time of execution of test case are attached to the bug for reference by the
developer.

After reporting a bug, a unique Bug ID is generated by the bug-reporting tool, which is then associated
with the failed test case. This Bug ID helps in associating the bug with the failed test case.

After the bug is reported, it is assigned a status of ‘New’, which goes on changing as the bug fixing
process progresses.

If more than one tester are testing the software application, it becomes a possibility that some other tester
might already have reported a bug for the same defect found in the application. In such situation, it
becomes very important for the tester to find out if any bug has been reported for similar type of defect. If
yes, then the test case has to be blocked with the previously raised bug (in this case, the test case has to
be executed once the bug is fixed). And if there is no such bug reported previously, the tester can report a
new bug and fail the test case for the newly raised bug.

If no bug-reporting tool is used, then in that case, the test case is written in a tabular manner in a file with
four columns containing Test Step No, Test Step Description, Expected Result and Actual Result. The
expected and actual results are written for each step and the test case is failed for the step at which the
test case fails.

This file containing test case and the screen shots taken are sent to the developers for reference. As the
tracking process is not automated, it becomes important keep updated information of the bug that was
raised till the time it is closed.

Contents of defect
---------------------
When a tester finds a defect, he/she needs to report a bug and enter certain fields, which helps in
uniquely identifying the bug reported by the tester. The contents of a bug are as given below:

Project: Name of the project under which the testing is being carried out.

Subject: Description of the bug in short which will help in identifying the bug. This generally starts with
the project identifier number/string. This string should be clear enough to help the reader in anticipate the
problem/defect for which the bug has been reported.

Description: Detailed description of the bug. This generally includes the steps that are involved in the
test case and the actual results. At the end of the summary, the step at which the test case fails is
described along with the actual result obtained and expected result.

Summary: This field contains some keyword information about the bug, which can help in minimizing the
number of records to be searched.

Detected By: Name of the tester who detected/reported the bug.

Assigned To: Name of the developer who is supposed to fix the bug. Generally this field contains the
name of developer group leader, who then delegates the task to member of his team, and changes the
name accordingly.

Test Lead: Name of leader of testing team, under whom the tester reports the bug.

Detected in Version: This field contains the version information of the software application in which the
bug was detected.

Closed in Version: This field contains the version information of the software application in which the
bug was fixed.

Date Detected: Date at which the bug was detected and reported.

Expected Date of Closure: Date at which the bug is expected to be closed. This depends on the severity
of the bug.

Actual Date of Closure: As the name suggests, actual date of closure of the bug i.e. date at which the
bug was fixed and retested successfully.

Priority: Priority of the bug fixing. This specifically depends upon the functionality that it is hindering.
Generally Medium, Low, High, Urgent are the type of severity that are used.

Severity: This is typically a numerical field, which displays the severity of the bug. It can range from 1 to
5, where 1 is high severity and 5 is the lowest.

Status: This field displays current status of the bug. A status of ‘New’ is automatically assigned to a bug
when it is first time reported by the tester, further the status is changed to Assigned, Open, Retest,
Pending Retest, Pending Reject, Rejected, Closed, Postponed, Deferred etc. as per the progress of bug
fixing process.

Bug ID: This is a unique ID i.e. number created for the bug at the time of reporting, which identifies the
bug uniquely.

Attachment: Sometimes it is necessary to attach screen-shots for the tested functionality that can help
tester in explaining the testing he had done and it also helps developers in re-creating the similar testing
condition.

Test Case Failed: This field contains the test case that is failed for the bug.

Any of above given fields can be made mandatory, in which the tester has to enter a valid data at the time
of reporting a bug. Making a field mandatory or optional depends on the company requirements and can
take place at any point of time in a Software Testing project.