A release candidate is a specific artifact with a specific configuration. Testing a nearby development build does not establish that the candidate has the same scenes, content, or behavior. Start by making the object of the release decision unambiguous.
Imagine a puzzle-game update that adds a new level pack and changes the save format. Its highest risks include discovering the new content, preserving old progress, and returning safely after an interrupted session. A useful checklist gives those changes more attention than an unchanged decorative menu animation.
/01
Identify the artifact and its configuration
Record the source revision, Editor version, package lock state, target platform, build profile, and artifact hash. Preserve the exported output that testers receive. Unity’s Build Profiles organize configuration for a target, so verify the selected profile and resulting settings rather than relying on the name of a build folder.
Confirm the intended entry scene, included content, service environment, and development instrumentation state. Keep secrets out of distributable configuration and review evidence. If a setting changes after the candidate was tested, identify the replacement as a new candidate and determine which checks need to run again.
/02
Map each change to a player-facing risk
Review the actual diff and content changes, then list the player journeys they can affect. Include indirect dependencies: a shared UI prefab may affect old levels, and a changed save schema may affect startup before the new pack is even opened. Give each risk a test route and an owner.
For the fictional update, prioritize an existing player reaching the new pack with previous progress intact. Also test a new player who has no save. Keep a short smoke route for unchanged essentials such as launching, making a move, finishing, failing, and restarting. The change map determines the deeper checks beyond that common route.
/03
Exercise upgrade and interruption paths
Use disposable historical fixtures to test the upgrade path from each supported save version. Verify that completed levels remain completed and that the new content appears under the intended rules. Reopen the migrated save after exiting the candidate. A successful first session alone cannot show that the new state was persisted correctly.
Exercise interruption at meaningful boundaries: leaving during a level transition, canceling an optional download, or returning after pause. Pick scenarios relevant to the actual platform and architecture. Record the expected recovery before running the test, and distinguish a safe, explained failure from a silent reset of player progress.
/04
Check the target experience and evidence
Run the candidate on representative supported devices and input methods. Inspect readability, controls, audio settings, loading, and the performance scenarios most affected by the update. Use the project’s agreed budgets and preserve capture conditions. Do not convert an unavailable device into a passing result because a similar machine worked.
Collect relevant player logs when a failure occurs; Unity documents where those logs are available on each target. Tie every report to the artifact, device, steps, and expected outcome. Remove unrelated personal information from shared evidence. A short reproducible report is more useful than an unexplained collection of screenshots from several different builds.
/05
Make the decision and recovery plan explicit
Summarize passed, failed, and unverified checks separately. For each remaining issue, state the player consequence, affected scope, owner, and reason for accepting or blocking it. A large number of successful minor checks should not dilute a known progress-loss failure. Keep the release decision attached to evidence from the actual candidate.
Retain the prior artifact and consider whether it can read saves written by the new version. If rollback has a data-compatibility limit, document the forward-repair option before release. After the candidate is distributed, verify the delivered version through the real installation or hosting path. The release record should remain useful when someone needs to diagnose or recover from a later problem.
Keep this in mind
Key takeaways
- Identify one immutable candidate and tie every test result to its actual build configuration.
- Use the change set to prioritize upgrade, interruption, and target-device coverage.
- Keep failed and unverified checks visible and plan recovery around save compatibility as well as code.
Sources & further reading
Consult the source documentation for the version and platform you are working with.