Game Development Reference
In-Depth Information
These steps not only apply to black box testing, but they also describe white box test-
ing, configuration testing, compatibility testing, and any other type of QA. These steps
are identical no matter what their scale. If you substitute the word “game�? or “project�?
for the word “build�? in the preceding steps, you will see that they can also apply to the
entire game, a phase of development (Alpha, Beta, and so on), or an individual module
or feature within a build. In this manner, the software testing process can be considered
fractal—the smaller system is structurally identical to the larger system, and vice versa.
As illustrated in Figure 8.3, the testing process itself is a feedback loop between the
tester and the developer. The tester plans and executes tests on the code, then reports
the bugs to the developer, who fixes them and compiles a new build, which the tester
plans and executes tests on, and so on.
Figure 8.3
The testing process feedback loop.
A comfortable scale from which to examine this process is at the level of testing an
individual build. Even a relatively small game project may consist of dozens of builds
over its development cycle.
Test Cases and Test Suites
As discussed in the previous chapter, a single test performed to answer a single ques-
tion is a test case; a collection of test cases is a test suite. The lead tester, primary tester,
or any other tester tasked with test creation should draft these documents prior to the
distribution of the build. Each tester will take his or her assigned test suites and per-
form them on the build. Any anomalies should be noted and checked against the
defect database. Any anomalies not already present in the database should be written
up as new bugs.
