Test Plan

1. Game Name

   1. Copyright Information

2. Table of Contents

3. SECTION I: QA TEAM (and areas of responsibility)

   1. QA Lead

      1. Office phone

      2. Home phone

      3. Cell phone

      4. Email

   2. Internal Testers

   3. External Testers

4. SECTION II: TESTING PROCEDURES

   1. General Approach

   2. Basic Responsibilities of Test Team

      1. Bugs

         1. Detect them as soon as possible after they enter the build

         2. Research them

         3. Communicate them to the dev team

         4. Help get them resolved

         5. Track them

      2. Maintain the Daily Build

      3. Levels of Communication. There's no point in testing unless the results of the tests are communicated in some fashion. There are a range of possible outputs from QA. In increasing levels of formality , they are:

         1. Conversation

         2. ICQ

         3. EMail to Individual

         4. EMail to Group

         5. Daily Top Bugs List

         6. Stats/Info Dump Area on DevSite

         7. Formal Entry into Bug Tracking System

   3. Daily Activities

      1. The Build

         1. Generate a daily build.

         2. Run the daily regression tests, as described in "Daily Tests" which follows .

         3. If everything is okay, post the build so everyone can get it.

         4. If there's a problem, send an email message to the entire dev team that the new build cannot be copied , and contact whichever developers can fix the problem.

         5. Decide whether a new build needs to be run that day.

      2. Daily Tests

         1. Run through a predetermined set of single-player levels, performing a specified set of activities.

            1. Level #1

               1. Activity #1

               2. Activity #2

               3. Etc.

               4. The final activity is usually to run an automated script that reports the results of the various tests and posts them in the QA portion of the internal Web site.

            2. Level #2

            3. Etc.

         2. Run through a predetermined set of multiplayer levels, performing a specified set of activities.

            1. Level #1

               1. Activity #1

               2. Activity #2

               3. Etc.

               4. The final activity is usually for each tester involved in the multiplayer game to run an automated script that reports the results of the various tests and posts them in the QA portion of the internal Web site.

            2. Level #2

            3. 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 ).

   4. Daily Reports

      1. Automated reports from the preceding daily tests are posted in the QA portion of the internal Web site.

   5. Weekly Activities

      1. 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.

            1. Level #1

               1. Activity #1

               2. Activity #2

               3. Etc.

            2. Level #2

            3. Etc.

         2. Weekly Review of Bugs in the Bug Tracking System

            1. Verify that bugs marked "fixed" by the development team really are fixed.

            2. Check the appropriateness of bug rankings relative to where the project is in the development.

            3. Acquire a "feel" for the current state of the game, which can be communicated in discussions to the producer and department heads.

            4. Generate a weekly report of closed-out bugs.

      2. Weekly Reports

         1. Tracking statistics, as generated in the weekly tests.

   6. Ad Hoc Testing

      1. Perform specialized tests as requested by the producer, tech lead, or other development team members .

      2. Determine the appropriate level of communication to report the results of those tests.

   7. Integration of Reports from External Test Groups

      1. If at all possible, ensure that all test groups are using the same bug tracking system.

      2. Determine which group is responsible for maintaining the master list.

      3. Determine how frequently to reconcile bug lists against each other.

      4. Ensure that only one consolidated set of bugs is reported to the development team.

   8. Focus Testing (if applicable )

      1. Recruitment methods

      2. Testing location

      3. Who observes them?

      4. Who communicates with them?

      5. How is their feedback recorded?

   9. Compatibility Testing

      1. Selection of external vendor

      2. Evaluation of results

      3. Method of integrating filtered results into bug tracking system

5. SECTION III: HOW TESTING REQUIREMENTS ARE GENERATED

   1. Some requirements are generated by this plan.

   2. 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 daily tests).

   3. Requirements can also result from changes in a bug's status within the bug tracking system. For example, when a bug is marked "fixed" by a developer, a requirement is generated 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.

      1. Some requirements are generated when a developer wants QA to check a certain portion of the game (see "Ad Hoc Testing").

6. SECTION IV: BUG TRACKING SOFTWARE

   1. Package name

   2. How many seats will be needed for the project

   3. Access instructions (Everyone on the team should have access to the buglist )

   4. "How to report a bug" instructions for using the system

7. SECTION V: BUG CLASSIFICATIONS

   1. "A" bugs and their definition

   2. "B" bugs and their definition

   3. "C" bugs and their definition

8. SECTION VI: BUG TRACKING

   1. Who classifies the bug?

   2. Who assigns the bug?

   3. What happens when the bug is fixed?

   4. What happens when the fix is verified ?

9. SECTION VII: SCHEDULING AND LOADING

   1. 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.

   2. 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

    1. QA Team Personnel with Hardware and Software Toolset

       1. Team Member #1

          1. Hardware

             1. Testing PC

                1. Specs

             2. Console Debug Kit

                1. Add-ons (TV, controllers, memory cards, hubs, etc.)

          2. Software Tools Needed

             1. Bug tracking software

             2. Other

       2. Team Member #2

       3. Etc.

    2. Equipment Acquisition Schedule and Costs (summary of who needs what, when they will need it, and how much it will cost)