Tag Archives: test case

QA 101: How to write awesome Test Cases

Are you looking to get started in testing for the gaming industry? Are you a more seasoned quality professional looking to level up your skills? Are you curious to learn more about what testing video games is really like? If you said yes to any the above, then the QA 101 series is for you! We aim to teach the basics of quality assurance by going back to the fundamentals. Each article will contain essential information to explain everything you need to know!

In our last article, How to create a Test Suite, we focused on creating test suites for a game project. We put together an outline of features that we should test and thought about different testing scenarios. Through this, we have a good idea of the types of ways in which to test the features of our game. It’s now time to move on to writing test cases!

What does a test case need?

First things first: What do you actually need to include in a test case? While different projects require different amounts of documentation around this, there tends to be a standard set of basics that you should always consider including.

Test Case ID

It’s a good idea to associate a Test Case ID with each of your test cases. If you’re using a test repository program, the ID will likely be added automatically. The reasoning for using an ID is because you’re likely to have many tests that are similar to each other. It’s easier to tell somebody that test 539 failed, rather than “That one test that checks the cooldown animation on the mage NPCs in the woodland forest. No, not the healers, just the black mages…”.

Test Case Title

Test titles need to be descriptive, but not exhaustive. You want a good idea of what the test is supposed to look at, but you also want to make it clear what the pass criteria are. For example, a test with the title “Login to server” is far too broad, and doesn’t suggest what the expectations are. “Server login failure with incorrect credentials” or “Login failure with offline server” are much better titles. Although these 2 tests are looking at similar things, you can tell at a glance how they differ. You do not need to write the exact expected results in the title, as these should be expanded within the test case itself.


Environment describes the hardware, software or configurations needed to run a test. For game testing, this can be as simple as whether you’re testing on a PlayStation or Xbox. This may not be necessary to include in every single test as you might set up your test suites to cover platforms separately. However, it’s important to ensure that the tester is set up correctly so that any test results are reflective of the intended testing.


Similar to environment information, there may be additional set up steps that the tester will need when running this test. Often this will be setting up when and where the test takes place, such as a level or checkpoint. Sometimes it’s essential that another test case has been run first. Whether that’s to get to a certain point in the game or ensuring another system works. For example, it’s pointless to run a test case that ensures multiplayer matchmaking works as intended if you cannot join an online lobby. Having the pre-condition that a lobby join test case passes beforehand is useful to prevent wasted time running tests that you should logically know will fail.

Test steps

These are the individual descriptive steps that a tester will perform to run the test. These need to be in-depth enough that anybody could run through them precisely. Remember that QA members aren’t the only people that look at tests. You’ll need to make sure any developer, artist, or even somebody on their first day on the team will understand the instructions! Some QA teams are close-knit, small and only have members that have been on the team for a long time. Because of this, test steps will often be written vaguely. This can leave you with situations where tests are run slightly differently by different people. This can produce different results and misunderstandings between team members. It’s also harder for new testers to learn the system and know what the correct usage is if the instructions are unclear.

Expected results

Expected results are exactly what they sound like: What should happen once you’ve run the test steps. They are the second most important aspect after the test steps themselves. You can use the expected results to describe the behaviour for each individual step or for the test as a whole. This helps to make sure that the tester knows what is supposed to happen. Sometimes a game will look good on the surface level, but ultimately isn’t fulfilling the expected design criteria.

How do you write a good test case?

  • Make sure all your steps are clear and concise. Sometimes including screenshots, gifs, or videos is the easiest way to be the most accurate.
  • Use standards or uniform styling to make the steps easier to read. This can be things like bolding names of files, levels and similar. Doing this makes it easier to scan the test and pick out the important pieces of information.
  • Do not make any assumptions about the testers knowledge or leave out information. You should always assume that you won’t be the one running the test. It’s good practice to get into the mindset of someone who has never even booted up the game before. This way you can ensure that you do not miss any details.
  • At the same time, you should try to reduce redundancy. Make sure that you’re not testing the same things over and over again in a test suite. Consider using the pre-conditions to ask a tester to run another test first if that makes more sense. You may also want to consider using tooling for your testing. Having to play through to a certain section of a level each time is redundant testing. Having a debug tool or a save file would allow you to start exactly where you need to be every time.
  • Having good test data, such as appropriate save files, is really useful. You need to ensure that they can be reverted back to the same state as before you ran the test (ie. don’t lose the checkpoint to a more up to date autosave). This is also true of different character unlocks, such as skins or abilities.
  • Remember that with testing, you need to have a healthy mix of valid & invalid testing. You want to make sure that all the intended behaviours exist, but you also want to see what happens with non-intentional behaviour. For example, does the game crash when you can’t connect to a server? What happens when you try to select a character that isn’t unlocked yet? With this, you’ll also want to check that the game gives appropriate feedback to the player.
  • If the test is too long you should try breaking it up into smaller tests. You could also consider adding test data or debug tools that help you to skip steps. For functional testing, it’s ideal to try to limit the number of ways that an individual test can fail. The more steps you have, the more ways that one test can fail and it becomes too broad. You would have to rerun this entire test when a fix has been made, and it can be time-consuming to go through it all to confirm the step now runs correctly.
  • Revise/Update often! The game will change throughout development. You’ll come across situations that you hadn’t realized before. You might want to change some of the test data that is used for particular tests. It is healthy to keep checking your test cases are good enough for the level of quality you’re looking to assure!

