Game Development Reference
In-Depth Information
b. Level #2
c. Etc.
3. Email showstopper crashes or critical errors to the entire team.
4. Post showstopper crashes or critical errors to the daily top bugs list (if one is
being maintained).
c. Daily Reports
i. Automated reports from the preceding daily tests are posted in the QA portion of
the internal Web site.
d. Weekly Activities
i. Weekly tests
1. Run through every level in the game (not just the preset ones used in the daily
test), performing a specified set of activities and generating a predetermined set
of tracking statistics. The same machine should be used each week.
a. Level #1
i. Activity #1
ii. Activity #2
iii. Etc.
b. Level #2
c. Etc.
2. Weekly Review of Bugs in the Bug Tracking System
a. Verify that bugs marked “fixed�? by the development team really are fixed.
b. Check the appropriateness of bug rankings relative to where the project is in
the development.
c. Acquire a “feel�? for the current state of the game, which can be communicated
in discussions to the producer and department heads.
d. Generate a weekly report of closed-out bugs.
ii. Weekly Reports
1. Tracking statistics, as generated in the weekly tests.
e. Ad Hoc Testing
i. Perform specialized tests as requested by the producer, tech lead, or other
development team members.
ii. Determine the appropriate level of communication to report the results of those
tests.
f. Integration of Reports from External Test Groups
i. If at all possible, ensure that all test groups are using the same bug tracking system.
ii. Determine which group is responsible for maintaining the master list.
iii. Determine how frequently to reconcile bug lists against each other.
iv. Ensure that only one consolidated set of bugs is reported to the development team.
g. Focus Testing (if applicable)
i. Recruitment methods
ii. Testing location
iii. Who observes them?
iv.
Who communicates with them?
v.
How is their feedback recorded?
