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 |
Table 1
Testers work through test cases or plans to identify flaws in the software. They record any bugs they find with steps to reproduce and as much detail as possible. When the bugs come back marked "fixed," testers have to repeat the process and verify that the bug is indeed eradicated. If the issue is resolved, then the bug can be closed.
Project managers review the bug reports that come in, decide on the priority, and assign them to developers to be fixed. Depending on the project, they may assign directly on an ongoing basis or assign batches to groups of developers. Using the Scrum methodology, for example, bugs are organized into sprint backlogs and the team tackles them during pre-planned windows of time. Persistent bugs can end up spanning several sprints.
Developers investigate the bugs they are assigned, fix them, and then pass them off to testers for verification. If they dispute a bug report or require more detail, they can talk directly to testers or project leads.
Those roles are not set in stone, but they are typical. Though, it is worth mentioning that anyone on the team—not just testers—can submit a bug if they find one. The bug lifecycle is influenced by how closely the test team works with the development team.
It is always better when the two teams are located on the same site because they can communicate face to face if necessary. If the developer can ask the tester to show him a bug or explain why he doesn't consider a specific bug to be an issue, then the whole project runs more smoothly. Embedded test teams are considered part of the development team, and they will typically work much more closely with developers, whereas independent testing teams have a separate chain of command. This can influence how bugs are reported and dealt with. If the test team is offsite, then the bug management system is vital for communication, and bug reports or developer notes really have to be detailed and concise to ensure smooth sailing.
Useful Tools to Handle the Bug Lifecycle
There are some excellent software tools out there that can enable efficient and accurate testing while minimizing wasted time for testers, developers, and project managers. Let's take a look at a few examples.
Bug Management Tools
Having a central repository or database that stores all of your bug reports is vital. If you select the right bug management software, you can set up relevant permissions for staff and create a trail that records the bug lifecycle as it is reported, prioritized, assigned, discussed, fixed, and eventually closed.
At each stage of the process, the status of an individual bug is clearly marked and team members can filter the results to find bug reports that require their attention and update them as necessary. The bug-tracking system is an essential communication channel, especially if the testing team and development team are not working in the same location.
Any list of the most popular bug management systems should include Bugzilla, JIRA, Assembla, Redmine, Trac, OnTime, and HP Quality Center. Bugzilla, Redmine, and Trac are freely available, open source software, while Assembla and OnTime are offered in the form of software as a service. All of these options support manual bug entry, but Bugzilla, JIRA, and HP Quality Center also support some kind of API so that you can plug in third-party tools in order to enter new bug reports.
Integration of bug-tracking software with project management solutions or test management software is very common. This enables project leads to maintain an overview of the whole project, and it enables development to proceed in tandem with testing. It sometimes makes sense to treat bugs the same way you would treat a new user story or a development task because they can all be assigned and prioritized and they each require a relevant status and a due date. Solutions like Assembla, Microsoft's Team Foundation Server, or IBM's Rational Team Concert can actually combine bug tracking and management with requirements, project, change, configuration, build, and release management.
Invaluable Software Utilities
The bug-tracking system equips your team with everything they need to work through a typical bug lifecycle, but some extra help is always welcome. Tools that empower testers to enter concise bug reports enable developers to reproduce and fix those bugs more quickly and efficiently. A really good bug report won't require further communication or follow-up questions, and that gives testers more time to test and developers more time to fix bugs.
To explain a typical bug in text form can actually be quite difficult. By missing just one important element, the tester can leave the developer in the dark, unable to reproduce a bug and therefore unable to discover a fix.
By using tools that capture the tester's screen, record his actions, and even record videos of him reproducing bugs, the risk of incomplete or poor bug descriptions can be mitigated.
Screen Capture Tools
The ability to grab a screenshot of each pertinent step in a bug is a must for testers. The resulting bug reports will be much clearer, and the developer's chances of reproducing the bug without further assistance will be much higher. The screenshots can be attached directly to the bug report in the management system.
There are a lot of screen-capture tools to choose from, including SnagIt, Jing, Snipping Tool, RoboScreenCapture, ScreenHunter, FastStone Capture, TNT Screen Capture, and MadCap Capture. The majority of these utilities also allow testers to grab a screenshot of a specific area of the screen, an active window, or the whole screen. The screenshots are saved as image files, and most tools support a range of common formats.
User Action or Video Recording Tools
For complex bugs with many steps to reproduce, the screen capture method can be lengthy and inefficient, and the bug report may still rely on a lot of text description. Being able to record every step in the process with a tool keeps things as clear as possible, and the developer can access a step-by-step report or a video file that leaves nothing out.
Some great tools that capture every user action and record them as steps include qTrace, Problem Steps Recorder, and KeyLogger. If videos are preferred, then Jing, CamStudio, SnagIt, and ScreenCam will all do the trick.
These tools can seriously speed up the bug-fixing process, and they actually make life easier for the tester, developer, and project manager.
Reap the Rewards
The typical bug lifecycle is a process that demands the attention of multiple staff members. If testers have to spend a lot of time writing up bug reports, answering queries, and reproducing bugs for developers, then they are spending less time finding bugs. There are many solutions out there—far more than those mentioned in this article—so take advantage and keep your bug lifecycle under control.