What does a test case look like?

We’ve done a lot of describing test cases so far, but it’s honestly easier to demonstrate these practices with an example. Let’s take another look at Tetris!

Test Case ID: 001
Test Title: Block Movement

Environment: NES Build
Preconditions: Load into the game with the following settings: 1 Player – Level 0 – Handicap 0
Test Steps:

StepInsructionsExpected Behaviour
1Observe falling block with no gamepad inputsThe block should move downwards incrementally allowing the player to input button presses
2Press Left button once on gamepad (short press)The block should move one unit to the left
3Press & hold Left button on gamepad (long press)The block will continue to move unit by unit to the left side of the playing area
4Press Right button once on gamepad (short press)The block should move one unit to the right
5Press & hold Right button on gamepad (long press)The block will continue to move unit by unit to the right side of the playing area
6Press Up button on the gamepad once (short press)The block should immediately drop to the bottom of the playing area in line with its position when the button was pressed
7Press & hold Up button on the gamepad (long press)The block should immediately drop to the bottom of the playing area in line with its position when the button was pressed. The newly spawned pieces should also continue to drop to the bottom of the screen as soon as they appear on screen
8Press Down button on the gamepad (short press & long press)The block should speed up its descent to the bottom of the playing area only the down button is pressed
9Press A button once on gamepad (short press)The block should rotate clockwise 90° 
10Press & hold A button on gamepad (long press)The block should rotate clockwise 90° once, but should not continue rotating more as the button is held
11Press B button once on gamepad (short press)The block should rotate anti-clockwise 90° 
12Press & hold B button on gamepad (long press)The block should rotate anti-clockwise 90° once, but should not continue rotating more as the button is held

Expected Results: All button presses should result in the expected movements, without any additional unwanted behaviour.

Hopefully this article gives you a much clearer idea of what test cases look like, and gives you an understanding of how to create them! They’re the backbone of every testing team, so making sure that you use good practices can really set the QA team up for success.

Other posts in the QA101 series:

QA101: How to create a Test Suite

Are you looking to get started in testing for the gaming industry? Are you a more seasoned quality professional looking to level up your skills? Are you curious to learn more about what testing video games is really like? If you said yes to any the above, then the QA 101 series is for you! We aim to teach the basics of quality assurance by going back to the fundamentals. Each article will contain essential information to explain everything you need to know!

Put on your lab coats, because today the QA101 series is going to get practical. No more theory, we’re going to look into the process of writing test suites! If you’re still uncertain of the theory, then take a glance back at our piece on designing your test cases and test suites. If you’re already in the know, or once you’re all caught up, you’re ready to learn how to create test suites!

Which came first; the Test Suites or the Test Cases?

It might seem backwards but it’s often easier to think about the test suite before you have the test cases to go in it. There is no right or wrong order to this, but having guiding categories helps to structure your focus when writing the tests. If you’re working on a much larger team, you can even give the different suites to different QA members. They can add the test cases for each specific area, allowing them to focus in or partner with relevant members of the dev team.

The earlier you get working on test suites for the project, the easier it is to create your test cases. If the game ends up being huge, you can slowly add to your test coverage over time. Early in development, features will be incrementally added and improved upon. While this is happening you can summarize the feature with a test suite and write new test cases as they’re added. If you join much later and there are no tests for the many features, you’ve got a lot more ground to cover to catch up!

So where do you actually start? As mentioned before, some games are huge and have an expansive amount of content to test. The best way to explain how to do this is to break down this process by using a real-life but simpler example.

Testing Tetris

Say you are responsible for testing the original Tetris. It is a simple game in terms of its features compared to AAA games today. The first thing that you want to do is break down the features of the game. If your team has a Game Design Document, this information should be pretty easy to extract. If there’s no document, then a brainstorming session can help you to quickly pull out the main points. The idea isn’t to make this perfect on the first try but to create a very high-level skeleton.

