How to decide on the best tools for testing game features
As developers, we need to ensure our features are working as intended. To do so, we require tools to test the integrity & stability of those features. The question is: which tools are the best fit to replicate intended behaviours?
With the end goal being such that you want the tester to be able to check out your feature in the shortest time possible whilst attaining results closest to what an actual user would do, these are some questions you should keep in mind when deciding what tools you need for the job!
- What could the player possibly do pertaining to this feature?
- What tools do I create to aid the tester in mimicking the closest possible intended behaviour of a user?
- Is the feature time consuming?
- Do we need a server or client tool?
Let’s look at two examples while keeping these questions in mind: Butter Royale’s Loyalty Gift Card, and Quests.
Loyalty Gift Card
The Loyalty Gift Card is a feature that gifts the player a reward upon log in over a period of 7 days. Based on the earlier sentence and image, we can deduce that:
- Testing this will be time-consuming as the rewards are given over a period of 7 days.
- Rewards have to be credited into the account that’s being played.
- The reward will have to reset once the day “resets”.
After breaking down the feature, we can ask ourselves more questions like:
- Can we speed up the time? How do we do that?
- How do we specifically claim a Day (x) reward to check if the data is accurate?
- How do we check for the daily reset?
Those simple questions immediately call to mind multiple solutions.
- We could speed up the time by having the reset timer in a test build to trigger every 30 minutes, give ourselves the ability to change server time, or even force a reset immediately to be able to claim it.
- We could also have a tool that sets the day to the specific reward we need to claim.
Quests
In Butter Royale, the Quest is a feature that gives players different rewards after completing its requirements. Similar to what we did in the above example, we’ll break down the feature:
- Rewards have to be credited into the account that’s being played.
- Testers have to be able to complete the quests, including hard ones that are either time-consuming or tedious.
- The quests will refresh after the day/week resets.
- Testers will have to be able to unlock and complete the bonus quest.
Probing further can lead to more questions such as:
- How do we allow testers to complete the quests? By how much?
- How do we test the quest refresh?
- How do we test specific quests that could have had their data and rewards modified?
Just like the above, there are many solutions, with some here for thought:
- We could have tools that allow testers to automatically complete all the quests that are currently available. We can even incorporate an open amount that allows them to set how much they would like completed, and perhaps for a specific quest that is currently available.
- We could either test the quest refresh naturally or have an option to forcefully refresh the quests.
- We could requests for designers to give each quest an ID, so that testers can choose and set what kind of quests they would like to test.
Here are a few additional things to keep in mind when you create tools for your testers and designers:
- Don’t be afraid to pick your team’s brains! Getting functions like Design and QA to state their objectives and needs to achieve the best possible results will help you better understand what tools they need.
- Keep refining your tools based on the requests of your testers as they are the ones using them the most.
- As much as we would like to keep the testing as “natural” as possible, there may be limitations based on your current project infrastructure (resources, manpower, time).
I hope this article has been helpful at breaking down the thought process of creating tools! If you enjoyed this article, drop me some claps, and follow us on our Medium publication!
