QA Test Script Quickstart Guide
With about two years of game QA experience under my belt, I’d like to share what I’ve learnt on the job with regards to writing QA test scripts for functionally testing games!
First things first, games need testing to perform well, whether it’s a simple text adventure or Apple Arcade’s most popular battle royale game, Butter Royale. š As long as there are variables and moving parts, something is bound to go wrong and edge cases will rear their little heads. The aim of the QA test script is to ensure that the game functions as intended and does not compromise the player experience — or basically, to find bugs!
If you are a student or indie developer, chances are you may not have the funds to engage an external QA vendor to do rigorous testing on your project. In this article, I’ll be breaking down the test scripts I’ve been using for manually testing Butter Royale since the start of development. Whether you need to write an extensive test script to fully test your game, or just a quick checklist to run smoke tests, I hope this article checks all those boxes!
Here are some key things that I think make a test script solid and easy to work with:
Extensiveness: The test script covers all bases and edge cases.
Readability: The test script is easily understood by testers (internal or external).
Efficiency: The test script is able to be executed quickly and easily.
An Easy Test Script Template
To follow along, check out this template I’ve made here! Feel free to save a copy of it and modify it to suit your means.
The test script can be broken down into five columns:
- Number: A number assigned to the particular test case for easy reference, or used to denote the chronological steps for testing.
- Test (or Input): The exact actions to execute for the test case. For example, “Press down on the D-Pad while standing on top of the 4th pipe in World 1–1.” Try to be as detailed as possible in describing the test to prevent any miscommunication.
- Expected Result: Self-explanatory. For example, the expected result for the above test would be “The player enters the pipe and transitions to the Secret Area.” Again, do not skimp on detail.
- Test Result: “PASS” or “FAIL”. Anything that does not adhere exactly to the Expected Result should be considered a “FAIL”. You might also run into a situation where a certain feature cannot be tested (device limitations, different control schemes on different platforms), so having a “N/A” option in your data validation setup for this column would help too.
- Notes: This is where details of the failure would go in the case of a “FAIL”. This column can also be used to highlight any other problems to the developers that do not fail the test case.
Some sheets opt to have a column for ‘Observed Result’, but I have cut that from my test scripts in favour of the generic ‘Notes’ column, since there should be no need to detail the observed results of a test in the case of a ‘PASS’.
Testers would then go down the list, executing the tests as shown and indicating the result in the appropriate column. Easy!
Organising the Test Script
That’s basically it, if your game is linear and relatively short! However, for more complex games with a slew of menus, submenus and sub-submenus, the list will only get longer and hairier over the course of development.
The most straightforward method for making sure the list is organised is to group the test cases by feature. This also makes it easy to add test cases to specific features if more functionality is added later on. In the case of Butter Royale, I initially had all tests relating to buttons on the main menu grouped under “Main Menu”. As more and more buttons were added to the menu and had their functionality expanded, I eventually had to split the test cases by submenu: “Settings”, “Gallery” and so on.
After grouping test cases by feature, the next step would be to arrange these groups in some sort of chronological order that makes sense for testing. When looking at the sheet, the tester’s first instinct would be to complete the tasks from top to bottom, therefore it would make sense to place features that surface first at the top. This means things like splash screens, loading bars, any permission prompts and (most importantly) the First Time User Experience/Tutorial should be at the top of the list.
Lastly, if you’re maintaining this list during development, it is bound to grow and change. QA Testers are usually the last bastion of defence when it comes to finding bugs, so we should keep abreast of feature changes during development and edit the test script accordingly. While adding test cases for new features is a given, don’t forget to go back and remove test cases that are no longer relevant, or testers are going to be confused about whether something is a feature or a bug.
A final tip: as a tester, it’s easy to go on auto-pilot when testing, especially if you’ve gone through the list hundreds of times before. What’s important is to stay vigilant even when checking the most mundane things in the game, as you never know when a new update could cause regression in what you thought was a stable feature.
QA Test Script Quickstart Guide was originally published in Mighty Bear Games on Medium, where people are continuing the conversation by highlighting and responding to this story.
