Software Testing in Gaming. What Is That and Why?

What Is a Game?

In this world, the gaming industry is one of the largest segments of the entertainment industry, alongside the cinema. All sorts of computer, console, mobile, and browser games are released. They give us a chance to feel cool, a winner in a virtual world. But how often do we give some thought to what the game actually is?

A game is a competitive process in which the player is involved. At the end the player receives a reward or punishment. The game rules determine their amount and type as well as game duration, actions, and game process.

Getting a reward creates an emotional connection between the player and the game. Everyone is happy to get a carrot but no one wants to get a stick. The game grants the player happiness as they passed a level or received something from the game, which they sought for a long time. But the player is also physically connected to the game.

I will never forget when I met the person who passed the Mirror’s Edge for the first time. In this game, the character jumps on rooftops and makes pirouettes unimaginable for the human brain and body. With every movement of the character on the screen, with every movement of the camera, my friend moved. He was so attached to the process that he physically tried to mirror the character’s movements on the screen! How many times have we tried to look around the corner by turning our heads? And this is not only true for games that are specially made in this way. Even city builders, games where the main idea is to build a city, give their physical connection. A person looks at his city and thinks about whether it is beautiful or not. They evaluate it with his eyes. They like what they see! It is this mix of emotional and physical contact that makes gaming such a unique form of entertainment!

That’s great, you might say, but how is this related to game testing?

Well, how do I start?

1. Balance

People who play multiplayer games have probably heard this word before.

What is balance? Balance is a set of tables, each of which is responsible for a different set of objects in the game. Each of the tables contains a list of names and a set of values ​​that are needed for a given object in the game. For example, the “Monster” will have the number of lives and the amount of damage received and dealt with it. The “Weapon” will have its unique qualities, rarity, type, amount of damage done, and so on. The balance is drawn up by the game designer.

When a game is developed, objects are added: weapons, buildings, items, monsters, enemies, friends, resources, or money. Using these objects, the creator sets up the process in which the player will be immersed. And now, when all the items are created, the creator, who is also a game designer, sets them up so that the gameplay is addictive and comfortable for the player. The game designer takes everything in the game and assigns its importance, value, and price. They put “weights” on the scales, where on one scale is written “reward”, and on the other – “punishment”. Like a king and a god, they can determine that one weapon does this much damage, and the other – that much. It is the game designer who is busy making sure that the monsters that the player meets at the initial level are simple enough.

So how do we test the balance? There are a few things I want to tell you about balance testing:

1. Comparison of the balance with the actual values ​​in the game

What is written in the balance tables does not mean that the same will be written in the game itself. First of all, you need to check what is in the tables and what the game actually shows. Perhaps someone entered incorrect data. Someone could make a mistake, and as a result, the weapon has a price 10 times more than it should be. If all the values ​​match our tables – good for us! If not, we definitely need to make a bug report about it!

2. Formulas

Some formulas calculate a part of the gameplay depending on the values. But they might have mistakes. They can be everywhere. Formulas are also written by a game designer, who gives information to testers: how they look, where they get the values ​​from, what value should be obtained. When we shake everything out of it, the first thing to do is look at the formula and substitute simple values ​​for it. For example, the formula for dealing damage to an enemy might look like this:

((base damage + “Strength” + weapon damage) * coefficient) – the percentage of enemy immunity

Unfortunately, the table can show the values ​​that will be giving us a headache, even with a simple formula. But after we substitute simple values: ((2 + 1 + 2) * 2) – 15%, it becomes easier for us to imagine the final result.

As we cleared up with formulas, we, as testers, need to arm ourselves with our tables and formulas and compare the actual result in the game with the expected one, calculated from the tables. If it matches –  good! If not, you should definitely write a bug report about it!

3. Process

