Samantha Roberts
Most indie teams treat QA like a final checkbox. Build the thing, then hand it to a friend for a weekend, fix the obvious crashes, ship it. I did this on my second project and watched a game-breaking save corruption bug hit the Steam forums within six hours of launch. Reviews tanked before I even woke up on release day. That experience rewired how I think about testing permanently.
Here’s what actually surprises people when they look at QA seriously for the first time: the workflow matters more than the headcount. A solo tester with a structured process will find more critical bugs than five people playing around without one. That’s not motivational-poster stuff, that’s just true. Structure determines what gets found, documented, and actually fixed versus what gets clicked through once and forgotten.
What a Real QA Workflow Looks Like for a Small Team
| QA Phase | Purpose | Scope | Frequency |
|---|---|---|---|
| Smoke Testing | Catch broken builds | Launch, main menu, core loop stability | After every major build |
| Feature Testing | Validate new content | Targeted system (weapon, level, mechanic) | When new content lands |
| Regression Testing | Detect unintended side effects | Systems adjacent to changes | After bug fixes or code merges |
| Exploratory Testing | Find unanticipated bugs | Full game, creative testing | Before external playtests/launch |
The first thing to accept is that indie QA isn’t AAA QA with fewer people. It’s a genuinely different discipline. You don’t have a dedicated QA department running regression suites on 12 platforms simultaneously. What you have is maybe two or three people, some willing volunteers, and a finite amount of time before launch. The workflow has to be designed around that reality.
A functional indie QA workflow has four distinct phases, and skipping any of them costs you twice as much time later.
Smoke testing happens after every major build. This isn’t a deep test, it’s a 20-minute check: does the game launch, can you reach the main menu, does the core loop run without crashing? Its only job is to catch “the build is broken” situations before anyone else touches it. I use a literal four-question checklist in Notion for this. Boring? Yes. Saved us three wasted tester sessions? Also yes.
Feature testing happens when new content lands. A new weapon system, a new level, a new save mechanic goes through a targeted test pass before it touches the main branch. You’re checking that the thing you built does what it’s supposed to do, nothing else yet. This is where your issue tracker earns its keep. I’ve been using HackerOne’s Shortcut (formerly Clubhouse) for a while, but honestly for very small teams even a shared Trello board with a disciplined card format works fine if people actually use it.
Regression testing is the one most indie teams skip, and it’s the one that kills you. Every time you fix a bug or merge new code, something else can break. Regression testing means deliberately re-testing previously working systems after changes. You don’t need to test everything every time, just the systems adjacent to what changed. Keep a regression checklist. Update it as the game grows.
Exploratory testing is the human-intelligence pass. You give a tester time with no script, tell them to try to break the game, and let them go. Skilled explorers find the bugs your test cases don’t anticipate because they think sideways. This is also the most valuable thing external playtesters do, which is why you should be running playtests on itch.io closed betas or through Steam’s Playtest feature, not just asking friends.
Bug Documentation: The Part Everyone Underestimates
A bug report that says “the game crashed when I was near the forest” is nearly worthless. A bug report that says “reproducible crash when entering Birchwood Forest from the eastern entrance after picking up the Lantern item, 3/3 attempts on Windows 11, build 0.4.2” is a gift to your programmer.
The difference between those two reports is documentation discipline. Your QA workflow lives or dies on whether testers (paid, volunteer, or yourself) know how to write an actual report. I give every new tester a one-page guide. Five fields required: title, steps to reproduce, expected result, actual result, frequency and build number. If a report doesn’t have those five things, it goes back. That sounds harsh. It saves days.
For tracking, GitHub Issues works fine if you’re already in that environment. Jira is powerful but genuinely overkill for a team under five. I’ve seen small teams do well with Linear, which is cleaner and faster than Jira without being as bare-bones as Trello. Whatever you pick, use it consistently. The graveyard of bug trackers abandoned for spreadsheets is real.
Severity and Priority: They’re Not the Same Thing
How To Fail at Marketing Indie Games · Artindi on YouTube
This trips up a lot of first-time producers. Severity describes how bad the bug is technically. Priority describes how urgently it needs to be fixed relative to everything else on your plate.
A typo in a loading screen tip is low severity and probably low priority. A softlock in level two that only triggers if you skip the tutorial is medium-to-high severity (it blocks progress) but maybe medium priority because the trigger is rare. A crash on startup is critical severity and also critical priority. These can diverge in ways that matter: a bug that only affects 2% of users but causes data loss is high severity even if it’s low frequency.
Build your severity scale early. Four levels is enough: critical, major, minor, trivial. Anyone on your team should be able to classify a bug consistently without asking you. That consistency lets you triage fast during crunch without arguments.
External Testers and When to Bring Them In
The research here is genuinely mixed on optimal timing, but my practical experience is: external testers too early waste their novelty. The first time someone plays your game, they see it fresh. That’s a non-renewable resource. Don’t burn it on a build full of placeholder art and broken systems. Bring them in when the core loop is stable and representative of what you’re actually shipping.
Where to find external testers: the r/gamedev and r/indiegaming communities run beta request threads. TIGSource forums still have active members who will test. Your own Discord server, if you’ve been building an audience. And Steam’s Playtest feature is legitimately good now for gathering a larger pool of feedback in a structured way.
I’ll be honest: paid QA services for indie games exist and most of them are not worth it at the price points they charge. The exception is platform certification testing for console submissions. If you’re shipping on PlayStation or Xbox, hire someone who has done cert before. The certification requirements are specific, the failure modes are expensive, and “I’ll just figure it out” is a very bad plan there.
Build Your Test Plan Before You Need It
What surprised me most doing this properly the first time was how much the test plan itself revealed about the design. Writing down “how do we test that the save system handles an interrupted write correctly” forced us to figure out whether we had actually handled that case. We hadn’t.
A test plan doesn’t need to be 40 pages. It needs to cover: what are the critical paths through your game, what are the edge cases for each major system, and who is responsible for testing what before each milestone. One shared Google Doc, updated as features change. That’s it.
Recommended reading if you want to go deeper: “Game Testing: All In One” by Charles Schultz and Robert Denton Bryant is the most comprehensive book I know on the topic. It’s oriented toward professional QA but the fundamentals translate directly to indie workflows. For project tracking and documentation, Notion has become my default recommendation for small teams because it handles the test plan, bug triage, and build notes in one place without requiring an IT department to set it up.
FAQ
Sources
- cottonbro studio
- that says “the game crashed when I was near the forest” is nearly worthless
- that says “reproducible crash when entering Birchwood Forest from the eastern en
- doesn’t have those five things
- loss is high severity even if it’s low frequency
How many testers does an indie game actually need?
For a 5-10 hour single-player game, 8-12 external testers across your beta period is usually enough to surface the major issues, assuming they’re testing with structure. The number matters less than coverage: make sure different hardware configs, playstyles, and experience levels are represented.
When should I start QA on my indie game?
As soon as you have a playable vertical slice, you should be doing smoke and feature testing internally. External playtesting can start once your core loop is stable. Waiting until “the game is done” to start any QA is the single most common mistake I see, and it consistently results in launch-day disasters.
Do I need a separate QA build or can I test the development build?
Test as close to your shipping build as possible. Dev builds often have debug flags, extra logging, and disabled optimizations that mask real issues. Before any significant test pass, especially late in development, run tests on a release-configured build. This catches an entire class of “only breaks in release mode” bugs.
How do I track QA progress without expensive tools?
A spreadsheet works if you commit to it. Create columns for test case ID, description, pass/fail, build number, tester name, and notes. The key is running the same test cases consistently across builds so you can see regressions. Linear’s free tier also covers most of what a small indie team needs from a dedicated tracker.
What’s the difference between playtesting and QA testing?
Playtesting is primarily about game feel, pacing, and design feedback. QA testing is specifically about finding technical defects and verifying that systems work as specified. You need both, they’re different activities, and conflating them makes both less effective. A playtester telling you “level three feels too long” is useful design data. That’s not a bug report.
Photo: cottonbro studio via Pexels
