7 Tips to make your Game QA Testing process more effective

QA testing is a critical process in game development, so we thought it might be helpful to share some things we’ve learnt as a studio to make things more efficient! From writing test cases to bug reports, here are some tips and advice to game testing from our team’s QA Developer, Ronnie 🙂

1. Reduce ambiguity with open and frequent communication

Remember that QA is a support role! Having good communication with devs, designers, artists or whoever is responsible for the different areas of the game that you are looking at helps ensure that there’s clarity for everyone. Ask questions to help yourself understand what you need to do and look out for, it’ll help you be better at providing that support. This also means you can work faster and there’s less passing tasks back and forth.

For example: If you’re jumping into a project that is towards the end of development, there will be plenty that you are unfamiliar with. It’s a good time to ask questions, no matter how obvious the answers may seem. What you think is in the game by design might actually be a bug. Alternatively, if it’s the other way around, that might be a red flag that something is not being conveyed as intended.

“Everytime I fall off a platform, I respawn at the beginning of the level instead of the nearest platform. Is this by design or does it sound like a bug?”

2. Be concise, particularly when writing bug reports

Being concise is useful in many areas of your QA work such as writing test cases or even when asking questions to your team. In particular, being concise with your bug reports will (along with Tip 1) help reduce ambiguity and the back and forth between you and the dev team. 

It’s important that you give as much information as possible, you might not know how the information is useful (doing QA testing isn’t about fixing bugs, more about finding them and helping with processes that prevent them). But that information also needs to be easy to understand. If information isn’t communicated well, devs may try and work on a solution to a problem that isn’t actually there. This slows down progress and is a longer road to the solution.

Give as much information as you can in as few words as possible. To write concise bug reports, here are some things to keep in mind:

• Use a consistent format that is easy for the reader to follow. E.g. title→reproduction steps→expected result→actual result→reproducibility→version→platforms etc.  
• Where possible, using game dev language language/terminology will help you be more specific and describe accurately. For example: 
  • If you write ‘the player’ do you mean ‘user’ or ‘player game object’? 
  • If you write ‘sound’ do you mean ‘sfx’ or ‘music’? 
  • If you write ‘interaction between players’ do you mean ‘collision between objects’ or something else? 
• Include images and videos as much as possible that are named appropriately. E.g. instead of ‘Screenshot-20221125.png’ use something like ‘JumpNotTriggering-20221125.png’

3. Use your experience as a player and/or game dev)

At times QA testing and looking for bugs can feel like a bit of a guessing game, so you’ll have to accept that you won’t catch everything at once! One thing to consider is looking at the game from different perspectives. Try and consider the following perspectives when looking for bugs: 

User’s perspective (new player and experienced player)

As someone who plays games I know where things sometimes go wrong (based on games previously played). Often, when you’ve spent a lot of time with a game (doing QA), it’s easy to ignore a new player’s perspective. A new player will also probably find it harder to look past or progress past some of the bugs they encounter.

For example, you’ve played a level many times so you know exactly where to go. A platformer where you only need to move right so you never encounter the bug that occurs when moving left. However a new player may go in a different direction (start the level by moving left).

More important than the game breaking in abnormal situations is if the game breaks under a combination of variables that is more likely to be seen by a new and inexperienced player. For example, going to some obscure/hard to reach place in a game.

Game development perspective

If you make games (or have some knowledge of that process), then you can also understand where things can go wrong in more detail. Having some level of understanding of what’s going on under the hood helps you get some understanding of the types of ways things can go wrong. 

For example, sometimes character states get stuck during a respawn. You may be in a crouched state and upon respawning the character is still crouched. Prior game dev work may have taught you that this kind of bug comes up often therefore you know it’s something to test in future games with similar gameplay.

4. Don’t just find bugs, give feedback on the different areas of the game

Your goal is to make the product better. Finding bugs is just one aspect of that but providing feedback on any area of the game that you are comfortable talking about is useful. For example:

• You might find that something about the UI is confusing
• Something part of a level is unintentionally frustrating
• A sound effect starts sounding repetitive and annoying after some time with the game

Those are the types of things you may notice and providing that feedback to the team is another way you can contribute to making the product better. You as QA developer are one of the people who spends a lot of time with the game so your feedback is particularly valuable!

Even though it’s not your role to find the solution, your feedback in these various areas might be useful. The team members responsible for those aspects of the game can look into it further after that.

5. Use and request debug features/tools where it is suitable 

After spending more time in the role, I understand the importance of having QA specific features/tools put into development builds of a game.

This might feel like it’s something to avoid because adding them in takes up dev time. But the faster you are able to do QA, the better that it is for the entire process because issues will be found quicker and fixed quicker. In the long run, it is useful and even more worthwhile for live games, because you will have to test things repeatedly with new versions. You want to be able to jump in and specifically test what’s required without having to play the whole game from the start.

One example of this is when save files are not carried over when a new build is created or in cases where you need to start new save files very often. This could lead to situations where you’re constantly having to spend a long time getting through the game just so you can test something on the final few levels of the game. When you notice this, it would be a good thing to flag with the dev time as they might be able to implement something that unlocks all the levels for you, saving everyone’s time.

6. Remember that your tests will improve as you spend more time with the game

The test cases that you write for your game will become more detailed and level specific as you spend more time with the game. This means your tests won’t be perfect from the start and won’t cover all bases. 

It’s important to treat test cases and your other testing resources as living documents. Keep in mind that this means it will become more complex and long. So it’s important to keep it as well structured as possible even though it might be a little vague and light on details to start. Those gaps will fill in as you learn more about the game. 

For example, you might find that each level in your game requires specific checks and the same test cannot be carried out for all levels. One reason could be that achievement triggers need to be checked in some levels that require certain actions. This is something you may not take into account in the first couple of iterations of your full playthrough test but may eventually find a way in. 

The structure of your test will be important here to ensure that new additions to the test can slot and maintain a nice flow. Your testing for a full playthrough of a game could be written in a top to bottom manner, broken up into sections that are easy to step through. When more details are made clear they can be slotted into the various parts of your test. E.g. new game screen→menus/options→level 1→level2→level 3→dlc→saving/progress checks. Each section essentially being a small group of related test cases.

7. Manage testing by their order, not difficulty

You might have a lot of little tasks, little bugs that have been addressed and minor features that have been added at the last minute which need QA testing. This may happen when the team is closing in on release or a new patch – this is when you’re the busiest. It can be tempting to deal with the hardest/easiest ones first however this can cause problems/become inconvenient.

Working through tasks in the order that they’re passed to you (as much as possible) might be useful in ensuring: 

• The team receives feedback on each item as soon as possible.
• The way you’re working is the reason for merge conflicts (which could be minor but can also just be avoided) 
• You’re not overwhelmed (as you’re following a process that keeps you organised)

For example, you’ve been asked to test various features and fixes. You receive them in the following order: 

1. UI fixes (easy to test)
2. Gameplay features (hard to test)
3. UI features (uncertain on how long this will take to test)

Let’s say you’re reasonably confident that the ‘Gameplay features’ will be the hardest to test so you start working on this before ‘UI fixes’. It might feel like a good idea because you’re getting the hardest and largest chunk of work out of the way first. However if this does take as long as you expect, it could also mean: 

• The team is not getting timely feedback they need on the changes that were part of the UI fixes.
• The team may have started working on adjacent parts of the game such as the UI features. However, since the UI fixes have not been merged yet (since they haven’t been tested yet), there may be issues that carry over. Particularly, if the UI fixes eventually fail your testing. Even if the UI fixes do pass testing, you might find it unexpectedly conflicts with changes that were recently merged if a lot of changes have been made.
• Your backlog of features and bug fixes to look at grows unexpectedly and becomes difficult to manage.

In sum, good communication and an understanding of game development tools and terminology (or willingness to learn!) equals better QA testing and efficiency! We hope that this list of tips will help you in your game development processes!

Have a question or want to chat more about game development? Reach out to us!

Other places you can find us:

• Join our Discord server
• Sign up to our newsletter