Game Development Reference
In-Depth Information
Project documents, project plans, code, tests, test results, designs, and user documen-
tation are all candidates for QA review. QA should also audit work procedures used by
the team. These can include the code inspection process, file backup procedures, and
the use of tools to measure game performance over a network.
Reviews and audits can be performed on the results of the process, such as checking that
all required fields in a form are filled in with the right type of data and that required sig-
natures have been obtained. Another way to audit is to observe the process in action.
This is a good way to audit peer reviews, testing procedures, and weekly backups.
Procedures that occur very infrequently, such as restoring project files from backup, can
be initiated by QA to make sure that the capability is available when it is needed.
QA itself should be subject to independent review (Rule 2). If you have multiple game
projects going on, each project's QA team can review the work of the other in order
to provide feedback and suggestions to ensure that they are doing what they docu-
mented in the SQAP. If no other QA team exists, you could have someone from another
function such as testing, art, or development use a checklist to review your QA work.
The QA activities identified in this section of the SQAP should be placed on a sched-
ule to ensure that the QA people will have the time to do all of the activities they are
signed up for. These activities should also be coordinated with the overall project
schedule and milestones so you can count on the work products or activities that are
being audited to be available at the time you are planning to audit them.
As part of being a good citizen, planned QA activities that will disrupt other people's
work, such as restoring backups or sitting down with someone to review a month's
worth of TDD updates, should be incorporated into the overall project schedule so
the people affected will be able to set aside the appropriate amount of time for prepar-
ing and participating in the audit or review. This is not necessary for activities such as
sitting in on a code review because the code review was going to take place whether or
not you were there.
Feedback and Reports
The SQAP should document what kinds of reports will be generated by SQA activi-
ties and how they will be communicated. Reporting should also include the progress
and status of SQA activities against the plan. These get recorded in the SQAP along
with how frequently the QA team's results will be reported and in what fashion. Items
that require frequent attention should be reported on regularly. Infrequent audits and
reviews can be summarized at longer intervals. For example, the QA team might pro-
duce weekly reports on test result audits, but produce quarterly reports on backup and
restoration procedure audits. Test result audits would begin shortly after testing starts
