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: