Game Development Reference
Testing the wrong build, failing to notice an important defect, or sending developers
on a wild goose chase after a non-existent bug shouldn't end up getting you physically
hurt, but there will be a price to pay in extra time, extra money spent, and/or loss of
sales and reputation.
Game project panic happens when you are
As a member of a game team, you might be asked to do something you've never had
to do before. You might be given someone else's tests to run, be thrown into the mid-
dle of a different game project, or told to take someone else's place at the last minute
to do a customer demo. In situations like these, rely on what you know, stick to basics,
and pick up any new or different ways of doing things by watching the people who
have already been doing it.
You may even be asked to accomplish something you've never done before, such as
achieve 100% automation of the installation tests, or write a tool to verify the foreign
language text in the game. Maybe no one has ever done this before. Don't make a com-
mitment right away, don't make stuff up, and don't try to be a hero. If you are unfa-
miliar with a situation, you act based on your best judgment, but it still may not be
right. This requires good “radar�? on your part to know when to get help, and also a
dose of humility so you don't feel like you have to take on everything yourself or say
“yes�? to every request. You don't need to lose any authority or “street cred.�? Find some-
one who's “been there, done that�? and can steer you toward some working solutions.
Stay away from responses that are known to fail. You can even search the Internet to
see if anyone else has been through it and lived to tell about it.
Chapter 8, “The Test Process,�? shows you how to define and follow a set of activities that will give
you consistent test throughput and results, even when you're in unfamiliar territory.