designing tests for computer games – test phases

There are 3 phases a game will go through before and up to release; these are Alpha, Beta and Gold.

Alpha is the first playable stage of the game, and as such only contains the base gameplay elements in order to make the game playable. during this phase, testing is usually only carried out by developers or members of the development team, as alpha builds are prone to being extremely unstable, and will typically frequently crash or encounter other such bugs. The alpha stage of the testing cycle ends with a feature freeze, during which no more features are added and extensive bug testing is carried out to try to make the build as stable as possible before moving into beta.

Beta is the second stage of the testing cycle, during which the game will largely be feature complete, with only some minor or general changes to be made to the game itself, and focuses quite largely on bug testing. many games have started to have release beta builds released to the public recently, as it can provide a lot of feedback and bug reports due to the fact that the community for a game will probably be larger than the number of in-office testers.

Gold is the full, final version of the game, where it is ready to be released and nothing more needs to be added. at this stage in development, there should be little-to-no bugs remaining in a game which would need patching post-release.

designing tests for computer games – Operating regions

Operating regions of a videogame are the 4 stages that any given game will go through whilst being tested or otherwise interacted with.

not only does the game itself have operating regions, but each element within the game, such as items or NPCs can also have operating regions.

the four operating regions of a game are:

Pre-Game:

the Pre-game operating region is before the game has been launched, for example, this will be the period of time when the disc has yet to be inserted into the console, or when you are on the consoles dashboard before starting the game. it is possible at this time to influence the game before playing it, such as by changing settings on the console itself.

Game-Start:

The Game-start operating region is the period of time between launching the game and any gameplay aspect, such as a main menu at the start of the game,  during the splash-screens showing company logos or an intro sequence. it is during this time that the game will be prepared for the player, whether or not the player is aware of this and it is essential to the proper performance and function of the game itself. It is only by reaching the end of this operating region that gameplay becomes possible.

In-Game:

the in-game operating region is when you actually play the game and have access to the vaious elements and mechanics within it. Depending on the element, these functions may be carried out multiple times throughout the course of the game, or just once.

Post-Game:

the post-game operating region takes place after you have played the game, usually when you turn the game off (with or without saving)

designing tests for computer games – triggers

There are 6 types of defect triggers within the operating regions of a game. each of these types of triggers are separate categories of game defects which can become an issue during testing.

the 6 types of trigger are:

configuration- configuration triggers are settings established before starting the game, such as system settings, language settings, date and time, etc.

startup- startup triggers are usually related to some sort of background operations carried out by the game, such as a loading screen

exception- exception triggers are code based, and therefore dependant on pieces of code within the game doing/not doing what it is supposed to do

Stress- the stress triggers are based on putting the hardware or software of a game under extreme conditions, such as changing settings to the highest possible value to see if anything breaks because of the strain.

normal- this takes place in the in-game operating region, and as such it is the most commonly used trigger type.

restart- this trigger is based on errors that occur after or during exiting the game

designing tests for computer games – Game test cycle

When games are being tested for bugs, there is a standard practice that exists within the industry. the first part of this cycle is planning the tests which will be carried to search for bugs, and these tests should be changed based on any build changes within the game, as the tests should check not just whether something has any bugs, but whether any different approaches to cause a bug will trigger it. the more thorough these tests are and the more detailed the plans, the more bugs that will be found whilst testing the game. another important aspect of the cycle that should be carried out whilst planning tests is preparation, most notably checking the bug database to see what bugs have already been found, and can ignore until they have been fixed, and which bugs have been fixed so that the fix can be verified via testing.

After planning and preparing for the bug testing, performing the tests is the next stage of the cycle. whilst carrying out tests, if any bugs are found, the bug needs to be “tested around”, to see if the bug can only be triggered in one way, or if it can be triggered by other methods. once this has been done, the nest stage of the cycle is to report any bugs found, with as much information about how to trigger the bugs, the severity, what they do, etc. so that the bug report can be as detailed and therefore useful as possible when the bug is being fixed.

The next part of the cycle is the bugs actually being fixed. once the bug report has been submitted, the bug needs to be confirmed following the details in the bug report, assuming that the report is correct. As shown in the diagram, there are several outcomes from this- the first is that the bug is found and fixed as planned, the next is that the reported bug is one that has already been found and reported, meaning that the report is essentially redundant. Another outcome is that the report is either incorrect in some way, or the bug was just a one-off, and the bug cannot be repeated, and therefore can’t be fixed.

Once the bug has been marked as having been fixed, the cycle is repeated by the testers to make sure that the bug really has been fixed, and to check that the patch didn’t cause any more bugs. If the bugs turn out to not have been properly resolved at this point, the bug is reopened, and the cycle is restarted.

http://gametesterlife.files.wordpress.com/2012/03/bug-life-cycle11.jpg