The Game Testing Primer document outlines the role of software testing. The processes that are commonly used for Software Testing are:

A) Code Inspection:

review the source code and focus on logic structure, conformity with standards, the use of comments, and the completeness of program documentation and/or definition.

B) Incremental Focus Testing:

test chunk or pieces of code by feeding values/input toan isolated module, and analyze the intermediate result from the module. Usually a run-time facility, a debugging tool, a “dummy” front-end, which allows invocation of objects by their underlying method(s).

C) Data Analysis:

examine the data in the database; or analyze which part of the system uses or modifies any item of data. By tracing data items through the game play, the tester can validate if data usage, interpretation and manipulation by the modules or objects are appropriate.

D) Path and Flow testing:

verify if the correct sequence of objects or components is executed for an end-to-end path.

E) Algorithm-Specific testing:

test a specific game scenario or feature by setting (or tweaking) data variables, data values to the code, and execute it in the run-time environment. Different from the Incremental Focus Testing, the testing is to verify a suite of codes that make up a specific game feature.

F) Artificial Intelligence Analysis:

generate the run statistic of the programmable moves and plays of the AI components. The result is to validate if all the pre-programmed moves (e.g. side grip on the snowboard) and plays (e.g. Jackie Chan’scombination punch/kick in a multi-directional action) are used. Verify if the AI logic is appropriate and reasonable (e.g. in a basketball game, it would not be reasonable to havethe scoring 90% by dunk; and 10% by jump shot).

The following provides a brief overview of specific tasks and techniques that a Software Tester should learn or know while working on a game project.

A new software tester should get familiar with Radical’s file structure. There are several good documents pertaining to this from the global game and foundation technologies technical documents. The learning objective is basically to learn the overall game component architecture, and understand how it all flows together and to familiar yourself with the file dependencies of the game. When checking a game module, it is important to understand what parts its inner workings are dependent on. This will help you and speed up your buginvestigation and problem analysis process.

A software tester will be responsible for the nightly builds. Every night the build is built using the latest modules so that in the morning everyone can be working on the same up-to-date code. Occasionally some thing will go wrong with the nightly build. A file should generate when the build is broken and it should say what part it failed on. You should use this file to in your  problem investigation. Usually some of the code may not work with another new part or maybe the pipelines are messed up. It is the software tester’s responsibility to go through the broken module and to find out why it’s broken and fix it if possible. If its too much for you to fix, you should then inform the person responsible for the code or the pipeline that something is broken and get them to fix it. Once the problem is fixed the build should be rebuilt to verify. The build number should be automatically amended with a post fix to represent the build number of theday. These build numbers will help you track down bugs or identify bugs within a specific build. For example someone might come to you with a bug on an earlier version. If you can identify what build they are working on and what build is completed, it could just be a simple fix of them getting the new build for the bug fix. It would be a good idea to send an email that tells people a new build is completed.

Another note on build is to make sure to mark the build release or debug because there could besome problems with one but not the other.

It is a good idea to check the current status of the memory after a nightly build. If there are significant changes between the new day and day before, make a note of it. Something could be wrong. If the exe size grows too large then the game will take longer to load.

Allot of your time is going to be spent on debugging or at least helping someone debug the game. One of the main skills a software tester should have is a STRONG understanding on how a debugger (Visual C++, Linux Debugger) works so that they can accomplish this task. They should be able to step through or into parts of code and be able to understand what is happening and how to set and change variables as well as run a function at any time during the program. At this time you will be doing some code inspection. The debugger can give you a lot of information on variables. Use this information to verify that the code is using all of its generated nodes and arrays and that any discarded arrays or nodes are properly cleaned up so no null pointer or such are created. Check the code for correct documentation for ease of use (e.g.no funky variables like temp;) ensure that the programmers are documenting correctly so their code can be picked up easily in the off case someone will have to continue their work. You may have to also do some sort of data inspection depending on the game. If a game uses some sort of statistics program and randomization, make sure the data is being stored correctly and is only available to the parts of the program that use it. Ensure that the data is not getting corrupted as it is coveted and used in the pipelines.

A very important part of the job will be for a software tester to write test programs. Some examples would be programs to enable cheat codes, play sound files, enable/disable the AI, recreate test scenarios, and whatever other debug information may be required. The Game Tester also uses these test programs so they can test for specific gameplay scenarioand/or situations.

Sound testing is simply listening to the sound and making sure the startup point and the length are appropriate. The software Tester often requires to write a “sound test” program to play all the individual sound files from inside the game (just a quick tip, you should check with the sound artist and see if they have one already).

Sound testing includes testing if there will be any error in loading the files, listening to the sound files for errors or distortion. Also, test to make sure all the sound files are being loaded correctly. If the game has Colour Commentary (or CC), use the cc profiler to analyze. The analysis helps you to determine how many times a CC was called, and if it gets played or overwritten.

The analyzer relates the scene or situations to the cc and checks to see if the information gets played, if you notice any problem in cc, you should check if the information is being passed and played correctly. Of course one way to analyze the cc is actually listening to it and note any irregularities and problems.

It is important to generally understand how the pipelines work. How the sound is being processed and converted, how the Maya art is being converted and used, generally how all the object data is exported from a raw data to a useable product. It would be a good idea to understand how P3D files are created and used. Look into the Anim classes, P3D chunks andcomplex messes.

The main purpose of the database for a game is:

1) Player or team statistics. It could be used solely for display, or it could b used by the AI engine to simulate the actual game play or for randomization.

2) Run-time statistics. It is used by the game engine to remember certain state, attributes or scoring of the player as you move from level to level (or to a different game state).

The easiest way to verify the database is to go into the game itself using a debugger, and analyze the game is using the data correctly. Obtain a printout of the database and look at the screens to make sure the data is being loaded, in the right place, showing the right information. On ahigher note, one could check the database export to make sure no error found in the export. Another good technique is to do random checking, say, on a player statistic, to make sure thedata is correct.

Make sure the overlays are loaded correctly. A tester could write a program to test that theoverlays are being called correctly, and identify if any one does not get used at all.

Most of the Front End screens could relate to statistics (you know, in the database). The main thing to look into is the “Text Bible”, i.e. the appropriateness of the text, the naming convention,checking against any manufacture standards or requirements, and even spelling.

The software tester should know how to use PVCS Tracker to track and report bugs, and know the use of the standard template to create/customize a new defect database for a new project. It would be preferred if you could have administrator rights to tracker to set up others with accounts and manage the database (new client sign-on ID, fields and information).

A software tester must also have “to have a love of games” in mind. A significant amount of your time will be playing games to find the bugs. You have to have the skills to find and report game bugs as well as help repair them. It is important to test for the fun factor of a game aswell, if you stop having fun while playing the game then make sure to discuss with your peerslike the Game Tester. If the changes happen too late they may not get implemented. Still,remember the debugger is your best friend.

Simple, burn CD copies of the game for people who need them (game testers, management). A bigger part of this would be to track down problems of bugs being discovered on a different medium.

Well, once more I kindly ask you that if you know the Author of this text, please let me know so I can give the RIGHT CREDITS to him/her/them.

Thanks for reading my blog!