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
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.
Pre-conditions
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:
| Step | Insructions | Expected Behaviour |
|---|---|---|
| 1 | Observe falling block with no gamepad inputs | The block should move downwards incrementally allowing the player to input button presses |
| 2 | Press Left button once on gamepad (short press) | The block should move one unit to the left |
| 3 | Press & hold Left button on gamepad (long press) | The block will continue to move unit by unit to the left side of the playing area |
| 4 | Press Right button once on gamepad (short press) | The block should move one unit to the right |
| 5 | Press & hold Right button on gamepad (long press) | The block will continue to move unit by unit to the right side of the playing area |
| 6 | Press 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 |
| 7 | Press & 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 |
| 8 | Press 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 |
| 9 | Press A button once on gamepad (short press) | The block should rotate clockwise 90° |
| 10 | Press & 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 |
| 11 | Press B button once on gamepad (short press) | The block should rotate anti-clockwise 90° |
| 12 | Press & 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.
Pingback: QA101: How to Design your Test Cases and Test Suites | QA Quest
Pingback: Writing Test Cases – Game Development Blog