Game Testing Methodology1. INTRODUCTIONEffective 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.The purpose of this document is to explain the testing methodology for game development. This document is intended for the person performing the testing. The topics and the level of details provide an interesting and useful set of information for the Game Tester or Software Tester. There are a number of Quality Assurance and testing initiatives that are covered in this document, including a testing strategy, testing processes and techniques, test coverage criteria, Testing Requirements, a Test Plan definition, testing documentation, and “Full Cycle Testing”.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.This document must be used in conjunction with the other companion QA documents1. Game Testing Primer, 2. Testing Design for a game project, and3. Defect Reporting Guideline.2. TESTING STRATEGY2.1 SCOPE AND DEFINITIONIn 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.2.2 TESTING PHILOSOPHYTesting is NOT a single persons 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). 3. TESTING PLANNING AND TESTING REQUIREMENTS3.1 IDENTIFY THE TESTING REQUIREMENTSA 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. Please refer to the “Full Cycle Testing” section about how to conduct a quality review.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