Game Development Reference
h. Compatibility Testing
i. Selection of external vendor
ii. Evaluation of results
iii. Method of integrating filtered results into bug tracking system
SECTION III: HOW TESTING REQUIREMENTS ARE GENERATED
a. Some requirements are generated by this plan.
b. Requirements can also be generated during project meetings, or other formal meetings
held to review current priorities (such as the set of predetermined levels used in the
c. Requirements can also result from changes in a bug's status within the bug tracking sys-
tem. For example, when a bug is marked “fixed�? by a developer, a requirement is gener-
ated for someone to verify that it has been truly killed and can be closed out. Other
status changes include “Need More Info�? and “Can't Duplicate,�? each of which creates a
requirement for QA to investigate the bug further.
Some requirements are generated when a developer wants QA to check a certain
portion of the game (see “Ad Hoc Testing�? ).
SECTION IV: BUG TRACKING SOFTWARE
a. Package name
b. How many seats will be needed for the project
c. Access instructions (Everyone on the team should have access to the buglist)
d. “How to report a bug�? instructions for using the system
SECTION V: BUG CLASSIFICATIONS
a. “A�? bugs and their definition
b. “B�? bugs and their definition
c. “C�? bugs and their definition
SECTION VI: BUG TRACKING
a. Who classifies the bug?
b. Who assigns the bug?
c. What happens when the bug is fixed?
d. What happens when the fix is verified?
SECTION VII: SCHEDULING AND LOADING
a. Rotation Plan. How testers will be brought on and off the project, so that some testers
stay on it throughout its lifecycle while “fresh faces�? are periodically brought in.
b. Loading Plan. Resource plan that shows how many testers will be needed at various
points in the life of the project.
10. SECTION VIII: EQUIPMENT BUDGET AND COSTS
a. QA Team Personnel with Hardware and Software Toolset
Team Member #1