Since the game is not static, we cannot test the balance by examining it only using our numbers. The game is a process, and only in the process itself can we check if the balance of the game is working. What if the very idea behind this calculation is wrong? What should it be? Should we make the game easier or harder? Are the win rewards and loss penalties configured correctly? Let’s talk about this.

Like all players, the tester spends some effort to get from point A to point B in the game. But, unlike the player, the tester really tests this time and effort against certain values. This is the same verification of expected and actual results! But if the actual result can be checked by going from point A to point B over and over again, comparing the results, then where to get the expected result? Again, from the same game designers. When a game designer writes a balance, they do not take it off the top of their head, or at least should not. For a game to play well, the game designer calculates how much effort and time it will take for the player to achieve the goal. For example: how many monsters does a player need to kill to get the second level? How many items to sell to be able to buy a new weapon or armor? How many times to hit the target to increase your shooting skill level? This is the first source of our information about the expected result.

The second source is the games we’ve played before. When we play some games, we memorize the mechanics, memorize the controls, and also memorize the balance. Every game we have played in the past is stored in our heads. This gaming experience in and outside of testing practice creates heuristics that help game testers every day. A very large part of the job of a game tester is comparing one similar game to another, and this is where you have to do a lot of work. How long does it take to get an achievement in another game? What if more time? Or less?

Someone might say, “We have our own game, they have their own,” and it is true. But comparing two similar games helps to find most of the problems in the balance, which the game designer did not even expect.

What if certain items are more expensive than in a similar game, and at some point, our game may become unplayable for the player in the future?

What if the opposite is true and we are giving too many resources?

What if our levels, compared to another game, are drawn out in time?

Shouldn’t we give the player a break? Here you shouldn’t jump on bug reports right away, but you should conduct this research, make a report on it and submit it to the game designer. If there is nothing to worry about and all the discrepancies are conceived or forgivable –  good for us! If not, we did a great job to make our players feel comfortable when playing our game!

2. Visual component

One of the most important parts of a game is its visuals. To fully describe what is needed and can be tested in the visual part, will take a month, maybe even more. But we will nevertheless look at some tricks and important aspects.

“Engine? I’ve heard this word many times! “, you might say. But let’s start with what is an engine?

An engine is a software that is made to create games. Developers use it to save time and money for the project instead of writing many rules and functions for the game themselves. The core functionality of a game engine includes a rendering engine for 2D or 3D graphics, physics engine or collision detection, sound, scripts, animation, artificial intelligence, networking, memory, control, multithreading, localization support, scenes and may include video support.

So what is engine testing?

First of all, it allows us to see how exactly an object is displayed. This is especially true for a first-person game. What we see on the screen is what our character sees. Keeping that in mind, we check how what we see looks like.

Are the objects correctly positioned on the map?

No trees are flying in the air?

Doesn’t light come out of the ground?

Do walls have a wall or floor texture?

If everything is displayed correctly – great! If not, feel free to make a bug report to the person who is responsible for this part of the game!

Secondly, the physics test. This implies testing how the player will physically react to objects and events. How the player will walk and at what speed, jump, and how high. What will be the reaction to a collision with a wall or meeting a monster? The first thing we need to learn there is the concept of collider. A collider is a setting that, when meeting another collider tells the game to react in a certain way. So, for example, if a character collider hits a wall collider, the character stops. You must check whether the player can get stuck in the collider or fall under it. You probably played games where at some point the character could fall through textures or move between them, but this was not intended to happen. This is exactly what needs to be tested! Stock up on patience and coffee, because we have to test all the corners of the world that we built!

Don’t forget to compare games! Comparing your game with other similar games can tell us what is different in our game physics. Does our character move faster? Should we slow it down? Our character jumps lower – is it worth paying attention to? Again, as with the balance comparison, the first argument you get is “we have our own game, they have theirs,” and that’s true. But it’s still research that needs to be done. Believe me, it is worth the time and effort spent on it! If nothing needs to be changed –  okay, good for us! If game designers decide that it is still worth taking a closer look at the experience in the industry that has already existed before us, we will make the game better for our players!

