Game Development Reference
In-Depth Information
add significant new headaches. It can substantially increase the code that your team
has to deal with (potentially hundreds of test scripts that have to be constantly main-
tained and updated, tracked, and so on) and appreciably increase the amount of test
data that your team has to process, store, and analyze. Imagine you are already inun-
dated with thousands of bug reports coming in from your internal and external
testers. How will you, your team, and your system cope if an automated program gen-
erates tens of thousands of lines of data, much of which can be ignored but none of
which can you assume is unimportant?
Introducing test automation in the middle of a project will not help a poorly run test
effort. As Figure 16.1 suggests, it's a bad time to automate when your test department
is overwhelmed and having trouble keeping up with the demands of development and
marketing to get the game completed and bug free. Yet this is exactly the mistake that
often occurs. Testers at the end of their wits recommend automation as a way to lessen
their workload, not realizing it is (at least in the near term) likely to substantially
increase the workload of both testers and programmers.
Figure 16.1
Should you automate?
Clearly some games are better suited to full-scale test automation than others,
although most would benefit from at least some degree of automation.
