Game Development Reference
In-Depth Information
The lead tester and project manager should mutually agree on appropriate permis-
sions—that is, which team members have edit rights to which fields. The lead tester
should also ask the project manager for a list of development team members to whom
bugs will be assigned. The “assigned to�? field allows the lead tester, project manager,
or anyone else so entrusted to review new bugs and assign them to the right member
of the development team to be investigated and fixed. Programmers and artists then
search the database for bugs assigned to them. Once they've resolved the bug, they can
assign the bug back to the lead tester so that the fix can be verified on the next build.
Whether the bug database is going to sit on an internal server or be accessible over the
Internet, it's a good idea at this point to populate the bug database with a few dummy
records and double-check all passwords and permissions, both locally and remotely.
Every person who will have access to the bug base should be assigned an individual
password, and the lead tester can allow or block edit rights to individual fields based
on the role that person will play on the project team (see the following sidebar, “Too
Many Cooks?�?).
Draft Test Plan and Design Tests
Having current and detailed knowledge of the game design is critical as the lead tester
begins to draft the test documents. Begin drafting an overall test plan that defines
what types of tests will be done and what the individual suites and matrices will look
like (see Chapter 8, “The Test Process�?). This is the point in the project where you can
put the methods described in Part IV of this topic to good use. Remember:
Prior planning
prevents poor performance.
Test Plan
A
test plan
acts as the playbook for the test team. It identifies the test team's goals along
with the resources (staff, time, tools, and equipment) and methods that are necessary
to achieve them. Test goals are typically defined in terms of time and scope. They may
also be tied to dependencies on other groups. The testing timeline often includes
intermediate goals for one or more milestones that occur prior to the final release of
the game. Any risks that could affect the ability to meet the test goals are identified in
the test plan along with information about how to manage those risks if they occur.
The scope of a test plan can be limited to a single subsystem of the game or it can span
many game features and releases. If the game is being developed at multiple sites, the
test plan helps define what test responsibilities are allocated to each team. Appendix C
contains a basic test plan outline and the topic's CD provides a link to a test plan tem-
plate document you can fill in for your own projects.
