Tracking bugs: summary of responses

[geoff-h -at- MTL -dot- FERIC -dot- CA]

 A while back, I asked for suggestions to help set up a
 bug-tracking database for some beta software. Here's a
 summary of what I came up with:

 User data
 ---------
 - name
 - company
 - address/phone #/e-mail
 - language preference
 - optional: last contact date

 Points to include
 -----------------
 - Bug number (assigned automatically by your database
 or--much better--use a descriptive code such as "GPF1 =
 general protection fault type 1")
 - Versions of OS and software being used; which module the
 bug was found in
 - Any software currently running when bug occurs
 - System details: CPU, RAM, video drivers etc.
 - Reported by (can be in-house testers, help hotline, beta
 testers)
 - Date of report (for tracking), plus date resolved.
 - Description of the problem and any steps that were
 performed before the bug appeared (as detailed as possible)
 - Menu item or other command or control affected by the bug
 - Verified by (to ensure that it really is a bug before
 developers spend time on it) or "Intended" (not a bug...
 the software is supposed to work that way). "Intended"
 features that are reported frequently as problems suggest
 interface changes are necessary.
 - Fixed by (identifies the developer who took ownership for
 the bug and its resolution)
 - Severity (use predefined categories, perhaps triage based
 on "urgent", "important" and "can wait")
 - Memo: to document how the problem was fixed, or to assign
 a status of "deferred" if the bug cannot be fixed at that
 time. (This can help identify a Release Note issue.)

 One respondent, who has worked with more than one package
 that tracks not only bugs but new projects, suggested that
 using commercial software is the best approach, and
 recommended "PVCS Tracker": there isn't much point
 "reinventing the wheel" if the software already exists.
 Another pointed out that the best software in the world is
 useless without the smarts and the dedication to rigorously
 track bug reports, investigate them, and resolve them...
 and that this can be a large job indeed.

 Thanks to the following contributors: One poster who wished
 to remain anonymous, Diane Burke, Debbie Molis, Kristine
 Olberg, Kathleen Padova, and Robert Plamondon.

 --Geoff Hart     @8^{)}     geoff-h -at- mtl -dot- feric -dot- ca
 Disclaimer: Speaking for myself, not FERIC.

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html