Game Development Reference
In-Depth Information
Brief Description
Larger databases may contain two description fields: Brief Description and Full
Description. The Brief Description field is used as a quick reference to identify the bug.
This should not be a cute nickname, but a one-sentence description that allows team
members to identify and discuss defects without having to read the longer full descrip-
tion each time. Think of the brief description as the headline of the defect report.
Crash to desktop.
This not a complete sentence, nor is it specific enough for a brief description. It could
apply to one of dozens of defects in a database. The brief description must be brief
enough to be read easily and quickly, but long enough to describe the bug.
The saving system is broken.
This is a complete sentence, but is it not specific enough. What did the tester experi-
ence? Did the game not save? Did a saved game not load? Does saving cause a crash?
Crash to desktop when choosing “Options�? from Main Menu.
This is a complete sentence, and it is specific enough so that anyone reading it will
have some idea of the location and severity of the defect.
Game crashed after I killed all the guards and doubled back through the level to get
all the pick-ups and killed the first re-spawned guard.
This is a run-on sentence that contains far too much detail. A good way to boil it down
might be
Game crashed after guards respawned.
The TV listings in your newspaper can provide excellent examples of a brief descrip-
tion—they boil down an entire half-hour sitcom or two-hour movie into one or two
sentences.
Tip
Write the full description first, and then write the brief description. Spending some time polishing
the full description will help you understand the most important details to include in the brief
description.
Full Description
If the brief description is the headline of a bug report, the Full Description field pro-
vides the gory details. Rather than a prose discussion of the defect, the full description
