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






