Game Dev · July 6, 2026
Bug Tracking and QA Workflow for a Two-Person Shmup Team
A bug reported in a Discord message and never written down anywhere else is a bug that will resurface a month later with nobody remembering it was ever found. Without a QA department, the tracking process has to be simple enough that two overworked people actually keep using it.
Published July 6, 2026
A studio with a dedicated QA team can afford a heavyweight tracker with custom workflows, severity matrices, and assigned triage staff. A two-person team building a shmup in whatever hours are left after day jobs cannot, and adopting the same tooling usually just means the tracker gets ignored within a few weeks in favor of whatever channel is fastest in the moment — which is exactly how bugs get reported once and then forgotten. The right system for a small team is not a smaller version of enterprise QA tooling; it is a genuinely different, minimal process built around the actual constraint, which is that nobody has spare hours to spend maintaining the tracker itself.
A plain issue list beats an elaborate tracker nobody opens
A single flat list — a spreadsheet, a plain text file in the repository, or the issue tracker built into whatever code hosting service the project already uses — outperforms a purpose-built bug database if the purpose-built option requires enough setup friction that reporting a bug becomes its own small chore. The entries that matter are short: what happened, what should have happened instead, and how to reproduce it. Categories, priority fields, and custom statuses can be added later if the list grows large enough to need them; starting with an elaborate schema for a project that currently has twelve open bugs is solving a problem the team does not have yet.
Reproduction steps are the only field that actually matters
A bug report without reproduction steps is close to worthless, because "sometimes I die when I shouldn't" gives a developer nothing to act on beyond guessing. The discipline worth enforcing, even informally, is that every report includes at minimum: what stage or scenario, what the player was doing right before it happened, and whether it reproduces consistently or only occasionally. A report that says "happens sometimes near stage three's midboss when grazing a spread pattern" is immediately actionable in a way that a one-line complaint is not, and getting reporters — including external playtesters — into that habit early saves far more time than any tracker feature would.
Turning Discord chatter into tickets, not letting it stay chatter
Community playtest feedback overwhelmingly arrives as conversational messages, not structured reports, and expecting external testers to file a proper ticket themselves is unrealistic for most of them. The workable pattern is a single person on the team — rotating if the team is only two people — responsible for periodically sweeping the playtest channel and converting anything actionable into a real entry on the tracked list, discarding vague reports that cannot be reproduced from the information given rather than letting them accumulate as noise. This connects directly to the broader discipline covered in running effective playtests: feedback that never gets converted into a tracked, reproducible item was effectively wasted regardless of how useful the underlying observation was.
Severity tags, kept simple
Three tiers cover nearly every case a small shmup team needs: crash or save-corruption bugs that block play entirely, gameplay bugs that affect fairness or scoring but do not block progress, and cosmetic or minor issues that can wait indefinitely. Anything more granular than three tiers tends to produce arguments about classification that cost more time than the extra precision saves. The crash tier gets fixed before any other work; the fairness tier gets triaged against whatever release is next; the cosmetic tier gets batched and addressed whenever there happens to be spare time, which for a small team may mean rarely.
A regression pass before every release, not just before the big ones
Fixing a bug can introduce a new one nearby, and a small team without automated test coverage for gameplay behavior has to rely on a short, repeatable manual regression pass before each release — playing through the specific scenarios tied to whatever changed, not the entire game from scratch every time. This is a smaller-scale version of the same discipline behind planned, versioned patch releases: a fix shipped without checking its immediate surroundings for new problems trades one bug for the risk of a different one, and that risk compounds with every release that skips the check.