At the heart of Quality Assurance lies the creation and execution of test cases—a systematic approach to identifying and resolving issues in games before they reach the players’ screens. In this blog post, we’ll delve into the intricacies of test cases for video game QA and shed light on their importance in delivering top-notch gaming experiences.
USE SPREADSHEETS!
Wether you prefer Microsoft Excel or Google Sheets doesn’t matter, both are excellent tools to write test cases and share with your team.
Are you the only tester in the team? It doesn’t matter, use spreadsheets!
Do you suck at using spreadsheets? Give no excuses, check my tutorial covering the basics.
How to write down tests cases?
At the same time that your test cases should provide detail, they should be simple and short, because there will be dozens (or hundreds) of them, and long texts will make the job sluggish.
The Essentials
Here’s a sample document, but in summary, your spreadsheet should include, at least, the following items:
- ID: put a numerical ID (such as #001, #002, etc) to make it easier to refer to the test case, so instead of telling the Engineering team to check “That bug at Main Menu”, you can say “Check test case #002”
- Name: a name is the shortest possible description, for example: “Pause button funcionality”
- Objective: write the purpose of this test case, for example: “Ensure the Pause button is pausing the game”
- Prerequisites: tell if the user needs to take any previous measure before trying to reproduce the test case, for example: “Start the game and finish level 1”
- Reproduction Steps (AKA Repro Steps): inform the steps the tester should follow to test for the case. I suggest numbering the steps to make communication easier in case someone doesn’t understand one of them.
- Expected Results: write what should ideally happen after the reproduction steps
- Current Results: are the results not as expected? Write down what’s going on, for example: “After finishing the first level, the game crashes”
- Responsible team: inform what team should this bug be reported to
Additional information
Depending on the scope of your project, it might be worth to add the following items to your spreadsheet:
- Links: if you team uses Jira, Favro or any similar plaform, you can link the test cases to the bug report in these platforms
- Suggestions: sometimes there isn’t even a bug, but theres something that could be improved, so you can write your suggestions in this tab
- Test Date: if you split the test cases into categories, you can inform the last time said category was tested
Some good Practices
- Split the sheet in categories such as “Gameplay”, “UI”, “Online Functionalities” and, if necessary, separate them by tabs and split each with subcategories, for example:
“User Interface is a very broad category that includes everything from menu buttons to HUD elements which provide information during gameplay. This category often deserves to be split into subcategories.”
- Take some time to improve the spreadsheet readability. You can highlight the more important columns with different colors and bold texts, as I show in my example
- Pair your Test Plan with platforms such as Jira, Favro and the like, thesy will help producers track progress, set priorities and meet deadlines
Conclusion
Working as a QA Analyst/Tester is not just about playing games and figuring out what’s wrong with them, it’s about delivering vital information through efficient and precise communication with development teams.
If players complain about issues within a game, the Quality Assurance team is the first to be blamed, with a reason. So never underestimate the importance of a QA analysts and never stop studying new ways to improve your work.