Sometimes I notice such a situation in various projects: team members spend their time to some activity that seems to be necessary but the result discovers to be incommensurate with the spent effort. Often, it’s not because the people but because of the process, work organization in the project. We start the series of White Papers devoted to the practical problems of the software testing process organization that my colleagues or I faced with and also innovations that we provided to cope with them. These White Papers will be useful for Test Managers and Project Managers as well as QA and Testing Specialists that are interested in their project development and feel strength to introduce innovations.
Team Leader of Network Testing Team
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.
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.
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.
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.