Software testing, despite the name, is about more than just testing software. It is obviously important to identify as many bugs as possible, but finding the bugs is only half the battle. Every bug that is found has to be recorded accurately and in such a way that the developer responsible for fixing it will be able to reproduce the problem. All of the bugs identified must be added to a database, tracked, assigned, fixed, and eventually closed. Communication must be clear, bugs must be well described and categorized so that management can assign them correctly, and every fix necessitates a verification process.
The complete lifecycle of a bug can be lengthy. From identification through to a verified fix, the process can require the attention of testers, developers, project managers, and team leads. The expectations of end-users and senior management are often unrealistic with regard to the time and resources required to test software properly.
Let's take a look at the lifecycle of a typical bug and discuss some of the types of software tools that can be used to ensure the process is smooth and efficient.
A Typical Bug Lifecycle
The flow chart in figure 1 gives you some idea of the process that unfolds when a bug is identified. It is based on personal experience with various testing teams, so it's not representative of every bug process. But, it is a typical cycle for a bug in software testing.
Figure 1: Flowchart of a typical bug lifecycle
If you take a look at table 1, you’ll see a more detailed breakdown of the activities at each stage and the staff members who are likely to be involved. There are three distinct groups—testers, developers, and project managers or leads.
|Typical Bug Lifecycle Activities||People Involved|
|1. Execute tests.||Tester|
|2. If a bug is found, the tester records and submits the bug to a bug management system, such as Bugzilla. The bug status is set to new.||Tester|
|3. The project team reviews and decides whether to fix the bug. If yes, a developer is assigned to fix the bug. The bug status is set to in progress, under investigation, or another similar term.||Project lead, project manager|
|4. The developer investigates and reproduces the bug by repeating the steps described in the bug report.||Developer|
|5. If the bug is reproduced successfully, the developer proceeds to fix. He may ask for more information from the tester. Once the bug is fixed, the developer changes its status to fixed. Otherwise, the developer gets the bug back to the tester for more elaboration, and the bug status is changed to open.||Developer|
|6. The tester elaborates the bug by providing further description for the bug or using a bug-reporting tool to generate more information about the bug.||Tester|
|7. The tester verifies the fix by executing the steps described in the bug report.||Tester|
|8. If the fix is verified, then the tester closes the bug and the bug status is set to closed. Otherwise, the bug status is changed to open. The tester may provide further explanation on the bug.||Tester|