| Each
bug report represents hours -- maybe even days -- of work. It's important company data,
which should be well protected and well organized. Bug reports should be recorded in a
database that is backed up on a daily basis. A system, such as PR-Tracker, should manage that database.
Here are some guidelines for effective bug tracking. 1. Make a build of the software daily
Bug tracking works best in an environment where there is a daily build. This enables
testers to test the most recent version of software so that they aren't reporting bugs
that have already been fixed. They are also discovering newly introduced bugs quicker
while the code is still fresh in the mind of the developers that introduced them.
2. Use build numbers
When applicable, build numbers should be used to specify what version of software a bug
was found in, what version it was fixed in, and what version a fix was verified in.
Revision numbers of source code modules modified to fix bugs are helpful notes for
developers, but they aren't necessary or sufficient to coordinate work between test and
development. Use build numbers instead.
3. Use a process to handle bug reports
Bug reports should go through a process that ensures that they aren't closed if they
shouldn't be. Such a process should require that the person who reported the bug be the
one to verify that it has been fixed or to approve any other type of resolution. The
typical bug report
life cycle would include the following status values: New, Assigned, Resolved,
Verified and Closed, respectively.
4. Use a resolution field
To keep the bug report life cycle simple, use a resolution field to specify how problems are
resolved. Possible resolutions include: Fixed, Won't Fix, Not Reproducible, Duplicate,
By Design and External.
5. Don't triage bug reports in meetings
Avoid using a committee or meeting to triage bug reports. This will use a lot of man-hours
that could be used fixing bugs. If the schedule dictates a triage, don't close bug reports
in the meeting because this will circumvent the quality process by sidestepping testers
that report bugs. Instead, use the bug triage to reprioritize, postpone, or resolve as
won't fix.
6. Handle feature requests separately
Feature requests and specifications are often recorded as bug reports. These should be
recorded separately so that they can be triaged, and so that they don't skew statistics
for measuring software quality.
7. Describe how to reproduce bugs
A bug report should include a step-by-step description on how to reproduce the bug. This
reduces the amount of time developers spend trying to reproduce the bug before they fix
it. Finding the minimal steps to reproduce the bug will save even more developer time.
8. Record how bugs are detected
Keeping
records on how bugs are detected helps you determine how best to spend your testing
dollars. Suggested choices for a detection method field include: Interactive Testing, Test
Script Execution, Test Script Design, Unit Testing, Integration Testing, Code Review, Beta
Testing and Customer Report.
9. Keep bug reporting simple
Don't make bug reporting complicated by requiring entry of more data than is really
necessary. If it's too much work to enter bugs into the tracking system, some bugs won't
be entered, or people may start going around the system and begin reporting bugs by email
or word-of-mouth. |
