Indie Game Release QA Checklist: What to Test Before Shipping a Build

A game can feel “almost finished” for weeks while still being unsafe to ship.

The dangerous part is not always a spectacular crash. More often it is a group of smaller release problems that were never tested together: an old save stops loading, a controller prompt is wrong on one screen, a translated string breaks the menu, performance drops in the busiest scene, or a fixed bug quietly returns in the next build.

For a solo developer or small team, release QA does not need to become a giant enterprise process. It does need to answer one question clearly:

What evidence do we have that this build is ready to become the public build?

This checklist organizes that answer into practical release gates.

1. Freeze the build you are actually testing

QA becomes unreliable when the target changes underneath the test.

Before a serious release pass, record:

• build number or version;
• build date;
• target platform;
• branch or source-control reference if you use one;
• major known issues;
• features intentionally excluded from the release;
• tester or owner of the pass.

The goal is simple: when someone says “it worked in the tested build,” you should know exactly which build they mean.

A late code or content change may be necessary, but it should create a new test target. Otherwise you can accidentally approve a build that no longer exists.

2. Separate blockers from ordinary bugs

A list of 70 open issues is less useful than a clear answer about which five can stop the release.

Use a small severity system. For example:

• Blocker — prevents launch or makes a core path unusable;
• High — seriously damages gameplay, progression, data or a major platform path;
• Medium — visible problem with a workaround or limited scope;
• Low — polish, cosmetic inconsistency or minor inconvenience.

Then add a release decision for each unresolved issue:

• must fix before release;
• accepted known issue;
• defer to patch;
• cannot reproduce / needs more evidence.

This prevents the bug list from becoming a pile where a menu typo and a save corruption defect look equally urgent.

3. Test the complete player path, not isolated features

Individual systems can work correctly while the game still fails as a product.

Run at least one end-to-end path through the build:

1. install or launch from a clean state;
2. reach the main menu;
3. start a new game;
4. complete the first meaningful gameplay loop;
5. save or trigger persistence;
6. quit normally;
7. relaunch;
8. load or continue;
9. reach another major gameplay state;
10. return to menu or exit cleanly.

For a larger game, repeat this around major progression gates, chapter transitions, bosses, world changes or other points where state becomes more complex.

End-to-end testing catches integration failures that isolated feature checks miss.

4. Treat save/load as release-critical

A broken optional animation is annoying. A broken save can erase hours of a player's time.

At minimum, test:

• first save on a new profile;
• manual save if supported;
• autosave if supported;
• checkpoint restoration;
• multiple save slots if supported;
• save after major progression changes;
• save after inventory or equipment changes;
• quit immediately after saving;
• load after a normal restart;
• load after an update from an older supported build when relevant;
• behavior when save data is missing or invalid;
• settings persistence separately from game-state persistence.

Do not assume that one successful “Save → Load” test proves the persistence system.

Different game states can serialize different data, and migration problems often appear only after the project changes between builds.

5. Re-test fixed bugs for regression

“Fixed” should mean more than “the original symptom disappeared once.”

For every release-critical fix, record:

• the bug ID or short name;
• the build where it was reported;
• the build where it was fixed;
• exact reproduction steps;
• expected result;
• retest result;
• whether related systems were checked.

If a fix touched inventory, for example, do not only repeat the exact inventory bug. Check the nearby behavior that could have been affected by the change.

A release pass should include a regression list made from recently fixed high-severity issues.

6. Measure performance in repeatable scenes

“Runs fine on my PC” is not a benchmark.

Pick a small set of repeatable test scenes or situations, such as:

• main menu;
• normal gameplay area;
• busiest environment;
• combat with several enemies;
• heavy effects sequence;
• inventory or UI-heavy state;
• load into a large scene.

For each benchmark, record useful values such as:

• average FPS;
• low FPS or worst observed drop;
• frame time;
• memory usage;
• load time;
• hardware profile;
• graphics preset;
• build number.

The most useful question is often not “is 60 FPS perfect?” but did this build become materially worse than the previous known-good build?

Consistent measurements make that regression visible.

7. Test controllers and input as a system

Input bugs frequently survive until late because keyboard and mouse receive most development attention.

If controllers are supported, check:

• every required gameplay action;
• menu navigation;
• pause menu;
• remapping if supported;
• conflicting bindings;
• reconnect after disconnect;
• correct device prompts;
• switching between controller and keyboard/mouse;
• dead zones and analog movement where relevant;
• confirmation/cancel consistency;
• focus behavior after opening and closing menus.

Also test input at awkward moments: reconnect during gameplay, pause with a controller, switch devices while a menu is open, or change a binding and restart the game.

8. Audit every important UI state

A UI screen is not just its default screenshot.

Each important screen can have multiple states:

• normal;
• empty;
• full;
• disabled;
• loading;
• error;
• selected/focused;
• controller navigation;
• long-text or translated-text state.

Create a screen inventory and check the states that actually matter for your game.

