Game Development Reference
In-Depth Information
Pass or Fail
Tests that fail are good from your perspective, but it's also important for the project to
know which tests passed. You will probably be expected to record the completion and
results of your tests by indicating which passed and which failed. Other status types
might include “Blocked�? or “Not Available,�? where “Blocked�? indicates that an exist-
ing problem is preventing you from executing one or more steps in the tests, and “Not
Available�? indicates that a feature or capability that is part of the test is not available
in the version of the game you are testing. For example, a multiplayer scenario test is
“Blocked�? if a defect in the game prevents you from connecting to the multiplayer
server. A test that can't be run because the level hasn't been added to the game yet
would be classified as “Not Available.�?
Usually this information goes to the test lead and it's important to provide it in a timely
manner. It might just be a physical sheet of paper you fill out and put on a pile, or an
electronic spreadsheet or form you send in. This information can affect planning which
tests get run for the next release, as well as the day-to-day assignments of each tester.
Note
In the course of testing, keep track of which version of the game you are running, which machine
settings you're using, peripherals, and so on. It's also a good idea to make and keep various “save�?
files for the game so you can go back later to rerun old tests, or try new ones without having to
play through the game again. I also recommend that you keep your own list of the bugs you have
found so that you can follow up on them during the project. I have personally been the victim of
bug reports that were “lost�? or “moved,�? even though the bugs themselves were still in the soft-
ware. Just make sure you have a way to identify each save file with the game version it was made
for. Otherwise, you can get false test results by using old files with new releases or vice versa.
As much as you may become attached to the defects you find, you may have very little
to say directly about whether or not they get fixed. Your precious defects will likely be
in the hands of a merciless Change Control Board (CCB). This might go by some
other name in your company or project team, but the purpose of this group is to pri-
oritize, supervise, and drive the completion of the most necessary defects to create the
best shipping game possible when the project deadline arrives. This implies that
defects are easier to get fixed when they are found early in the project than when they
are found later. The threat of messing up the rest of the game and missing the ship-
ping deadline will scare many teams away from fixing difficult defects near the end of
the project. This is why you want to find the big stuff early!
