Quick answer: The first-time user experience is the most critical area to test. This includes the game's first launch, any tutorials or onboarding, the first save point, and the first 30 minutes of gameplay.

A thorough QA testing checklist for indie game releases prevents issues from reaching players. You have spent months or years building your game. The code is done, the art is in, the levels are designed. Now comes the part that separates a smooth launch from a disaster: making sure it actually works. This checklist is not theoretical — it is built from the bugs that have sunk real indie game launches, organized into testing areas you can work through systematically in the weeks before release.

First-Time User Experience

The FTUE is the single most important testing area because it affects 100% of your players. A bug in the endgame affects only the fraction of players who reach it. A bug in the first five minutes affects everyone, and it happens before they have formed any attachment to your game.

# FTUE Testing Checklist
# Test on a clean install, not a development environment

[ ] Game launches from store page without errors
[ ] Initial loading screen appears within 5 seconds
[ ] Main menu is fully functional (new game, options, quit)
[ ] Options menu: resolution changes apply correctly
[ ] Options menu: audio sliders work and persist
[ ] Options menu: control rebinding works
[ ] New game starts without crash
[ ] Tutorial text is readable and accurate
[ ] All tutorial prompts match current control bindings
[ ] First save point works correctly
[ ] Player cannot get stuck or soft-locked in tutorial
[ ] Quitting during tutorial and resuming works
[ ] Skipping tutorial (if supported) works without issues

Test the FTUE on a completely clean install. Not your development machine with a warm cache and pre-compiled shaders. Install the game from the store page or distribution package on a fresh machine and experience it exactly as a player will. You will be surprised how different the experience is.

Save and Load System

Save system bugs are among the most damaging issues a game can ship with. A visual glitch is annoying. A lost save file after 20 hours of play generates genuine anger and a strongly-worded review. Test saves exhaustively.

# Save/Load Testing Checklist

[ ] Save and load at the start of each chapter/level
[ ] Save during combat, reload, verify state
[ ] Save during dialogue, reload, verify state
[ ] Save with full inventory, reload, verify items
[ ] Save with empty inventory, reload, verify
[ ] Save at zone transition boundaries
[ ] Quick save and quick load work
[ ] Auto-save triggers at expected points
[ ] Multiple save slots work independently
[ ] Overwriting a save slot works
[ ] Deleting a save slot works
[ ] Loading a save from a previous game version works
[ ] Corrupted save file is handled gracefully (no crash)
[ ] Missing save file is handled gracefully
[ ] Disk full during save is handled gracefully
[ ] Alt-F4 during save does not corrupt the file
[ ] Save files are in the correct OS-specific location

Pay special attention to save compatibility across versions. If you plan to patch the game after launch (you will), your new version must load save files created by the launch version. Test this explicitly by creating saves with the current build, making your intended day-one patch changes, and loading those saves in the patched version.

Performance and Stability

Performance bugs are tricky because they rarely crash the game. Instead, they degrade the experience in ways that accumulate into negative reviews: frame rate drops in busy areas, stuttering during streaming, memory leaks that slow the game after an hour of play.

# Performance Testing Checklist

[ ] Consistent 30+ FPS on minimum spec hardware
[ ] No frame rate drops below 20 FPS at any point
[ ] Loading screens complete within 30 seconds on HDD
[ ] No stuttering during normal gameplay
[ ] Shader compilation does not cause visible hitches
[ ] Memory usage stays stable over a 2-hour session
[ ] No VRAM overflow on minimum spec GPU
[ ] Game runs for 4+ hours without crash on all platforms
[ ] CPU usage does not spike to 100% during normal play
[ ] Alt-tabbing and returning works without issues
[ ] Minimizing and restoring does not break rendering
[ ] Resolution changes take effect without restart
[ ] Fullscreen, windowed, and borderless modes all work

The 4-hour stability test is essential. Many memory leaks and resource exhaustion bugs only manifest after extended play. Let the game run for four hours on minimum spec hardware while periodically interacting with it. Monitor memory usage — if it is climbing steadily, you have a leak that will eventually crash the game.

Input and Controls

Input bugs are disproportionately frustrating because the player encounters them constantly. A misbound key, an unresponsive button, or a controller that is not recognized can make an otherwise good game feel broken.

# Input Testing Checklist

[ ] All keyboard bindings work as documented
[ ] All controller bindings work (Xbox, PlayStation, generic)
[ ] Controller hot-plug works (connect/disconnect during play)
[ ] UI prompts update when switching input method
[ ] Rebinding all keys works and persists across restarts
[ ] No key can be bound to two actions simultaneously
[ ] Mouse sensitivity setting works and persists
[ ] Controller dead zones are appropriate
[ ] All menus are navigable by keyboard only
[ ] All menus are navigable by controller only
[ ] Pause menu works during all gameplay states

Audio

Audio bugs are easy to miss during development because developers often play with audio off or at low volume while they code. But players notice missing sounds, volume inconsistencies, and audio glitches immediately.

# Audio Testing Checklist

[ ] Music plays in all areas that should have music
[ ] Music transitions between areas are smooth
[ ] Sound effects play for all player actions
[ ] Volume sliders (master, music, SFX) work correctly
[ ] Muting audio works and persists
[ ] No audio crackling or popping during play
[ ] Audio does not continue playing after game is minimized
[ ] Headphone/speaker switching during play works
[ ] No audio plays before the player adjusts volume settings

Platform-Specific Requirements

Each platform has its own set of requirements that go beyond gameplay. Store integration, achievements, cloud saves, and platform-specific UI conventions all need verification.

# Steam-Specific Checklist

[ ] Steam overlay works (Shift+Tab)
[ ] Achievements trigger correctly
[ ] Steam Cloud saves sync between machines
[ ] Rich Presence shows correct game state
[ ] Steam Deck: all gameplay is playable with controller
[ ] Steam Deck: UI text is readable on small screen
[ ] Trading cards and badges are configured (if applicable)
[ ] Store page screenshots match current build

Accessibility Basics

Accessibility is not optional. Beyond being the right thing to do, accessibility failures generate negative feedback and can block platform certification on consoles. Test these basics even if your game does not have dedicated accessibility features.

# Accessibility Testing Checklist

[ ] All text is readable at minimum supported resolution
[ ] UI elements have sufficient color contrast
[ ] Important information is not conveyed by color alone
[ ] Subtitles are available for all spoken dialogue
[ ] Subtitle font size is adjustable
[ ] Control remapping is available for all actions
[ ] Game is playable with one hand (remapped controls)
[ ] Screen shake/flash effects can be reduced or disabled
[ ] Photosensitivity-triggering effects are minimized

Using This Checklist Effectively

Do not try to run through this entire checklist in a single marathon session. Break it into testing areas and assign each area to a specific day during your pre-launch code freeze. One day for FTUE testing, one day for saves, one day for performance, and so on. This keeps sessions focused and prevents fatigue from causing missed issues.

Track your results in your bug tracker, not just on the checklist. When an item fails, create a bug with the specific failure details. When all items pass, you have objective evidence that the game is ready to ship — not just a feeling, but documented test results.

“A checklist does not make testing unnecessary. It makes testing systematic. The difference between a buggy launch and a clean one is usually not talent — it is thoroughness.”

Related Issues

For a deeper dive into building your own QA checklist tailored to your game, see how to build a QA checklist for game release. To understand how to reduce your crash rate specifically, read how to reduce your game’s crash rate before launch. And for platform-specific testing strategies, check out how to test your game on multiple platforms.

Print this checklist. Pin it to your wall. Check every item before you hit Publish. Future you will be grateful.