Typical release failures include:

• buttons that cannot be reached with a controller;
• text clipped at another resolution;
• empty lists that look broken;
• incorrect back-navigation;
• focus lost after closing a modal;
• tooltip or prompt showing stale information.

9. Test localization beyond “the file imported”

If the game ships in multiple languages, translation completion is not the same as localization QA.

Check:

• missing strings;
• untranslated fallback text;
• text overflow;
• line wrapping;
• dynamic placeholders;
• plural or variable text where relevant;
• font coverage;
• punctuation and spacing;
• button labels that no longer fit;
• subtitles and captions;
• language switching and persistence.

The highest-value localization pass is usually in the actual game UI, not only in the source spreadsheet.

10. Run a focused accessibility pass

Accessibility QA does not require pretending that every game can support every possible need. It does require checking the features and presentation choices you actually ship.

Review areas such as:

• text readability;
• subtitle/caption availability and readability;
• important information conveyed only by color;
• remappable controls where supported;
• hold versus toggle interactions;
• camera shake or motion options where relevant;
• flashing or visually intense sequences;
• audio-dependent gameplay information;
• difficulty or assistance options you advertise;
• focus and navigation consistency.

Most importantly, verify that any accessibility feature mentioned on a store page or feature list actually works in the release build.

11. Use playtests to find confusion, not only bugs

A tester can complete the game without encountering a technical bug and still reveal a release problem.

Record feedback in three separate layers:

• Observation — what actually happened;
• Interpretation — what the tester thought it meant;
• Action — fix, investigate, accept or defer.

Examples:

• Observation: three testers walked past the required crafting station.
• Interpretation: the station may not read as interactive.
• Action: improve interaction cue and retest.

This keeps raw feedback from turning directly into random design changes.

Before release, prioritize repeated confusion around onboarding, controls, objectives, progression and failure states.

12. Check install, update and first-run behavior

Developers often test from a machine that has run hundreds of development builds.

A player does not.

Where possible, test from a clean or realistically clean state:

• first launch;
• default settings;
• required folders/files created correctly;
• first-run prompts;
• update from a previous public build when relevant;
• uninstall/reinstall expectations;
• save/config behavior after reinstall if supported;
• missing optional data handling.

A clean-state test catches assumptions hidden by months of local development files.

13. Verify store promises against the actual build

Before release, compare the public product description with the build.

Check claims about:

• supported platforms;
• controller support;
• languages;
• multiplayer or online features;
• save features;
• accessibility options;
• game modes;
• system requirements;
• included content.

The goal is not marketing polish. It is avoiding a gap between what the store says and what the player receives.

14. Create one explicit final release gate

A project should have a moment where the team deliberately decides whether the build ships.

For a small team, the gate can be a single page with:

• candidate build number;
• blocker count;
• unresolved high-severity issue count;
• regression pass status;
• save/load pass status;
• performance pass status;
• controller/input pass status;
• localization pass status;
• accessibility review status;
• clean-start/end-to-end pass status;
• known issues accepted for release;
• final decision: GO / HOLD;
• owner and date.

This is more useful than a vague feeling that “everyone seems done.”

A HOLD is not failure. It is the release process doing its job before players discover the problem for you.

A lightweight order for a solo developer

If you are doing everything yourself, run the release pass in this order:

1. Blockers and known high-severity bugs.
2. Clean launch and end-to-end gameplay path.
3. Save/load and persistence.
4. Regression of recent critical fixes.
5. Performance benchmarks.
6. Controller/input.
7. UI and resolution checks.
8. Localization.
9. Accessibility.
10. Focused external playtest.
11. Store-claim verification.
12. Final GO/HOLD gate.

That order protects the most expensive failures first.

There is little value polishing one translated tooltip if the tested build still corrupts progression saves.

Use a free readiness check before the full QA pass

If you are still deciding whether the project is even close to launch, start with the free Game Launch Readiness Score. It checks store positioning, trailer, content, outreach, analytics and launch operations in a fast 100-point planning pass.

Once the project enters actual release QA, the broader Game Production Systems page separates bug tracking, playtests, save/load, performance, localization, accessibility, controller/input and other production disciplines.

For teams that need several of those release workflows together, the Indie Game QA & Release Operations Bundle is the one-time $39 bundle rather than buying multiple separate QA trackers one by one.

Final principle: release evidence beats release confidence

Confidence is useful during development, but it is a weak release criterion.

A safer release process produces small pieces of evidence:

• this build was identified;
• these blockers were closed or explicitly accepted;
• these save paths were tested;
• these performance scenes were measured;
• these critical fixes were retested;
• these controller and UI paths were checked;
• these localization and accessibility states were reviewed;
• this candidate received a deliberate GO decision.

That evidence does not guarantee a bug-free launch. Nothing practical does.

It does make the decision to ship much more defensible — and makes the inevitable post-launch fixes easier to understand because you know what was tested, in which build, and why it was approved.