A lot has changed in the gaming sphere in the past decade, from the old Ping-Pong when testers were not required to worry about variables such as browser compatibilities, operating systems or video cards to multifaceted games today with players often playing on different platforms, or even playing online. From the most complex triple-A console game to the simplest mobile game, it is up to the tester these days to save the player from frustration, confusion and lost time.
Why Gaming Testing is Important
The complex nature of the software required to deliver top quality games and contractual commitments make testing an essential part of the games. Every time someone outside of your team or company gets a look at the game, it is going to be scrutinized and publicized. It is important to the development team as they rely on testers to find problems in the code. Gaming testing is also significant for game publishers as an official release of the game should be error-free and marketable. Further, gaming testing is also important to console providers in order to meet quality standards. There is a parallel testing requirement for mobile game testing by wireless carriers and handset manufacturers so as to allow approval for use on mobile devices and networks.
Basic Rules for Gaming Testing
-
Stop Panicking
We all know that panic is bad for multiple reasons, including game testing and can lead a tester to cause severe harm to the project. It can result in wastage of crucial time, money, sales and reputation. Generally, game project panic occurs when you are:
- Unfamiliar
- Unprepared
- Under pressure
- Unrested
- Nearsighted
In such circumstances, it is important to ask yourself the following questions-
- Do you have the right version of the test?
- Are you using the right version of the build?
- Are you using the right hardware configuration/settings?
- Are you using the right game controller and settings?
- Which installation options did you use?
- Is the game in the right initial state before running the test case?
- Did you complete all of the test steps in order?
- Did you record all of the problems you found?
- If you reported a problem, did you fill in all of the required fields?
-
Trust Your Own Self (Only)
It may happen that the publisher may not trust your game, the press and public may consider your game unexciting or project managers may find loopholes in the test code, but don’t lose trust in yourself. Games that come with certain bugs can fall victim to complaints and rants posted on the Internet, sometimes rightfully so. But don’t let this happen to you!
It is crucial to conduct a background check, examine your tests and search for ways in which you can improve, in order to gain more trust in your own skills in finding defects. Further, always remain open to suggestions from developers, managers, other testers and most importantly, yourself.
The process of Game Testing
- Black box testing- Almost all game testing is black box testing, which is described as testing done from outside the application. It is not the case that game testers find defects merely by reading the game code. Rather, they try to find defects using the same input devices available to the average player, be it a mouse, a keyboard, a console gamepad, a motion sensor, or a plastic guitar.
- White box testing- As against black box testing, white box testing provides the tester with better prospects to exercise the source code directly and in ways that no player ever could. It can be a daunting challenge for the white box tester to read a piece of game code and predict every single interaction it will have with every other bit of code, and whether the programmer has accounted for every combination and order of inputs possible. However, because of impossibility to account for the complexity of the player feedback loop, testing a game using only white box methods is extremely difficult. Nevertheless, white box testing is more practical in certain circumstances such as:
- Tests performed before submitting new code for integration with the rest of the game.
- Testing code modules that will become part of a reusable library across multiple games or platforms.
- Testing code functions or methods forming essential parts of middleware or a game engine product.
- Writing Bugs- It won’t be an overstatement to say that bug writing is one of the most crucial skills a tester must learn. This is because no defect can be fixed unless it is communicated clearly and effectively. Since you can never find out exactly who will be reading your bug report, it always helps to write reports in a clear, objective and dispassionate manner. Further, never assume that those reading your bug report will be as familiar with the game as you are. Testers usually spend a lot more time in the game closely examining each asset and exploring every hidden path than anyone else on the entire project team. By making a good bug report, the tester ensures that a reader who is not familiar with the game has a fair sense of the severity and type of the defect/deficiency it describes.
The Life Cycle of a Build
The process of game testing comprises, primarily, of following steps:
- Plan and design the test- Although much of this is done early in the planning phase, planning and design should be revisited with every build. What has changed in the design spec since the last build? What have additional test cases been added? What new configurations will the game support? What features have been cut? The scope of testing should ensure that no new issues were introduced in the process of fixing bugs prior to this release.
- Prepare for testing- Tests, code, documents as well as test environment are required to be readied by their owners and also aligned with each other. It is also necessary for the development team to have marked the bugs which have been fixed for the build in the defect database in order to enable the QA team to verify those fixes and close the bugs.
- Perform the test- Always ensure to run the test suites against the new build. In case of a defect, test the bug to make certain you have all the details necessary to write a specific and concise bug report. More research in this direction will enable easier and more useful bug report.
- Report the results- Make sure you log the completed test suite and report any defects you found.
- Repair the bug-In this stage, the test team participates by ensuring availability to discuss the bug with the development team and provide any directed testing that a programmer might need to track the defect down.
These steps not only apply to black box testing but also to white box testing, configuration testing, compatibility testing as well as any other type of QA.
Connect with KiwiQA to leverage focused capability for QA and Testing services.