Thanks to Tetris’ ubiquity, it is often used to teach game development and design theory. Because of this, I was able to find a Game Design Documentation created by students online. Using the information from their GDD and my own brainstorming I came up with these notes in about 5 minutes:

You may notice that I’ve brainstormed some test cases at the same time as the suites. This is important because they both inform each other. I focused on the gameplay mechanics, the controls, and the visuals/aesthetic, as these were the areas first outlined in the GDD. The gameplay mechanics of Tetris all revolve around the blocks; how they move, stack, and clear. Tetris wouldn’t be Tetris if it didn’t do these things, so they’re the first thing in the brainstorm. You’ll notice how I’ve highlighted some of these lines and suggested that they fall into more than one area.

Testing one thing, many ways

Let’s take the example of “Multiple Shapes”. The reason that I call this out as falling into many areas is because there are different ways to test this core gameplay element. You want to check that these shapes can spawn in and fall down the screen correctly. Each block has a different shape and will display a different pattern/colour. You want to test that the collision for each block is correct and will stack as expected when it hits the bottom. You’ll need to test that for every shape in the game because they’ll each have different collisions. You’ll need to check to see if the stacked blocks at the bottom continue to keep the correct collision. You will need to test that the controls for rotating, dropping and moving the pieces work as expected. And so on. All these tests focus on one thing (the blocks) but they’ll be tested in different ways. They can also be classified in different ways.

Sweeping into Suites

So what is the correct way to group these tests into suites? There really is no right answer! You could categorize them as I extracted from the GDD for the original brainstorm. But as we’ve just found out, you’d have tests for blocks all over the place. This could make it more difficult to construct test runs, especially if you want to focus on a particular feature. I would more likely set up multiple test suites like this for blocks alone:

  • Blocks – Gameplay
  • Blocks – Shapes
  • Blocks – Controls
  • Blocks – Collision
  • Blocks – Visuals
  • Etc.

Then other features outside of that that I could group are:

  • Field of play
  • Sidebar
  • Menus

To my logic, this makes the most sense, but there may be a need to switch it up depending on how development is going. For example, say you’re testing the gameplay of the blocks and it passes all tests except for the dropping feature. It would be useful to pull that out into its own suite or subgroup so you could give it the testing focus it deserves. Remember, as a member of QA you need to focus on the important areas of gameplay, but you also need to focus on risk. If a particular feature is breaking more often than others, that’s a good reason to spend time testing it more thoroughly. I’d be interested to hear from others how they would categorize suites for Tetris!

Early in development, having such specific testing is extremely useful. Active development is the most likely time that individual features will break, so this type of testing is valuable. Yet, when you’re a week away from release, the team should have fixed most of the issues. It no longer makes sense to check the blocks individually for their shapes, patterns and collisions. Hopefully, those features haven’t broken for a long while. This is where you’d start using smoke tests that would be more akin to “Start a game and play a level, ensure blocks rotate and drop”, etc.

Never stop adding new tests

You may notice that I missed out a REALLY important gameplay feature in my brainstorm. Do you know what it is? I’ll tell you the answer at the bottom of the article. Remember that this conceptualization stage is not the finalized testing plan; it’s just a starting place to help spark ideas. It can be helpful to try out the game and see what comes up in a play session. You can then add tests every time you realize that something isn’t covered. Sometimes testing will uncover tangential but unrelated bugs that you realise you hadn’t been looking for before. You’ll find that you’ll need to add tests often through the development of a game. However, remember that testing can also never be completely exhaustive. Blocks falling at level 1 may behave differently at level 100 (especially so with the speed multiplier in play). Would there be value in checking behaviours for every single level 1-100? Maybe not.

Putting it into practice

The original Tetris is a fairly simple game by today’s standards, but even within a 5-minute brainstorm, we’ve already come up with a sizable amount of tests. Upgrading that to Tetris Effect or Tetris 99 would explode the number of tests needed! You’ll need to add testing for online play or the more advanced visual effects. Even still the tests for that would likely be smaller than a 100-hour open-world RPG!

Try it for yourself! Think about another simple old-school game (like Pacman or Snake) and try to see the test cases & suites that you can think of. As a reminder, googling the name of the game and “game design doc” will likely bring up student’s work that can help you! Let me know in the comments or in a tweet what you come up with. I often see people talking about how QA is just “trying to break the game” or “running into walls”, but they don’t analytically think about how you try to do that. This exercise is a REALLY useful one for getting into the mindset of QA.

(* So what obvious thing did I miss out? In my test plan, I didn’t think about the lose condition, eg. Game Over. Pretty integral, huh?)

