Hi, everyone!

Here I come with one more post, but this time, talking about Game Testing Methodology as the title said!

Unfortunately, I couldn’t find the source of this text and all I know that this was available here. And also, I couldn’t find the author of it. So, if you want to have the full version of it, just check the website above.

Further more, if any of you know who is the author of this text, please, let me know so I can give the right credits.

Enjoy!

Effective testing comes from a well-structured approach and a well-defined testing methodology so the game product is highly satisfying to our Publisher and the game player. In contrast, poor testing results in a buggy game or software that gives rise to a long stream of repeated testing and project delays.

[…]

There are few, if any “fixed rules” for this testing methodology; however, there are many suggestions, ideas, and guidelines for improving the quality and effectiveness of testing for our game projects. Hopefully, testers will be able to learn, understand, plan and carry out effective and efficient testing in a structured manner. If you have any questions about the information, please contact your Software Quality Director.

SCOPE AND DEFINITION

In a simplistic view, testing is to identify bugs found in the software, so the problem can be removed. There are different forms of tests and testing that can be categorized as “Black-Box” testing and “Clear-Box” testing (“Clear Box” testing is also known as “White-Box” testing in the software industry). Their testing objective and overall processes are indifference (e.g., test planning, test design, testing execution, regression testing and bug reporting), but their focus of attention puts emphasis on different aspects of the game:

* “Black Box” focuses on the functional or the playability aspects of the game. For examples, testing the user interface (e.g., the selection menus and the use of buttons), the “look and feel” (e.g., the graphics and animation), and the actual gameplay.

* “Clear Box” is focus on the architecture and integration aspects of the game software. For examples, the use of a database, pipelines, the interaction/integration of game components like the rendering engine, the AI engine, sound, and so on.

For Black Box testing, the tester must know how to play the game (e.g., use of the game pad, know the rules and the game flow). For Clear Box testing, the tester must understand what coding is. The Software Tester uses a run-time debugging environment, feeds the code or chunks of code with input (i.e., data, setting variables, etc.) and analyzes the test result.

TESTING PHILOSOPHY

Testing is NOT a single person’s job, nor solely the responsibility of the Game Tester and the Software Tester for a game project. Every team member working in a game project must have“quality” in mind, and each person is responsible for the accuracy and completeness of the work that he/she produces.

This testing methodology is NOT the only process and it should NOT be used in isolation. The reader must be aware that this testing methodology is considered as an integral part to the Game Pre-production and Production processes.

In reality, no one can test a program COMPLETELY , i.e., testing every single part of the game using different and all available characters, so triggering different path of the logic and all the possible variations of input, interfaces, AI, and then output. Our testing strategy is to develop excellent, full-coverage, and effective testing (i.e., 80/20 rule).

TESTING PLANNING AND TESTING REQUIREMENTS

A requirement is an objective that must be met. The tester must understand most of the game requirements and translate them into functional terms (e.g., what needs to be tested, what things are testable and what not, what are the targets and measures, etc.), leaving the design and implementation details to the developers. As part of the testing requirement development process, the testers read the system documentation, gather all the visual and written information, analyze what and how the game components can be tested. It is the responsibility of testers to read all the relevant documentation so they can share (to understand and appreciate) the mission of the project […]. You are required to develop a Testing Requirements document for each game by outlining what and how the game and game components will be tested. The document includes:

* a list of features,

* the specifics of the internal design and external designs of the game. This may require a description of the possible implementations if it makes the testing requirements easier to understand (e.g., certain theme of the game, the characters, the animation, the AI, cinematic or camera view, and so on). For example, to test the multi-directional fight action for the Chan PS2 game, you must make reference to the use of “Ring of Engagement”, describe how the opponents engage into the fight scene, and what you expect the single/combination fighting actions.

* a testing structure detailing if and how Game Testing and/or Software Testing is applied (i.e., in a spreadsheet format for the items identified above),

* the testing criteria (e.g., ideas for testing), and

* the completion criteria (e.g., what are the expected results, what does “something is done” or “something is working” mean to you in game testing?) After the testing requirements are identified, the Technical Director for the game and the Software Quality Director will review the document to confirm scope and priority. Following the test requirements, the testers work on their own test design and develop a Test Plan and Test Cases. Any testing dependency requirements must be identified and communicated to the game team so the game code is “test-enabled”, i.e., what kind of cheat codes, or “test automation-enabled” code are required?

The testing documentation is expected to be developed in the early stage of the project, i.e., draft testing documentation is produced when we have the first playable build. It is important to note that the testing requirements will not cover every single detail of the game, but it must cover testing all the contractually required elements (e.g. specific features and the major game functionality). You can obtain this information from the game Technical Director.

DEFINE THE TIME LINE REQUIREMENT

When a game project is pressed for time, we must recognize the existence of a threshold point where sufficient time line must be provided for the testers to perform:

* a number of iterations for testing each new or updated game features,

* a complete cycle of regression testing for each build,

*sufficient regression testing of the previously Critical, Closed bugs, and

* a full regression testing expecting to test every event/world/environment object and triggers in the game for Alpha, Beta and Final. This “threshold” point varies from game to game, the tester is expected to communicate the“bare bone” testing requirement with the Producer and/or Project Manager.

Well, as you can see, Testing Games is not that simple. There is a lot, and when I say a LOT, I mean a LOT of things that you have to read and study about. However, just reading and studying is not enough to be a good Game Tester. You have to deal with the real thing and get into the market – as hard as that can be.

Wait for the second part of this text and hope someone out there can understand and use this at work!