Game Development Reference
In-Depth Information
There will be times, especially later in the project, when the development team deter-
mines that they can't (or won't) fix a bug. This can happen for a variety of reasons.
Perhaps the technical risks involved in the fix outweigh the negative impact of the
defect. Perhaps there is a workaround in place that the technical support team can
supply to players who encounter the defect. Perhaps there simply isn't time.
Whatever the reason, each project must have a quick and orderly process in place to
determine which defects will be
waived,
that is, which will not be fixed by the devel-
opment team. This designation has many different names. Waived bugs can be known
as “as is,�? ISV (In Shipped Version), DWNF (Developer Will Not Fix), or CBP (Closed
by Producer). The worst name I've ever encountered for the waived status is “featured,�?
which institutionalized the cynical joke, “That's not a bug, it's a feature.�? (Not sur-
prisingly, that studio is now defunct, having released too many buggy games.)
Cynicism, defeatism, and defensiveness have no place in the bug waiving process. On
the one hand, testers work very hard and want to feel as though their effort matters to
the project. On the other hand, developers work just as long (if not longer) and have
a duty to ship their game on time. It is crucial that all parties involved maintain an
understanding and respect for the role each plays in the overall project team.
Ideally, the senior members of the project team will meet regularly and often to dis-
cuss those bugs that the development team have requested to be waived. These can be
flagged as “waive requested�? or “request as is�? in the Status or Developer Status fields
of the bug database. The senior members of the project team (the producer, executive
producer, lead tester, and QA manager) can meet to evaluate each bug and discuss the
positives and negatives of fixing it versus leaving it in the game. Other team members
such as programmers or testers should be available for these meetings as needed. This
decision-making body is sometimes called the CCB (Change Control Board) or the
Bug Committee.
In some cases, where a post-release software update, or
patch
, is anticipated, a number
of bugs will be designated for fixing after the game has been shipped (see “Post-release
Testing,�? later in the chapter). In the case of most console games, however, this is not
yet an option.
Once a bug has been waived, it's important to remind both the bug author and the test
team as a whole that merely because the bug was waived doesn't mean that it wasn't a
legitimate bug. Nor does it mean that they shouldn't continue to find defects with the
same level of diligence. It is the role of the test team to write up every bug, every time,
no matter when in the cycle they find it. They supply the lead tester, project manager,
and the business unit heads with the best information possible about the state of the
game so that the best business decisions can be made.