Other posts in the QA101 series:

QA101: How to Design your Test Cases and Test Suites

Are you looking to get started in testing for the gaming industry? Are you a more seasoned quality professional looking to level up your skills? Are you curious to learn more about what testing video games is really like? If you said yes to any the above, then the QA 101 series is for you! We aim to teach the basics of quality assurance by going back to the fundamentals. Each article will contain essential information to explain everything you need to know!

So you’re working through the test process. You’ve gotten through the initial planning and information collection. You can now move on to the design stage and begin devising the testing that you’re going to use on your project. Taking the gathered information, you start writing test cases. Once you’ve done that, you should collect them into test suites. But what is a test case? Why are test suites used? For some, these questions may sound like they have obvious answers. However, there are best practices that can help you design great tests. Testing is not exhaustive, after all, so you don’t want to waste time and money on low-value work. Understanding in more depth can help keep you focused and clear about what your tests and test suites could or should contain. 

Test Cases

A test case is a piece of actionable documentation that contains instructions of how to test. They generally are targeted on specific areas or features of the game. Sometimes described as “test scripts”, their aim is to confirm that the game is behaving in the intended or expected way.  Think of a test script the same as a coded script. If you run through the steps of the test exactly as written, you expect to get the same results every time. Unless there is a bug!

Writing test cases step by step is useful in many ways. A game development team is usually larger than one person, so good communication is key! You want every QA tester to check things in the same way. You want to make sure to test every important feature so you’ve left no holes in coverage. The testers need to know how a feature works (or at least how it’s supposed to work). Knowing this, they can report issues without guesswork. The way to ensure all this is to write a complete test case, with individual steps and expected results.  This all helps so that when a QA tester says “there is a bug in X system”, they can efficiently communicate why. They have run the same steps as others and they know how the feature is expected to work. If they’re seeing something different, they can be confident they’ve found a bug.

Depending on your current focus, you can write many test cases for the same features. For example, you want to know that your game does the correct thing AND doesn’t do the incorrect thing. You want to know that your heal spell gives 50hp to the target. You also want to know that the heal spell doesn’t give an extra 50hp if the target is already at max health. There can be a lot of creativity in coming up with design ideas for writing your test cases. Testing can never be exhaustive so it’s impossible to cover everything. While it is good to have a lot of tests, past a certain point you’re unlikely to be able to use all of them, all the time. It’s a good idea to keep your test writing efforts focused rather than writing as many tests as possible. Quality over quantity. To do this, you need to ensure that you have a wide coverage across all areas and features of the game. You should also ensure that you have enough depth to the tests you have as well.

But what should actually go into a test case? I’d like to go into more depth, but the elements are far too many to include in this article! Take a look at the following post outlining more important tips on how to write great test cases! QA 101: How to write awesome Test Cases

Test Suites

A test suite is a collection of test cases. As you’re writing more test cases, they can quickly get out of hand! So it’s important to collect them into groups to help organize them. There are many different ways to do this, but the most common is to group tests that focus on the same area. All your weapons tests. All your character animation tests. All your VFX tests. This makes it easier to construct a testing pass that focuses on those particular areas. It also makes it easier to find a particular test that you’re looking for. 

Which tests do you run when you’ve been given a new build of the game that revamps the way that characters move? You’re gonna want to run your character animation suite. This also makes it easier when reporting. Which makes more sense; saying that you have 2 failing tests out of the total 1000 or saying that 2 tests in the animation suite failed? The latter immediately communicates the information more concisely. It’s easier to see where the problem is likely to be, and who to send the bug to.

It’s also not unusual to have test suites created for different types of testing. For thorough testing, your tests will likely touch on specific areas and functions. Later in development, your testing will be more of an overview so you’d want to run higher-level tests. For example, checking each specific animation performs as intended vs a quick check that a character has animations at all. This is an example of the difference between functional and smoke testing. There are a variety of other types of testing that could be defined this way, such as build verification testing, regression testing and so on.

Want to learn more about creating Test Suites? We got you covered: QA101: How to create a Test Suite

Test cases and test suites are fundamental to a lot of the day to day work of a game tester. Because of this, it’s important to have a fuller understanding and appreciation of each. It’s useful to know the essential characteristics when you’re designing testing. This helps you to be more mindful of their functionality. A well-constructed set of test suites can make or break how successful you can be at creating effective test passes.

The purpose of this article is to give you an outline of what test cases and test suites are. In our next pieces, we’ll go into much more depth about the process of collecting your test suites, plus all the things you need to think of when writing test cases!

Other posts in the QA101 series: