Testing, Testing

A Development Kit

Video game testers

Bug Typing (not of the Pokémon variety)

A type

These kinds of bugs are maximum priority; the game cannot be played with these present. They prevent publishing.

·         Crash

The game or software is completely unresponsive, having either suffered a critical error or becoming hanged (unresponsive) indefinitely.

·         Severe

The gameplay has been impaired by bugs to the point where it is unplayable. Highly important features of the game are unusable, and the gaming experience is utterly ruined. These often include bad frame rates, data corruption, and critical flaws in the gameplay itself.

Legend of Zelda Skyward Sword Game Breaking Bug;

If you do certain things In a certain order In L.O.Z Skyward Sword, You can no longer proceed in the game and the gameplay is ruined. This is not a Crash, but it is a severe bug.

B type

These prevent the game from being sold, or reduce sales if released. They are often used as exploits.

·         General

There are notable glitches and bugs, which affect gameplay greatly but do not ruin the gameplay entirely. They can however build up into a severe glitch if left unchecked. They can often involve localisation translation errors, flaws in aesthetics, and bad game mechanics.

Simpsons Hit & Run B type Glitch;

In Simpsons Hit and Run, you can use cheats to access the area outside the map. This can be escaped and does not impede progress, but is a major bug. You can cause crashes by doing certain things in this area.

C Type

This type of bug can be ignored, is funny, or goes completely unnoticed by the player.

·         Minor

These can be considered nuisances, small glitches that can be easily worked around and yet are somewhat noticeable.

·         Cosmetic

These are very small flaws, hardly noticeable, such as minor texture and H.U.D errors.

Borderlands 2 C type glitch;

The NPC character Tiny Tina has a common glitch, a lazy eye that was not meant to occur. The creators left this in, as they thought it suited her craziness.

Phases of testing

Identification

 The tester plays the game and figures out what should and shouldn’t be. More or less what it says on the tin, the tester ‘Identifies’ bugs and glitches, so they might be reported.

Reporting

A detailed report of the bug is then sent to the developers via a computer system, along with possible ways to solve it and occasional videos showing the bug happening.

Analysis

 The developer who worked on the aspect of the game that is bugged will analyse the bug and figure out ways to fix it. If more information is needed, the tester can be asked to send more detail.

Verification

After the issue is fixed, that part of the game is sent to be tested again. If the bug is small or non-descript, and can be ignored, it might not be fixed or added in as a feature.

Testing Types

Play testing

Simply playing a level and exploring it to see if there are any bugs or gameplay errors.

Soak testing

This involves leaving the game on for a period of time, allowing it to repeat one of the programmed operations for a long time, such as a characters idle stance, or the repeated use of a character’s movement. This helps fix errors with memory and glitches that occur after repeated operations.

Stress testing

Stress testing is running the software in conditions that would break it. This is to see whether the software has good error handling capabilities, and to see if the software can recover well afterwards.

Localisation testing

This sort of testing ensures the game is suitable for multiple countries, that all the text that the player needs/wants to read can be read, and that parts of the game that would not be acceptable in certain countries are removed or changed.

Testing suites

The idea of a testing suite is to find all the errors in a part of a game and fix them.

The first thing you need to do is to figure out all of the elements of the game. They could be anything from lighting to whatever direction a certain object moves in. You then need to check whether or not there is anything wrong with any of them, and then you need to report whatever is wrong to the programmers to see if they can fix the problem. If they need more information, you may need to analyse the problem and see if you can pinpoint the problem. After they have corrected the error, you will need to re-test that particular element of the game to see if they have fixed it correctly.

To start off with, you need to ask questions about each element of the game;

Does the Splash screen appear?

Does the first Main menu work properly?

Does the second Main menu work properly?

Does the Level menu work properly?

Does the Menu SFX play?

Does the Menu exit beep play?

Does the Level ground model appear in the level?

Does the Level ground model texture appear properly?

Does the Sky Dome appear?

Does the Sky Dome animation play properly?

Do the Water physics work properly?

Does the Water texture display?

Do the Water animations play properly?

Do the Water splash sounds play?

Does the Monorail 1 asset appear in level?

Is the Monorail 1 texture displayed properly?

Does the Monorail 2 asset appear in level?

Is the Monorail 2 texture displayed properly?

And so on. You need to ask every question you can about each and every asset and aspect to create a proper mock testing suite.

A good example of a testing suite is a flowchart; this helps you figure out what is needed to be done and how to go about it.

This is the beginning of a test flow diagram of my own FMP game level.

A Testing suite is mainly about constantly asking questions and determining whether the game can or should be fixed, and repeating the process until either you or the project manager is happy with it. It’s quite obvious you cannot ever get rid of all the bugs in the game, there will always be something wrong, but the point is to get rid of the majority and the most obvious and dangerous. And that’s all I got on Video Game testing.