Plenty of studios stop merging code at some point in December. People take leave, release managers want a quiet branch, and whatever ships over the holidays is the build that was locked weeks earlier. The freeze itself makes sense. The risk is what goes into it: a build the developers know well and that nobody outside the team has actually played. This guide is for the producer or QA lead who wants one outside pass on that build while there is still time to act on what it finds.
Why an outside pass matters right before a freeze
People who built a feature tend to test it the way they built it. They know which menu to open first, which save slot is safe and which device the build was tuned on. A tester who arrives cold behaves more like a player: skips the tutorial, sends the app to the background halfway through a download, signs in on a second device, or buys something on a weak connection. Those sessions can expose problems that otherwise reach support in January. Finding them before the lock leaves time to assess and fix them. After the lock, a serious finding may force the team to choose between an exception to the freeze and a known risk.
What to send with the build
A short handover lets testers spend day one testing rather than asking questions. Four items cover most of it.
- The build itself: the candidate you plan to freeze, or the closest version you have, with install steps and the way it reaches testers, such as a TestFlight invite, a Play testing track, a Steam branch or a web staging link. Add test accounts and server access if the game needs a live backend to get past the title screen.
- Target devices: the hardware and OS versions you will support over the holidays, with the ones most of your players use listed first. Include the weakest device you still support to check how the build behaves with tighter memory and performance limits.
- What changed: a plain list of what is new or reworked since the last build anyone outside the team tested. Release notes work, and so does a rough list typed up by the producer.
- What you already know about: open bugs you have decided to ship with, so testers can confirm them quickly and spend their time on things you have not seen.
The flows to protect first
A freeze pass is not the moment to test everything evenly. Put most of the hours on the paths where a failure stops a player cold or costs them something.
- First launch: a clean install on each target device, with no leftover data, all the way to the first playable moment. Check permission prompts, extra content downloads and what happens if the player quits partway through.
- Save and load: saves made in the current live version should still open in the frozen build. Test cloud sync between two devices, and a save that gets interrupted by a closed app or a dropped connection.
- Purchases: every store item on each storefront in scope, using sandbox or test purchases. Check entitlement delivery, restoration of eligible purchases after a reinstall, and what the player sees when a payment fails.
- Multiplayer joins: invites, matchmaking and rejoining after a disconnect, across platforms if you support crossplay, and on both good and poor networks.
If the holiday build carries seasonal content or a timed event, test just before, at and after its start and end using the game's authoritative clock or a controlled schedule in a test environment. Check the relevant time zones and what happens when the device clock is wrong. Moving the device clock alone is not enough for an event controlled by the server.
Timing it so fixes still land
Work backwards from the day the branch locks.
- Lock date: the last day a fix can be merged. Every other date hangs off this one.
- Fix and verify window: leave enough working days before the lock for your developers to fix the important findings and for testers to confirm each fix in a fresh build. A pass that ends the day before the freeze only tells you what you are shipping with.
- The outside pass: schedule it to finish before that window opens, which usually puts it well clear of the final week.
- A short recheck on the frozen build: once the branch is locked, verify that the intended fixes are present and smoke-test the critical flows on that exact build. Record what was checked and what remains outside the pass.
Holiday leave affects both sides, so agree two things up front. First, who on your team triages incoming bugs each day of the pass. Second, which bugs still earn a fix this close to the lock. A simple rule keeps the last days before the freeze predictable, for example fixing only crashes, progression blockers, save loss and payment faults.
What a useful report looks like
At this stage you need decisions more than a long list. Ask for findings grouped by severity, each with the device, build number and steps to reproduce, plus a short note on what was covered and what was not. That note matters as much as the bugs, because it shows which risks you are knowingly taking into the holidays. If any of those risks involve a live game with players on more than one version, our guide to mixed-version QA for game updates covers that side of it.
Planning a December lock?
GameCloud's game QA work began in FY 2010-11. Today, our team tests studio builds for PC, iOS, Android, TV, Web, XR and other emerging platforms. To plan the pass, email your December lock date, the devices you support and a short list of what changed to Sales@GameCloud-Ltd.com, and we will plan the outside pass around that date.