Why I stopped paying for external QA and just run my own tests
When you ship indie games, someone has to play them before players do. That's usually you. I used to send builds to a small group of testers and wait two weeks for feedback that was always too vague to act on. "The second level felt boring" means nothing when you're trying to fix a collision bug or tune a damage curve. So I switched to running my own solo Gameplay Test Solo Run workflow, and it changed how I approach every project since. The core idea is straightforward: you play through your own build methodically, not casually. Casual play is what players will do. It's also useless for finding structural problems. You need to treat the build like a system you're auditing, not entertainment. I script out a checklist before I start — every area, every ability, every UI state, every edge case I can think of — and I go through it in order. If I skip something because I'm bored, I note where I left off and come back. Boredom during testing is a feature, not a bug. It tells you where your pacing breaks.
Gameplay Test Solo Run: the actual process
My typical session runs about 90 minutes for a medium-sized level or module. I break it into three passes. First pass is pure exploration: walk every corridor, hit every switch, try to break the obvious things. Second pass is targeted: I go back and test the systems I flagged in pass one — combat encounters, resource drains, save/load behavior, restart logic. Third pass is the player simulation: I play through as if I've never seen the game before, following only the tutorial and on-screen prompts, recording where I get confused or stuck. I run all three passes in one sitting when possible. Context switching between sessions costs me about twenty minutes of refamiliarization each time. I use a simple spreadsheet to log issues with a severity rating, a reproduction step, and a screenshot or short video clip. The spreadsheet is not optional. Verbatim memory of bugs is unreliable after six hours of testing. I've lost count of how many times I convinced myself I'd documented something and it wasn't there. Here's the part nobody tells you: solo testing reveals different problems than group testing. When you're alone, you notice the empty spaces. You notice when a hallway feels wrong because you walked it forty times. You notice audio cues that should be guiding you and aren't. Groups will tell you about the big dramatic failures — the boss that's impossible, the quest that stalls. They won't tell you that the lighting in the third room makes the objective marker unreadable. That's solo territory. Both approaches have value. I use solo runs for polish and pacing and group sessions for fun and difficulty validation.
I had a specific issue last year with a stealth section where the enemy detection cone visual was misleading. During my solo run I spent twelve minutes trying to understand why I kept getting spotted when I thought I was hidden. I checked the logs, looked at the raw detection values, and found that the cone mesh was rotated three degrees off from the actual detection arc in the code. The artist had moved it during a layout pass and nobody caught it because playtesting groups were rushing through that area. I fixed the rotation mismatch, re-exported the nav data, and moved on. This kind of mismatch is invisible unless you slow down and test deliberately. Another counter-intuitive thing about solo testing: the optimal pass order isn't what most people assume. You should run the third pass — the naive player simulation — last, not first. If you do it first, you bias your subsequent passes. You'll start looking for the problems you already noticed instead of discovering new ones. Each pass should be blind to the previous one as much as possible. I sometimes close the spreadsheet between passes so I'm not primed to look for the same issues. The main limitation of this approach is that solo testing cannot validate fun. It can validate clarity, consistency, and technical correctness. Whether a combat encounter is satisfying or a puzzle is elegant requires other humans. Don't conflate the two. If your solo runs are producing zero critical bugs but the game feels flat, that's a design problem, not a testing gap. Hire or borrow actual players at that stage. Solo runs are a filter, not a verdict.
Get the Full Details
One practical tip that saves real time: automate your save states. I use a debug key combo that snaps a save at any point, and I load those saves to re-test specific sections without replaying thirty minutes of traversal. This cuts regression testing from roughly an hour down to fifteen minutes for most modules. I also use the console to toggle visibility of collision meshes, hitboxes, and AI state. Running blind in these situations wastes more time than any shortcut saves. There's no tool or framework that replaces actually playing the game yourself. People sell testing pipelines and QA suites, but they can't replicate the friction you feel when your own build is slightly out of sync with your intent. Just run the tests. Log the bugs. Fix the rotation mismatches. Repeat until the spreadsheet stops growing.
