How to Build a QA Checklist for Game Release

Learning how to build QA checklist for game release is a common challenge for game developers. You have built your game, fixed the bugs you know about, and you think it is ready to ship. But thinking and knowing are different things. A QA checklist turns "I think it works" into "I have verified it works." This guide walks through building a release checklist that covers the areas most indie developers miss, from platform certification to first-time user experience.

Why Checklists Work

Checklists are not glamorous. They are not a replacement for deep exploratory testing. But they are remarkably effective at catching the class of bugs that slip through because nobody thought to check. The surgeon Atul Gawande popularized checklists in medicine, and the same principles apply to game development: when the stakes are high and the process is complex, a simple list prevents simple mistakes.

The checklist does not need to cover every possible bug. It needs to cover the categories of bugs that are most damaging on launch day: crashes, data loss, platform certification failures, and terrible first impressions.

Category 1: Platform Certification

Each storefront has technical requirements that can cause your submission to be rejected or your game to be delisted. Check these first because a certification failure delays your launch entirely.

Steam: verify that the game launches from a clean install without requiring additional downloads. Verify that Steam overlay works. Verify that achievements, if applicable, trigger correctly. Verify that the game respects the Steam Deck’s input recommendations if you are targeting Deck Verified status. Test that the game exits cleanly without leaving orphan processes.

Mobile (iOS/Android): verify that the app does not crash on launch for the minimum supported OS version. Verify that in-app purchases complete correctly in sandbox mode. Verify that the app handles interruptions gracefully: phone calls, notifications, backgrounding, and returning from sleep. Verify that the app respects the device’s accessibility settings.

Console: each console manufacturer has a detailed certification checklist (TCR/TRC/lotcheck). These documents are under NDA, but the common themes are: the game must never hard-crash, it must handle controller disconnection gracefully, it must save data to the correct storage location, and it must display required legal notices.

Category 2: Regression Testing

Regression testing verifies that bugs you have already fixed have not returned. This is especially important after feature freezes, when last-minute changes can re-introduce old problems. Maintain a list of every critical bug you have fixed during development and verify each one before release.

# regression_tests.txt — verify before every release
# Format: [BUG-ID] Description — How to verify

[BUG-042] Player falls through floor in level 3
  Verify: Walk across the bridge in level 3 ten times

[BUG-087] Save file corruption when saving during cutscene
  Verify: Save during each of the 5 cutscenes, reload each

[BUG-103] Inventory duplication via rapid clicking
  Verify: Rapidly click transfer button 50 times, check count

[BUG-156] Audio stops after alt-tabbing on Windows
  Verify: Alt-tab during gameplay, return, confirm audio plays

[BUG-201] Boss HP bar shows wrong value after retry
  Verify: Die to boss, retry, confirm HP bar shows full

If your regression list grows beyond what you can test manually in a reasonable time, prioritize by bug severity. Always retest crashes and data loss bugs. Visual glitches can be spot-checked.

Category 3: Performance Benchmarks

Define your performance targets before testing so you have clear pass/fail criteria. Vague goals like "runs smoothly" lead to vague results.

Frame rate: define your target FPS for minimum spec hardware. For a 2D pixel art game, 60 FPS on integrated graphics is a reasonable target. For a 3D game, 30 FPS on your minimum spec GPU with medium settings. Test in the most demanding scene in your game, not the main menu.

Load times: measure how long it takes to go from launching the game to gameplay. Measure scene transition times. On an HDD (not SSD), load times can be three to five times longer. If your players are on Steam Deck, test with the Deck’s internal storage.

Memory usage: play for 30 minutes and monitor memory consumption. If it grows continuously, you have a memory leak. Check after scene transitions, as leaked assets from unloaded scenes are the most common source of memory growth in games.

Category 4: Save and Load Verification

Save system bugs are among the most damaging because they destroy player progress. Test these scenarios:

Save at the beginning, middle, and end of the game. Load each save and verify that the game state matches. Save during high-activity moments: combat, transitions, cutscenes. Verify that save files from previous versions of your game (if applicable) load correctly in the current version. Test what happens when the save file is corrupted or missing. Test what happens when the disk is full.

# Automated save/load verification script (pseudocode)
func verify_save_integrity() -> void:
    var test_data := {
        "player_level": 15,
        "gold": 2500,
        "inventory_count": 23,
        "current_scene": "dungeon_3",
        "play_time_seconds": 7200
    }

    # Save the game state
    SaveManager.save_game(test_data, "test_slot")

    # Load it back
    var loaded := SaveManager.load_game("test_slot")

    # Verify every field matches
    for key in test_data:
        assert(loaded[key] == test_data[key],
            "Save mismatch: %s expected %s got %s" % [key, test_data[key], loaded[key]])

Category 5: Localization Check

If your game supports multiple languages, every localized string needs verification. The most common issues are text overflow (German and French strings are typically 30% longer than English), missing translations that fall back to English or display keys like UI_MENU_START, character encoding issues with non-Latin scripts, and right-to-left layout problems for Arabic and Hebrew.

At minimum, run through your entire game in each supported language and verify that all text fits within its UI containers, no untranslated strings appear, and special characters display correctly.

Category 6: Accessibility Audit

Accessibility is not optional. It expands your audience, improves the experience for all players, and in some cases is required for platform certification. Check these basics:

Controls: all controls can be remapped. The game is playable with keyboard only, mouse only, and controller only (as applicable). Button prompts update to match the active input device.

Visual: colorblind modes are available or critical information is never conveyed by color alone. Text meets minimum size requirements (generally 24px at 1080p for body text). UI contrast ratios meet WCAG AA standards.

Audio: subtitles are available for all dialogue and important sound effects. Separate volume sliders exist for music, sound effects, and voice. The game is playable without audio (no audio-only cues for critical gameplay information).

Category 7: First-Time User Experience

The most overlooked category. You have played your game thousands of times. You know exactly how every system works. A new player does not. Test the first 15 minutes of your game with fresh eyes. Better yet, watch someone who has never seen your game play through the opening.

Verify that default settings are reasonable: resolution matches the display, volume is not too loud, controls are intuitive. Verify that the tutorial explains every mechanic the player needs in the first level. Verify that the difficulty curve does not assume familiarity with your game’s unique systems. Verify that the game does not dump a wall of text on the player before they have a reason to care.

"A checklist will not catch every bug. But it will catch the bugs that would have been embarrassing to miss. And in game development, the embarrassing bugs are the ones that end up in YouTube compilations."

Related Issues

For setting up automated crash reporting that catches issues your checklist misses in production, see our guide on adding crash reporting in 10 minutes. For a framework on deciding which bugs to fix before launch and which to ship with, our article on prioritizing bugs after early access launch covers triage in depth. For solo developers building their QA process from scratch, see the best bug tracking tools for solo developers.

Run the checklist when you are most confident the game is ready. That is when it catches the most surprises.