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.

Bug Life cycle: In entomology(the study of real, living Bugs), the term life cycle refers to the various stages that an insect assumes over its life. If you think back to your high school biology class, you will remember that the life cycle stages for most insects are the egg, larvae, pupae and adult. It seems appropriate, given that software problems are also called bugs, that a similar life cycle system is used to identify their stages of life. Figure 18.2 shows an example of the simplest, and most optimal, software bug life cycle.

This example shows that when a bug is found by a Software Tester, its logged and assigned to a programmer to be fixed. This state is called open state. Once theprogrammer fixes the code , he assigns it back to the tester and the bugs enters the resolved state. The tester then performs a regression test to confirm that the bug is indeed fixed and, if it closes it out. The bug then enters its final state, the closed state. In some situations though, the life cycle gets a bit more complicated. In this case the life cycle starts out the same with the Tester opening the bug and assigning to the programmer, but the programmer doesnt fix it. He doesnt think its bad enough to fix and assigns it to the project manager to decide. The Project Manager agrees with the Programmer and places the Bug in the resolved state as a wont-fix bug. The tester disagrees, looks for and finds a more obvious and general case that demonstrates the bug, reopens it, and assigns it to the Programmer to fix. Theprogrammer fixes the bg, resolves it as fixed, and assign it to the Tester. The tester confirms the fix and closes the bug.

You can see that a bug might undergo numerous changes and iterations over its life, sometimes looping back and starting the life all over again. Figure below takes the simple model above and adds to it possible decisions, approvals, and looping that can occur in most projects. Of course every software company and project will have its own system, but this figure is fairly generic and should cover most any bug life cycle that youll encounter

The generic life cycle has two additional states and extra connecting lines. The review state is where Project Manager or the committee, sometimes called a change Control Board, decides whether the bug should be fixed. In some projects all bugs go through the review state before theyre assigned to the programmer for fixing. In other projects, this may not occur until near the end of the project, or not at all. Notice that the review state can also go directly to the closed state. This happens if the review decides that the bug shouldnt be fixed it could be too minor is really not a problem, or is a testing error. The other is a deferred. The review may determine that the bug should be considered for fixing at sometime in the future, but not for this release of the software. The additional line from resolved state back to the open state covers the situation where the tester finds that the bug hasnt been fixed. It gets reopened and the bugslife cycle repeats. The two dotted lines that loop from the closed and the deferred state back to the open state rarely occur but are important enough to mention. Since a Tester never gives up, its possible that a bug was thought to be fixed, tested and closed could reappear. Such bugs are often called Regressions. Its possible that a deferred bug could later be proven serious enough to fix immediately. If either of these occurs, the bug is reopened and started through the process again. Most Project teams adopt rules for who can change the state of a bug or assign it to someone else.For example, maybe only the Project Manager can decide to defer a bug or only a tester is permitted to close a bug. Whats important is that once you log a bug, you follow it through its life cycle, dont lose track of it, and prove the necessary information to drive it to being fixed and closed.