Most patch testing asks one question: does the new build work? Once the update is out, a second question matters just as much. For days or weeks, some players stay on the previous build while others move to the new one, and their saves, cloud files and matches cross between the two. This guide shows studios how to test that mixed-version period before an update ships.
Why old and new builds overlap
The overlap is normal, and the store tools that make a release safer also make it last longer.
- Google Play: a staged rollout sends an update to a percentage of users, and that percentage does not rise on its own. If you halt the rollout, players who already have the update stay on it.
- Apple App Store: a phased release spreads an update across 7 days for users with automatic updates turned on. Anyone can still download it manually during that time, and you can pause the release for up to 30 days in total.
- Steam: players can opt into beta branches, so a beta branch and the default branch can carry different builds at the same moment.
- Players themselves: some switch off automatic updates, some play offline, and many own the game on more than one device. Google offers in-app updates precisely because some users need a reminder to install an update.
So the useful question is not whether two builds will meet. It is where they meet, and what breaks when they do.
Map the places where builds meet
Before writing test cases, list every point where data or players cross between versions. For most games the list is short:
- Local saves written by the old build and opened by the new one.
- Cloud saves synced between two devices sitting on different versions.
- Multiplayer lobbies, matchmaking and sessions where clients may differ.
- Server-side data, such as inventories, currencies and event progress, that both clients read.
- Downloadable content or asset packs fetched after the main update lands.
Each meeting point becomes a row in the test plan, with the old version, the new version and the result you expect.
Test the upgrade path players actually take
A fresh install of the new build says little about returning players. Their saves carry history the new code has never seen.
- Keep a library of saves from the current live build and at least one older build, at early, middle and late progress.
- Include awkward states: mid-quest, mid-match, unspent currency, pending purchases and full inventories.
- Install the live build from the store, play, then update in place instead of reinstalling.
- Cover players who skipped a version and jump two builds at once.
- After the upgrade, play on until the game saves again, then reload that new save.
Check what happens when a newer save meets an older build
This is the case teams most often miss. A player updates on one device, carries on playing on a second device that has not updated, and cloud sync hands the older build a save it was never written to read.
- Confirm the older build either opens the save safely or declines it with a clear message.
- Make sure a declined save is left untouched, so nothing is lost once the player updates.
- Check the conflict prompt when two devices hold different progress, and that the choice it offers makes sense to a player.
- On Steam, Valve says Steam Cloud syncs files before and after every session, and players can turn sync off per game. Test closing the game on one machine and opening it on another, with sync on and off.
- If your rollback plan is to set an earlier build live again, test that earlier build against saves written by the newer one.
Version checks in multiplayer and live services
Decide the compatibility rule first, then test both sides of it.
- Agree whether old and new clients can play together, or whether the game asks for an update before joining.
- Try an old client joining a lobby hosted on the new build, and the reverse.
- Check the message players see on a version mismatch, and that it leads them straight to the update.
- If you force an update, for example with Google Play immediate updates, which require the player to update and restart, confirm progress is saved before the restart.
- Watch shared server data: an item granted on the new build should not crash the old client that tries to show it.
Treat the rollout window as part of the test
Mixed-version testing does not stop at submission. While a staged or phased release runs, both versions are live. Keep both builds installed on test devices, and keep a short set of cross-version checks ready to repeat when player reports come in. Keep supported older builds in the matrix after rollout completes. Retire them only when your support policy and active-version evidence justify it, and keep their saves in the library for future upgrade tests.
Where an external QA team helps
Mixed-version work needs devices and accounts held on specific builds, which is hard to keep aside on an internal bench while developers test the next change. An external team can hold old and new builds side by side, maintain the save library between updates, and run upgrade, downgrade and cross-version checks on the devices you name. Fixes and the go or no-go call stay with your studio.
Plan your next update with GameCloud
GameCloud is a 16-year-old company and an external game QA partner for PC, iOS, Android, TV, Web, XR and other emerging platforms. Send the build window, the platforms in scope, and the regression areas you want covered. We will return a one-page project total. Write Sales@GameCloud-Ltd.com.