Alpha | Game Testing All in One (Game Development Series)

It's time to get busy. The project manager delivers you an Alpha candidate. You certify it against the Alpha criteria you established in the planning phase. Now full-bore testing can begin.

Over the course of Alpha testing, the game design is fine- tuned . Features are play tested and revised (or scrapped). Missing assets are integrated. Systems developed by different programmers are linked together. It's an exciting time.

As each member of the code and art team checks new work into the build, they're also checking for new defects. This means that the game at this phase is a "target-rich environment" for a tester. It can also seem very overwhelming (remember Rule #1: Don't Panic). It is critical at this stage that the test suites are strictly adhered to. They will provide a structure for bringing order to what may seem like chaos.

Over the course of Alpha testing, all modules of the game should be tested at least once, and performance baselines should be established (frame rate, load times, and so on). These baselines will help the development team determine how far they have to go to get each performance standard up to the target for release. For example, a frame rate of 30 (or even 15) frames of video per second (fps) may be acceptable in the early stages of developing a 3D action game, but the release target should be a solid 60 fps with no prolonged dips during scenes when there are greater-than-usual numbers of characters and special effects on-screen.

Alpha Phase Entry Criteria

The following are Alpha entry criteria typical for a console game:

All major game features exist and can be tested. Some may still be in separate modules for testing purposes.
A tester can navigate the game along some path from start to finish. This assumes the game is linear, or has some linear component (for example, career mode in a racing game). Because many games are non-linear, the lead tester and project manager must agree ahead of time on a content completion target for such games (for example, three of 12 mini- games ).
The code passes at least 50% of platform TRC. Each console game has a set of standards published and tested against by the manufacturer of that platform. When you produce a PlayStation game, the Format QA team at Sony Computer Entertainment America (SCEA) will test it against the PlayStation Technical Requirements Checklist (TRC) to make certain that the game complies with platform conventions. These requirements are very exacting, such as specifying the precise wording of error messages a game must display if a player pulls his memory card out during a game save.
Basic interface is complete and preliminary documentation is available to QA. The main menu, most submenus, and the in-game interface (sometimes called the Heads-Up Display, or HUD) should be functional, if not yet finalized and visually polished. Preliminary documentation in this context means any explanation of new functionality, changed controller maps, and cheat codes (if any).
The game is compatible with most specified hardware and software configurations. For a cross-platform console game, this means that the game will run on every targeted platform (PlayStation 2 and Xbox, for example). For a PC game, this criterion dictates that the game must run on a variety of systems with varying specifications (a range of CPU speeds, a range of RAM caches, and so on).
Level scripting is implemented. This pertains primarily to single-player story mode. An Alpha candidate that required the tester to load each level manually would fail this criterion.
First-party controllers and memory cards work. Each platform manufacturer (SCEA, Microsoft, Nintendo, and so on) either manufactures or licenses for manufacture its own line of peripherals. Since support of these first-party peripherals is required by the platform TRCs, and because the majority of testing will be done using first-party peripherals, they need to be supported by Alpha.
Final or placeholder art is in for all areas of the game. All the levels and characters must be textured and animated, though these textures, animations, and even the level geometry, may be subject to refinement as the game approaches Beta.
Online multiplayer can be tested. Enough network code must be implemented so that at least two consoles can connect over a LAN and play a game.
Placeholder audio is implemented. It is entirely possible that the voice recording sessions with the final talent have not yet taken place at Alpha. In this case, members of the development team should record "stub" audio and integrate it where needed.

Over the course of Alpha testing, all modules of the game should be tested at least once, and performance baselines should be established (for example, frame rate, load times, and so on). These baselines will help the development team determine how far they have to go to get each performance standard up to the target for release. For example, a frame rate of 30 (or even 15) frames of video per second (fps) may be acceptable in the early stages of developing a 3D action game, but the release target should be a solid 60 fps with no prolonged dips during scenes when there are greater-than-usual numbers of characters and special effects on-screen.