Inside Our Lean Game QA Process

Years ago, when I was running an indie studio, we ran into a wall trying to hire external QA for our first major multi-platform game. Every major testing house we approached tried to saddle us with a big overhead. Think 50-page documentation packages, rigid contract negotiations, and weeks of bureaucratic setup, it wasn't a great fit for us!

As an indie team, we needed to move fast. We didn't have time for that bloat, so we built our own lightweight testing pipeline instead. We modeled it after our own development tracking, the classic "modified SCRUM that’s actually just Kanban with Sprints" workflow that I see many studios settling on.

Today, that exact battle-tested framework is how we run operations at Ontario Game Testers. We use a dead-simple, high-efficiency "rhythm board" that integrates seamlessly with the tools teams are already using.

How the Rhythm Works on a Milestone Sprint

1. Logging: Testers put their findings into the far-left Bugs column. Don't just say "feature x broke", and don't guess at the cause. Describe the expected vs actual outcome. Every ticket should include crystal-clear descriptions and reproduction steps, along with hardware specifics, platform, version, etc, and if necessary: a video capture or screenshots.
2. The Developer To-Do List: The dev team uses this column as an actionable to-do list. When they pick up a bug, they move it to Fix in Progress. If Bugs is their "To Do", then this is their "Doing" list. When they push it into a build, they slide it over to Confirm Fixed.
3. Confirm Fix and Done: One of our few hard rules: Only the testers can move a card into Done. If we download the latest build and the bug is still present, the card goes right back to column one with fresh logs. If it's verified clean, it goes to Done.
4. Out of Scope: If an issue is simply out of scope for the current milestone (or ever), the developer will move it to Won't Fix to keep the workspace clean.

Why This Is Efficient

Direct, peer-to-peer communication between testers and developers is non-negotiable for us. If an issue is complex, we don't write an essay; we jump on Discord or Slack and talk it out in real time.

Because this process is so lean, we found that testers don't need to mirror your developers' exact working hours. In fact, many indie titles see the highest impact from just 8 hours of targeted testing per week (depending on your game's size and complexity).

Is this ground breaking? No, it's simple, and that's the point. It works, and anyone can follow it.

We built Ontario Game Testers to provide lean communication and high-impact reporting. We drop right into your existing pipeline with zero friction, so your team spends less time trying to reproduce vague bugs and more time moving production forward.

If you're in need of testing, you can contact us for a meeting; or just copy our work above and do it yourself (we don't mind one bit).