In This Chapter
• Testing Schedule
• Test Plan
• Testing Pipeline
• Testing Cycle
• External Testing
o many people outside of the game industry, testing seems like a glam-
orous job. After all, you get to play games all day! However, if you talk
to anyone who has tested games for a living, you know that it is any-
thing but glamorous. In reality, testing is an extremely stressful and difficult job.
Most testers spend at least five to eight months testing the same game day in
and day out, looking for defects, confirming bug fixes, and play testing missions.
This becomes pretty tedious after a few weeks, no matter how fun the game is.
Oftentimes, because testers are looking for specific issues with the game, they
don’t even have a chance to actually just play and enjoy the game.
Another thing that adds to the stress of testing is that many game devel-
opment schedules rarely allot ample time to test everything thoroughly, which
means the testers are often working massive overtime (late nights, weekends,
and holidays) to get the game tested and ready for code release. One reason this
happens is because testing is the last thing to happen in the production cycle.
So if things are running off schedule for art, engineering, or design, these delays
362 THE GAME PRODUCTION HANDBOOK, 2/E
are amplified by the time testing begins. Testing time is often the first thing cut
when extra production time is needed.
The producer must work closely with the lead QA analyst to alleviate as
many of the testing problems as possible. The lead QA analyst is responsible for
testing the game, closing bugs, and determining whether a game is ready to be
code released. Involve the QA analyst in pre-production so he can comment on
any features that will propose testing challenges. For example, if there are plans
to include 200 options in the character creation system, the QA analyst can com-
ment on how much testing time it will take to test each option and the different
combinations. The testing time alone is probably reason enough to drastically
limit the options for this feature. Things like this will help create a tighter loop
between the development team and the testing team, which will hopefully trans-
late into more manageable testing schedules.
22.2 TESTING SCHEDULE
Since testing time is often cut short to accommodate other schedule slips, create
a solid testing schedule during pre-production. This ensures that everyone on the
team has a clear understanding of the testing schedule and what the expectations
are. If the team understands how their delays negatively impact testing, they will
be more conscientious about meeting their deadlines in a timely fashion. Refer
to Chapter 16, “Game Plan,” for detailed information on creating a schedule.
Build the testing schedule directly into the production schedule and show
the testing dependencies so that delays affecting the test cycle can be immedi-
ately seen and mitigated. Also, add in testing time for each major milestone of the
game so the testing department can spend a few days with a single build to evalu-
ate the game’s progress against the milestone deliverables. Refer to Chapter 15,
“Game Requirements,” for details on milestone deliverables.
Other things to include in the testing schedule are as follows:
Play testing: During production, make sure to schedule time for QA to play
test the game and offer feedback to the developers. Ideally, conduct these
play tests with people who haven’t already spent months playing the game,
so the feedback is based mainly on the fun factor of the game.
Demo: Marketing will want a demo, and it will need to be tested. If the
demo is already in the schedule, everyone will be prepared to fulfill this re-
quest when marketing makes it.
Marketing builds: If marketing is sending development builds out during
production, schedule time for the testing department to check them be-
fore they leave the building. Even though journalists expect to see bugs and