Gold Testing

Once the Beta test phase winds down, the game should be at a state that resembles the following set of typical release guidelines:

1. All known Severity 1 bugs (crashes, hangs , major function failures) are fixed.

2. Greater than 90% of all known Severity 2 bugs are fixed.

3. Greater than 85% of all known Severity 3 bugs are fixed.

4. Any known open issues have a workaround that has been communicated to Technical Support (or documented in the ‚  README.TXT file, in the case of PC games ).

5. Release-level performance has been achieved (60-fps frame rate).

Upon meeting your release criteria, the game is declared to be at "code lock." A brief, intense period of testing is performed on what everyone on the team hopes will be (but which will probably not be) the final build. Since the version of the game that is sent to be manufactured is known as the gold master , the final few versions tested are known as gold master candidates (GMCs) or release candidates .

At this point the game look and feels like any other retail game. It's up to the testers to serve as the last line of protection for both the player and the project team by sniffing out any remaining hidden defects that would have a significant impact on player satisfaction. This should be done by rerunning one final time all of the test suites, or as many as time permits . In addition, a number of testers should be tasked with "breaking" the game one final time. Any remaining bug found during this final effort deemed too severe to be waived is called a showstopper , because it causes the gold master candidate to be rejected. A new GMC must be prepared with a fix for the new defect, and release testing must start over again from the beginning.

Last-Minute Defects

Because the final stages of the project are so intense and pressure-laden, people will react negatively to showstoppers: "Why are we [or you] just finding this now? Test has been going on for months!" This refrain is frequently heard from stressed-out executives. It is best for the test team to take such emotional comments in stride and remember several inviolable truths of game development:

1. There is seldom enough time in any project to find every bug.

2. Every time a programmer touches the code, bugs may be introduced.

3. Code changes accumulate over time, so that several iterative changes to different parts of the game may result in a bug showing up downstream from those changes.

4. Programmers are much more tired and prone to mistakes toward the end of the project.

5. Testers are much more tired and prone to miss things toward the end of the project.

6. Bugs happen.

In the case of a PC game, a Web game, or any other game in which the publisher or financing entity is the sole arbiter of whether to release the product, once the Gold testing phase has been concluded, the game is ready for manufacture. In the case of a console game, however, there is one final gatekeeper who must certify the code. This final certification process is known as release testing .