White Papers
7 Ways to Improve Testing Process: 1. Bug Tracking Work
- Details
- Created on Thursday, 12 January 2012 14:12
Written by:
Tatiana Kit,
Team Leader of Network Testing Team
Goal:
At each moment, each project team member must see the list of the bugs that must be fixed for the next release.
How it was:
Generally, the bug tracking scheme is a well-established idea, which differs only in some details. Our bug tracking scheme is as follows:
- Testers open all new bug reports with the New status.
- The developer, when starts working on the bug, change its status to Open.
- When bug is fixed, the developer changes its status to Please check.
- Tester checks: if the bug is fixed the bug report status if changed to Closed, otherwise – to New.
Problem:
Too many bugs with New status were accumulating.
“Many” is about 500 bug reports and more. It does not mean that the project is bad, but only that it is big, complicated and long-term. A lot of bugs had low priority, and we were also adding feature requests and small improvements to the bug tracking system. Usually, we did not have enough time for the major part of them and they were accumulating. Not to write them at all is not a good solution, as it’s better to fix a low-priority bug later than never. And moreover, priorities can change.
A huge number of bug reports meant wasting time on searching for the needed report. We had to compose the lists of actual bugs for each release and send them by email bypassing bug tracking system. These lists had to be updated all the time and it took considerable time.
Solution:
We started to use one more status Postponed.
All new bug reports and feature requests that won’t be included to this release are created with the Postponed status. Critical bugs and features for this release have the New status. We work with them as before. The status of a bug report can be changed at each moment. Testers write bug reports as usual, but at the end of the day, test manager or project manager looks through the new bugs discovered during this day and changes their status if required. Usually it takes about 10 minutes.
After the release, team reviews the list of bugs and improvements with the Postponed status and prepares the list for the next release; chosen reports obtain the New status.
Benefits:
Each project member, at each moment, can see the work scope for the current release and can answer the question from the managers or clients: “What we need to do for the release?”
Surely, it’s not a revolutionary idea, but it helped us to get rid of some boring and time consuming work.
