Game Development Reference
Too Many Cooks?
A defect tracking database (or bug database or “bug base�?) that is editable by only the lead tester
is not very useful—these tend to be very static and incapable of conveying up-to-the minute infor-
mation about the state of the project. Neither is a bug base in which every member of the team
can edit every field—these are chaotic and ultimately useless.
In designing the bug base, the lead tester must balance the need for members of the project team
to communicate with each other about a particular defect with the equally important need to con-
trol the flow of information to all members of the project team. Programmers need to be able to
comment on or ask questions about a defect in the Developer Comments or Notes field, but they
can't be allowed to close the defect arbitrarily by changing the Status field to “closed.�? Testers
need to be able to describe the bug in the Brief Description and Full Description fields, but they
may not be qualified to judge who should own the bug in the Assigned To field.
Here are some recommendations:
Status should be editable by the lead tester only. The default value for this field should be
“New,�? so that as testers enter bugs, they can be reviewed and refined by the lead tester before
the status is changed to “Open�? and is assigned to a member of the development team.
Severity should be editable by the lead tester or primary testers. Remember that the severity
of a defect is not the same as its “fix priority.�? Testers tend, rightly, to be passionate about the
defects they find. It is the job of the test team leaders to check against this and assign a sever-
ity in an objective manner.
Category Fields should be input by the testers and editable by the lead or primary tester.
These fields include such specifics as Game Type, Level, Bug Type, Reproduction Rate, and any
other field that includes specific information about the bug.
Brief/Full Description should be input by the testers and editable by the lead or primary tester.
Assigned To is a field that should be editable by the lead tester and any member of the devel-
opment team. The lead tester will typically assign new bugs to the project manager, who will
then review the bug and assign it to a specific programmer or artist to be fixed. Once the bug
is fixed, that person can either assign it back to the project manager for further review, or back
to the lead tester so that the fix can be verified in the next build and the bug can be closed.
Developer Comments should be editable by the project manager and any member of the
Priority should be editable by the project manager and senior members of the development
team. This field is primarily a tool to help the project manager prioritize the flow of work to
members of the development team.