Top 7 Reasons Why Video Game Testing Is Essential

Stability/Reliability

The stability & reliability of the game is another significant factor in gamer satisfaction. It can have a direct link to the amount of time that a player will spend with a game. If you don’t ensure stability or reliability in your game, then your player base will suffer.

An example of this could be a multiplayer game that has network lag that makes it unplayable. It is worth checking that an online lobby will work at an acceptable level with 2 players or 60 players. The development team must decide what is satisfactory and test against those standards. If you make improvements to lag, but a 60 player server is still problematic, that might be a case to adjust the goals of the project. The trade-off of reducing the player lobby to 30 may provide a better experience.

Varying performance can be a huge deterrent to people that want to play with the most up to date graphics. Many people will find it distracting if the game has screen tearing or low framerates. This can be particularly the case if they have high expectations after buying a next-gen console, such as the PlayStation 5 or Xbox Series X. However, you can also make a subjective argument about artistic choice when it comes to visuals. Many indie developers choose to use pixelated graphics and there is a huge market of games where high fidelity is not a key element. It is important to have a plan about what the game should look like and be able to achieve that reliably. Again this may be another area where the developers decide to reduce their original plans to pursue stable performance.

Speaking of multiple platforms, the game should look and feel similar across the same generation of consoles. The recent release of the next-gen of consoles always brings up bad faith “console wars” disputes, with discussions of how one side cannot perform as well as the other one. Ideally, games should perform in the same way on both consoles, or at the very least, not have a negative experience only on one side. After all, a low percentage of gamers have both consoles, so you want to tap into that market on both sides. This concept gets more complicated when you add in PC gaming, as you can build a machine with so many different components.

Soft locks are when you can’t progress in the game no matter what you do. Examples of this are when something doesn’t unlock, or your character gets trapped in a room. Soft locks will create confusion in the gamer and then frustration at not being able to progress. A full out crash can often lead to rage quits, especially if the player was performing well up until that point. There’s often a feeling of not wanting to play through all the same content again, meaning that a player might not pick up your game again. Generally, any issues related to this will come up naturally during testing, so long as your test plan is extensive enough. Despite this, they can be difficult to debug and fix when they come up randomly, and can sometimes get through the released game.

Qualitative Feedback

Is the game fun to play? Is this game actually what we wanted to make? It might seem like a basic idea, but focusing on whether the game works without bugs or crashes can make it easy to forget to pay attention to these factors. Focused qualitative feedback points out changes that could be made to make it more fun to play. There should also be attention on how to fulfil other targets, such as making it more RPG-like, or how to make the narrative flow better, etc.

It wouldn’t be classified as a bug but clicking through 10 menus to get into the game doesn’t lend itself to a great user experience (depending on the game). Having testers run through your menus will help them to experience that frustration which they can offer feedback on. Other aspects, such as unbalanced weapons or jumps being too floaty are also useful pieces of information. This type of feedback could either simply be “this is not good, we should fix it” or also include suggestions of how to change it. This is a good opportunity for aspiring game designers to flex their design muscles.

A designer can go back to look at the system and make tweaks, or even completely redo systems. They also may not want to make any changes at all. Video games are just like any other art or media, so a lot of creative decisions are subjective and down to preference. No matter what action is taken, this feedback loop is a big part of the polishing stage of creating a game.

Fulfilling Design Criteria

Another simple concept is looking at whether the game that is being created is actually what was originally planned. It’s natural that things grow and change throughout the development process, so designs may change. But there are many reasons to check back to your game design document to check whether you’re following the criteria. The team may wish to redirect to stay on track with the plan, or they may decide to change the criteria itself. Whichever they choose, it should be a conscious decision.

This document can also be directly used as a tool to create test plans for the game. In early prototyping and development, various systems may only be partially implemented or broken. This means that a tester might not realize how a particular feature is intended to work. Once all areas are “open for testing” (i.e. all the features are complete), they can use the design document as a review whether the test plan is thorough enough to check all functions.

It’s easy to come up with lots of ideas while working on a video game, but there is rarely enough money, time or people to implement them all. Trying to focus on too much at once will affect the quality and players at the end will struggle with a game that is trying to do too many things.

Regularly checking back to a strong game design document helps ensure that the project is following its criteria. This is a good way to help the game be the best it can be. Making the conscious effort to check the design can allow the development team to make informed choices if they do decide to change things.

