In the first two articles, we looked at the types of testing used in game development and examples of bugs encountered in games. The unanswered question remained in the air, though: “How to test all this stuff?” In this article, I will share the approaches and tools I use to test different games, including games with large maps (e.g., the Battle Royal genre) or something more local, such as a sports simulator.
Cheat codes and cheat menus
Cheat codes were not initially easter eggs or tips for players so that they could load a certain level or set themselves infinite health/money, and were not even invented for saving, although they can be applied this way. Dev teams used cheat codes to debug games. Over time, the codes got to the people and became highly demanded.
Instead of codes that need to be memorized and entered for a long time, cheat menus are used, which already contain lists of cheat codes grouped in a convenient form. Players can call this list on almost any screen, but if a code does not fit the current conditions, it will not be executed (for example, if you try to spawn an object in the main menu). The cheat menu is not a typical functionality; each game has a unique look and a unique code responsible for its implementation.
However, with great power comes great responsibility – cheat codes can lead to bugs that cannot be reproduced in actual game conditions. For this reason, rather complex and even “strange” bugs need to be rechecked and reproduced without using cheat codes, and also always keep in mind the entire flow that a player must go through to stumble upon this problem. It should also be borne in mind that there is a high probability that a bug that is easily reproducible with the help of cheats is one that a player will never meet in practice.
P.S. Motherlode and Konami Code are forever in our hearts!
The in-game console is often used as a functional testing tool. Usually, pressing the “~” (tilde) drops out either at the bottom of a small line or at the top of the screen, taking up a decent part of it. Using the console on dev builds (for example, directly from the Unreal Editor), you can connect the back-end with test accounts you need, speed up or slow down the game (not FPS, but in-game actions and time), use cheat codes, turn on/off debug HUDs, and much more.
In-game heads-up displays (HUDs)
HUD widgets are extremely useful tools that, among other things, cannot be obtained without the help of developers. They are often invoked using a console command. Depending on how the developers set up the HUD, some information will display specific info. With the help of such elements, it is extremely convenient to monitor the damage done, the progress on challenges, consumable usage, and much more. As cheat menus, HUDs are explicitly developed for debugging needs and may not be in your game.
Weapon room/raining room
This kind of room usually contains weapons, characters, enemies (including bosses), surfaces, items and consumables, vehicles, etc. In general, everything necessary and theoretically necessary for testing during gameplay can be there. In addition to all of the above, in such spaces, a game tester can create rooms for particular needs: for example, objects can be placed in such a way as to check whether an obstacle of a certain size protects you in a squat, standing, etc.; in another room, you can check if your character is walking between objects, etc. Such spaces are usually found in reasonably big games, because you need a budget to design them.
Configuration files are ubiquitous, and you can use them for various needs. There are more such files in the dev builds than in the release version, and through them, you can enable/disable features, change permissions, control the logging level, specify which back-end to connect to, manage graphics settings, and much more. The number and scope of available settings and their format can differ dramatically from game to game, even if the games are written on the same engine.
Managing your internet connection
An essential verification nowadays is the network connection. Even single-player games can be (and are most often found) elements tied to being online. Unfortunately, there is no unique and comprehensive tool here. Personally, it is pleasant and convenient for me to use the Clumsy tool as an assistant in this matter. The program does not manipulate the game, but your connection as a whole on your device, which makes Clumsy a convenient tool for managing your connection for absolutely any need: web app, standalone software, games, etc.
Game engines have functionality such as “view modes” that help you see the type of data processing in your scene and diagnose any errors or unexpected results. The most common view modes have their own hotkeys, which may differ from engine to engine, but you can always view them all from the view mode or call them using the appropriate command in the console. Below I will provide a few examples based on View Modes from the Unreal Engine. You can read more in the engine documentation. Let’s take a look at a few of them.
Lit view mode shows the final result of your scene once all of the materials and lighting are applied.
Unlit view mode removes all lighting from the scene, showing you base color only.
The wireframe shows all of the polygon edges in the scene. In the case of brushes, you will see the resultant geometry. Polygon edge line color can have an additional function. Or it may not. tThen, conventionally, all edges are black.
Reflections view mode overrides all materials with a flat normal and a roughness of 0, which is a mirror. This is useful for diagnosing the detail of reflections and allowing you to place more reflection capture actors in areas where you need more detail.
Digital game shops’ toolkit
All digital shops provide developers with their toolkit for downloading and testing the game through their systems. For example, Steam allows you to switch languages (localization) through the Properties menu of your game, launch the game with your parameters, check the integrity of the game files, manually check for updates from your CI/CD system, and much more!
An example of adding your game (dev build) to your Steam collection
In many cases, testers don’t need to use an Editor build because most of the needs are covered, by default, in a Game Shop’s build, and this build is as close as possible to what the end player will receive.
Common project tools that can be useful in game testing
Speaking of tools that are not directly related to testing but can make your life easier, I would highlight the following: VCS (Perforce, Git), game engine editors, Grafana, and Playfab.
Version Control Systems (VCS)
I won’t talk much about Perforce and Git because these are common Version Control System programs and are essential workflow elements for most projects. With Perforce, you can download a dev build, upload your changes, select and use a specific build number (Change List), make files available for editing (Check Out), set the settings you need, etc. Often game projects also use Git, but Perforce and Git are used for different needs. For example, Perforce is used to work with the client and Git to work with the back-end part. You can read more about Perforce on their official website, and I highly recommend that you familiarize yourself with it.
If you do not want to suffer from learning Perforce, but at the same time, you need the ability to collect builds with certain CLs, then such an ecellent tool such as UnrealGameSync (UGS) will always come to your aid. In this case, it is a tool for the Unreal Engine that allows you to see and filter the CLs in the repository. With UGS, it is extremely convenient to track the latest changes and collect a new build – just double-click on the desired CL, and the process will go!
We have about the same story with the game engine editor. You can reconfigure the elements you need inside the game before launching it and launch in either “editor” mode (the game is launched in the ViewPort of your engine) or in “standalone” mode. You can fulfill any of your wishes and preferences. Still, you often need to test the game on “finalized” builds, which can either be downloaded from your internal resources after completing the next CI/CD process or played directly through digital shops like Steam. It is also worth mentioning that the editor may not be available in some custom engines.
Grafana is a metrics visualization dashboard used by many team members. A handytool during performance and network testing due to the ability to monitor the number of actual and simulated players at a given time, displaying a limited amount of information for external teams in your process, and much more. You can read more about this tool here.
I think it’s also worth mentioning Playfab; a ready-made back-end provided by Microsoft by subscription, which combines accounts from different games into a single (master) account, and helps set up the in-game economy without “unnecessary” coding. As part of testing, Playfab will not be used often (it is NOT a testing tool, like most the tools in this section). Still, it can be interesting to check the correctness of use, for example, analytics attached to your functionality. Who wouldn’t use analytics for BattlePass or progression systems?
On the Playfab website, you can see many games using this product. Among them are Doom Eternal, Minecraft, Roblox, Gears 5, and many more! You can view an overview of the features provided by Playfab on their website.
Tools from console vendors
At the end of this section, I will clarify that all console vendors have tools for communicating and working with dev- and test-kits. These programs have many useful functions, such as collecting logs, working with save data, collecting information when the game crashes, using extended resources of dev-kits, emulating work with online services without direct connection to them, remote control, and much more! In 2020, all these programs began to improve the existing functionality for remote control of consoles, which is extremely convenient for modern realities.
An example of using the Nintendo Target Manager found on the Internet
So what is the bottom line?
As you can see, game testing is a complex, multi-stage process that includes a wide variety of testing types, including specific ones that you will not find in other “genres” of programs. You can start testing games andanything else with simple tasks, knowing only the basis for the junior position and understanding what and how the gaming industry lives. This does not require higher education in gaming at all!
As with everything, you will need to gain experience in different tools to become a specialist. You will need analytical qualities to help you in this direction; analytical and in-depth skills, video game knowledge, structure and mechanics, ability to work under pressure, etc. Game testing is a kind of raid boss, and you need an appropriate level of specialty to defeat it. To get such a specialist, it is usually not enough just to hire an “experienced QA engineer” to suddenly materialize a cool Game QA. You need someone with specific gaming experience. Learn more about our Gaming Studio.