This article explores a few common problems that can delay the internal QA process.
This article was originally posted on Kongregate's Developer Blog.
Before your game can be released into the wild, first it needs to survive the rigors of the internal QA process. Ideally this process will go smoothly, but there are a few common problems that can delay testing, which this article will explain. These are things that we believe should be considered early in development. They may seem minor, but they can stall out a release in a big way, especially if you’re developing in a different time zone from your publisher.
For some context, let’s start with a common release cadence: Alpha > Beta > Release Candidate > Release. Publishing QA receives builds at the Release Candidate stage. As much as we enjoy contributing earlier in the development process, this article is focused on the end of the release process. This assumes common blockers and crashes have already been found and fixed in the Alpha and Beta stages.
The first thing your users will see, obviously. Here’s the thing, they’ll only see it once -- QA will go through this experience at least 4 times a build. Even if you don’t change any code or do anything to that portion of the game, it should be tested. It’s too important not to.
Please ensure this is easy to access. A common problem we’ve run into is cloud save data being linked to Device UDIDs and no tools to reset them. No matter how many times we reinstall or clear the data, launching the game always loads into our save data that has already completed the FTUE, and has already purchased non-consumable IAP.
If you’re going to go this route, make sure there is an easy way for testers to reset their account or unlink their data.
Related to the point above, consider how you implement your cloud-saving feature. QA will often keep high-level end-game accounts around for testing. Our process is to verify the new-user experience, IAPs, and then switch to our accounts with everything already unlocked and verify all other features. We do this on multiple devices, and a different set of devices every time. The easier it is for QA to reach the content, the quicker and more thorough the smoke test will be.
You’ll want to test full progression at some point, but not every single release. Most apps will gate content behind certain levels and playtime, so it’s not feasible to unlock that content naturally in a normal test cycle. Don’t wait until the Release Candidate to test this!
Don’t forget to integrate the platform-specific game portals. This will require setting up Achievement and Leaderboard IDs, similar to how IAPs work. This will need to be set up in the game code as well as the developer consoles for iOS and Android.
Google has a set of special quality guidelines. The two most common guidelines that seem to have issues are the Android back button and permissions requests (Android 6+).
To maintain a consistent user experience, the Android Back button must:
Have the same functionality as any on-screen back or close button
Pause and unpause gameplay (if a pause function exists)
Dismiss all dialog windows
Navigate to the previous location in the menu stack or home screen in game (if applicable)
Exit the app when pressed at the main menu or home screen (or trigger a "do you wish to exit?" confirmation window)
As of Android 6+, users are allowed to directly manage app permissions at run time. Because of this, it’s important to handle permissions properly in case a user has denied access to some or all of the required permissions. Be sure to follow the guidelines below when implementing a permission request flow:
Avoid requesting permissions at launch unless they are critical to the app running.
If any permissions must be requested at launch, be sure to provide context to the user as to why they are being asked to allow it.
When possible, trigger the requests at the time of the associated action.
In the event of a user denying a permission request, avoid immediately directing the user to the app settings. Instead, educate the user as to why the app needs the permission to run and provide a way to re-trigger the request in the app. Reserve sending a user to the app settings until the app has detected that the "Always deny" option has been selected. More info on Android Quality Guidelines can be found here.
Hopefully these few points will help streamline your development and release cadence.
Read more about:
BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