Developers won’t test as well as QA professionals

I’ve heard people say “why do you need QA, just get devs to write better code”. It’s a great idea in theory, but you have to remember that developers don’t set out to write buggy code in the first place! Everybody makes mistakes. Without testers there to find the bugs, you might not even notice your own mistakes. It’s like getting a friend to proofread your essay or resume; it’s easy to become blind to your mistakes. Especially if you don’t realize they’re mistakes to begin with! 

QA is a fully-fledged career and has a distinct skill set that a developer may not have. There are elements of overlap, but the fact that QA Quest exists shows that there is a strong career pathway that will differ a lot from that of a developer!

Development runs more smoothly if you can have QA testing at the same time as engineers coding. Submitting a new piece of code and immediately uncovering a bug in testing is very efficient. This is because it’s easier to fix a bug in recently written code than waiting a few weeks and then getting the programmer to go back into a system that they last looked at a month ago. These are complex systems and there shouldn’t be expectations that developers remember everything. The amount of other new code in that time will only make the debugging harder. 

Games are very complex and sometimes broken isn’t noticeable. Developers will generally focus on their own areas. So if they code combat, they’re less likely to look outside of that. They’re unlikely to notice a broken interaction with the UI or animation because that’s simply not their area. When you’re not specifically looking, you tend to only catch the worst bugs. QA on the other hand will take a more holistic approach, and be looking for those problems in interaction between different systems.

 Even with solo developer indie developments, where the same person will have to code and test, it is useful to keep in mind that they are separate activities. As Ron Swanson says “Never half-ass two things, whole-ass one thing”. Put on your programming hat when you’re writing code, and your QA hat when you’re testing. Doing both at the same time will not get you the best results. 

Player Testing is not as useful as it seems

It has become popular in the last few years to have players contribute to the QA process for upcoming games. Common methods are using an open beta to stress test your servers or giving them early access to provide feedback. It can seem like a great solution, especially considering that you don’t have to pay them, but there are several faults with this approach. 

Despite the amount of passion and time players may have for your game, they aren’t necessarily good at testing. Depending on the current quality level of the game, most will only find the most severe or surface-level issues. A lot of people struggle to explain the problems they’re seeing. While they may want to be helpful when they find an issue, it can often take a lot of time and communication to pass the information back to the dev team. This work is part of the QA team’s main function, so they will be more efficient and in-depth. 

Giving constructive feedback is a skill that needs to be learnt in any field. Excluding trolls, sometimes a player won’t be able to identify why they dislike something. It’s also less likely that they will think up solutions that would actually help fix the issue. Player feedback is obviously very important, but relying on it more than members of the development team is a mistake. This is especially true where they don’t have internal context from the team. Having a QA team working with player responses and converting it into workable feedback is a more ideal process that has a higher value. 

As previously mentioned, beta testing for bigger titles that have large online components is common. The game should be mostly completed already, so players shouldn’t encounter many bugs. However, any bug they do encounter could be a deciding factor to not buy the game. Early Access has also had varying degrees of success because of this. It depends a lot on the quality of the game as it goes live, how committed the community is to the promise of the game, and on the developer to keeping communications open. Steam more recently announced a Playtesting feature, but the jury is out on how well that is going to perform.

Player testing can definitely have value, but it must be very cautiously implemented to get the most value. Ensuring that people still want to buy the game after it has allowed them to test it should be the main priority. The intention can be to create hype for your game with a beta, but it could have the opposite effect. So the next time you enter a beta test as a player, keep these ideas in mind and see how much value you can bring to the developers!

Money

Here’s the bottom line. The reasons listed above help to efficiently improve the quality of the game and preserve your relationship with your fans. After all, if your game is good, more people will want to play it and you’ll hopefully sell more copies. Releasing a buggy game can affect your company’s reputation negatively. This isn’t always the case (looking at you, Bethesda) but you have to put in a lot of work to encourage gamers to sign on for that experience. 

You do all this testing work to raise the quality of your game because you want it to sell well and make some money. Even if you’re not a giant studio racking in millions of dollars of profit for shareholders, you at least want to make enough so that your employees can eat, live and continue to make more games. Creating games is a creative endeavor and the industry is filled with passionate and hard-working developers. But it’s a hard reality that a team needs money for that process to exist.