3. Workflow

The process of game development is quite simple and is similar among different companies. The game designer assigns tasks to developers and designers. Then goes the testing. Everything seems to be simple, right?

It is, but there is one huge BUT! Testers know the game better than anyone else. They know about the limitations that a game designer or a programmer has no idea about. It can be the limitations of the gameplay (how the player interacts with the game and how the game reacts to the player’s actions) or it can be events that can happen when adding one or the other. And the task reaches them at the very end when it is already either difficult or simply impossible to fix, and they will have to redo the entire task almost from the very beginning.

A true Jedi of game testing always pays attention to the tasks assigned to the developers and reads them. Believe me, this gives so much benefit that it more than covers the time that you, as a specialist, spent on reading the task!

First, the tester immediately understands what has to be tested. When this task reaches them, they are already ready. The process is several times faster.

Secondly, the tester immediately sees problems, errors, and undescribed scenarios unnoticed by a developer. “What if?” is the main question here. No bugs mean the game designer did everything right. This is usually not the case.

Talking of workflow, I would like to mention alpha and beta testing. This happens when a game developing releases the product for users as incomplete so that users can play, rate, and give feedback. I am in favor of alpha and beta testing, as in some cases it helps to tune the player’s experience of the game. Beta-player feedback can directly influence the final result. Two hundred players can test the game experience better than 5 or 7 testers and even 20 developers since they have a fresh point of view.

However, this paragraph is not about how I feel about beta tests. It is rather about how misunderstanding of beta testing has developed among the players. They believe that the game does not have enough testers to make it good or the way the players would like it. And I had that until we put the game into beta ourselves! We completely made the game, the main gameplay was good enough for the player to be comfortable, but the players on the forum started talking about the inconveniences of the game chat, that it does not work correctly and “has not been tested”. I calculated how many times, in total, testers checked the game chat before giving it to users. 320 times! Three hundred and twenty times of complete passing of all chat-related tests. And each time the run of tests was necessary for different reasons! Fortunately, the checklist was quite short, it took a little over two minutes to complete it. You may ask: is it a lot or a little? Everything is learned by comparison: while working on another project, I counted how many times a short checklist was passed, about the same size, from the beginning of testing to the moment when the feature was handed over to users. I counted 32 passes!

Yes, of course, I have chosen the most illustrative example! But if you happen to be a tester of a game that was released in beta, and read such messages from players – do not be discouraged! Just know that you are now on the other side of the barricades.

Of course, you won’t be able to describe everything that is tested in the game. But try to think about it differently. A game is the same program as other programs. It has fields and buttons, and some actions of the player trigger a certain game response. It also applies test design techniques and documentation of tests and bugs that we use to test a website or application. Exploratory tests are just as applicable to it as to any other application. If the game is mobile, then mobile testing techniques can also be applied. You can’t tell everything, but our QA courses will tell you about the techniques. Armed with this knowledge, you can make testing easier and more efficient, and the final product better! Isn’t that why we are here?

4. How much does it cost and is it worth it?

The game development process uses a huge amount of resources. Designers, programmers, game designers, testers, managers – we all work not for food, but money. In addition, all these people are extremely attached to their creations. The game becomes a child for us, and, like every parent, we want our child to be the best! And we all need a place for the development process, that is, we need an office. We won’t be able to develop just sitting on a chair because we need computers and devices to run the game. Besides, there are also marketing events that allow you to sell the game.

All this: costs, blood, sweat, tears, and money – can be completely destroyed by the absence of game testing. Because then the players will not get the pleasure from the game, which means they will not play it. This is pretty simple.

While good testing makes the player admire the result. The player will bring friends, and they will bring their friends! They will be happy to play the game over and over again. This unique and pleasant experience helps them to feel better and we do feel better as well because we gave them this opportunity!