A Bug s Life Cycle

A Bug's Life Cycle

In entomology (the study of real, living bugs), the term life cycle refers to the various stages that an insect undergoes over its life. If you think back to your high school biology class, you'll 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. A software bug's stages don't exactly match a real bug's, but the concept is the same. Figure 19.2 shows an example of the simplest, and most optimal, software bug life cycle.

Figure 19.2. A state table shows that a software bug has a life cycle similar to an insect.

This example shows that when a bug is first found by a software tester, a report is logged and assigned to a programmer to be fixed. This state is called the open state. Once the programmer fixes the code, he assigns the report back to the tester and the bug enters the resolved state. The tester then performs a verification test to confirm that the bug is indeed fixed and, if it is, closes the report. The bug then enters its final state, the closed state.

In many instances, this is as complicated as a software bug's life cycle gets: a bug report is opened, resolved, and closed. In some situations, though, the life cycle gets a bit more complicated, as shown in Figure 19.3.

Figure 19.3. A bug's life cycle can easily become very complicated if the bug-fixing process doesn't occur as smoothly as expected.

In this case, the life cycle starts out the same with the tester opening the bug report and assigning it to the programmer, but the programmer doesn't fix the bug. He doesn't think it's bad enough to fix and assigns the report to the project manager to decide. The project manager agrees with the programmer and places the bug report in the resolved state as a "won't-fix" bug. The tester disagrees, looks for and finds a more obvious and general case that demonstrates the bug, reopens the report, and assigns it to the project manager. The project manager, seeing the new information, agrees and assigns it to the programmer to fix. The programmer fixes the bug, resolves it as fixed, and assigns the report to the tester. The tester confirms the fix and closes the bug report.

You can see that a bug might undergo numerous changes and iterations over its life, sometimes looping back and starting the life cycle all over again. Figure 19.4 takes the simple model of Figure 19.2 and adds to it the 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 you'll encounter.

Figure 19.4. This generic bug life-cycle state table covers most of the possible situations that can occur.

This generic life cycle has two additional states and extra connecting lines. The review state is where the 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 they're 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 shouldn't be fixedit could be too minor, is really not a problem, or is a testing error. The other added state is deferred. The review may determine that the bug should be considered for fixing at some time in the future, but not for this release of the software.

The additional line from the resolved state back to the open state covers the situation where the tester finds that the bug hasn't been fixed. It gets reopened and the bug's life cycle repeats. The two dotted lines that loop from the closed state and the deferred state back to the open state rarely occur but are important enough to mention. Since a tester never gives up, it's possible that a bug that was thought to be fixed, tested, and closed could reappear. Such bugs are often called regressions. It's also possible that a deferred bug could later be proven serious enough to fix immediately. If either of these situations 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. What's important is that once you log a bug, you follow it through its life cycle, don't lose track of it, and provide the necessary information to drive it to being fixed and closed.