Every studio says they take QA seriously. Then the launch date moves and QA is the first thing that gets compressed.
It happens so consistently it's almost a law of game development. Not because studios are reckless - most aren't. Because QA is invisible when it's working and only visible when it isn't. The bugs that QA caught never made it into the game. Nobody knows they existed. The bugs QA didn't catch because the team was under-resourced or the timeline was compressed - those show up on launch day in Steam reviews and Twitter threads and refund requests.
The cost of that visibility is enormous and almost always traces back to a decision that seemed like a reasonable tradeoff at the time.
What QA Is Actually For
There's a version of QA that most studios implement - a team of testers who play through the game looking for bugs before release. Find bugs, log bugs, fix bugs, ship.
This is QA in the narrow sense. It's necessary and consistently insufficient.
QA done well is a system for understanding risk across the entire product. Not just "does this crash" but "does this feel right." Not just functional correctness but experiential quality - pacing, difficulty curves, UI clarity, edge cases in player behavior that designers didn't anticipate. QA teams that have enough time and resources to actually play the game the way players will play it - not the way developers expect players to play it - find a completely different category of issues than teams running through checklists.
The difference between these two versions of QA is mostly time. Checklist QA can be compressed. Experiential QA cannot. You can't run a meaningful playtest of a thirty-hour game in three days. The issues that surface after forty hours of play are invisible to a QA process that never went past twenty.
The Pre-Production QA Gap
Here's the thing that most studios get wrong structurally, before a single bug is logged.
QA is treated as a late-stage process. Build the game, then QA it. The QA team meets the product near the end of development when the architecture is fixed, the core systems are built, and changing anything significant is expensive.
The studios that have fewer catastrophic launch problems bring QA involvement into pre-production. Not full QA teams during prototyping - but QA leads reviewing systems design, flagging test complexity before it's built in, identifying features that will be difficult to test and working with engineers to make them testable from the start.
A feature that's hard to test is almost always a feature that's hard to debug in production. The same properties that make something difficult for QA to isolate make it difficult for developers to reproduce when players report issues. This isn't coincidental - testability and debuggability come from the same design decisions. Getting QA perspective on architecture before architecture is final is cheap. Getting it after is expensive.
Platform Certification Is Not the Safety Net Studios Think It Is
App store review and console certification catch specific categories of issues. Technical requirement violations, certain crash types, compliance problems. They do not catch gameplay bugs, progression blockers that require specific player decisions to trigger, balance issues, or the category of "this works correctly but feels wrong."
Studios that treat platform certification as the final QA pass are confusing compliance with quality. Certification tells you the game meets platform requirements. It says nothing about whether players will enjoy it or whether it will hold together under the full range of player behavior.
This matters more now than it used to because day-one patches have made it technically possible to ship with known issues and fix them after release. The practice has normalized a risk tolerance in launch quality that consistently catches studios off guard. Players who are willing to forgive a day-one patch for a minor issue are not willing to forgive a day-one patch for a save corruption bug or a progression blocker that prevents finishing the game. The categories of "fixable after launch" and "damaging to launch reputation" overlap more than studios want to believe.
The Regression Problem Nobody Talks About
A bug gets fixed. QA verifies the fix. The build moves forward. Three days later a different fix introduces the same bug in a slightly different form because the underlying system wasn't fully understood.
Regression testing - verifying that fixes stay fixed and that new changes don't reintroduce old problems - is the part of QA that scales worst with team size and development velocity. In a small game with a small team, one person can hold a reasonable mental model of what changes might affect what. In a large game with multiple teams working in parallel, the interaction surface between systems is too large for any individual to track.
The studios that handle this well invest in automated regression testing for systems where it's feasible - not because automation replaces manual QA, but because automation catches the class of regression bugs that are boring to find manually and genuinely embarrassing to ship. A crash that was fixed six weeks ago reappearing in the launch build is the kind of failure that makes everyone look bad and is preventable with a test that runs automatically on every build.
The studios that handle this poorly rely on QA testers to remember what was previously broken and re-check it manually with each new build. This works as long as the QA team is stable and the build frequency is manageable. It breaks down when QA team members rotate, when build frequency increases near launch, and when the pressure to clear bugs fast means thorough regression gets deprioritized.
Launch Window QA Is a Different Discipline
Pre-launch QA and live game QA are not the same job and studios that treat them as the same are structurally unprepared for what happens after release.
Before launch, QA has a stable build, known test cases, and a clear definition of done. After launch, the game is being played by millions of people with hardware configurations, network conditions, save states, and play patterns that no internal QA process could fully anticipate. The bug reports coming in from players are often poorly described, non-reproducible in internal environments, and arrive in volume that overwhelms any team that hasn't specifically prepared for it.
The studios that handle launch window QA well have invested in tooling before launch - crash reporting infrastructure that captures context automatically, telemetry that surfaces unusual player behavior patterns, build pipelines that can get a hotfix to certification and release faster than the standard process. They've also specifically staffed for it - not assuming the same team that handled pre-launch QA can handle launch window volume on top of the pre-launch workload they're already carrying.
The studios that don't have this discover it in the first forty-eight hours after launch when the player-reported bug volume exceeds what they can triage, prioritize, and respond to coherently.
What Under-Investing in QA Actually Costs
The direct costs are the ones that show up in postmortems. Hotfix development and submission costs. Refund rates that exceeded projections. Review scores that settled below the studio's previous average and affected pre-order conversion for the next title. Community trust that took longer to rebuild than the studio expected.
The indirect costs are harder to quantify and often larger. Senior developer time spent reproducing and fixing launch bugs instead of starting the next project or the expansion content that was in the roadmap. The QA team members who burned out during crunch and left before the studio could leverage the institutional knowledge they'd built. The publisher relationship that got complicated after a launch performance that didn't meet projections.
None of this is theoretical. Studios that have been through a difficult launch talk about it in these terms when they're being honest. The cost of the QA investment that didn't happen is almost always larger than the cost of the QA investment that would have prevented the problem.
The Cultural Problem Underneath the Resource Problem
Here's the thing that doesn't usually make it into the public postmortem.
QA underinvestment is often a symptom of how the studio thinks about QA teams, not just how they budget for them. Studios where QA is a respected discipline - where QA leads have real influence on ship decisions, where bug advocacy is taken seriously, where "QA says it's not ready" carries weight - tend to ship cleaner products than studios where QA is a department that gets called in to bless whatever development hands them.
The studios where QA has genuine authority are the ones where product leaders have internalized that QA is not a cost center that slows shipping down. It's a risk management function that determines what kind of product reaches players.
That cultural shift - which is a leadership decision more than a hiring decision - is what separates studios that consistently ship quality from studios that consistently have complicated launches and tell themselves they'll do better next time.
Working with an experienced game development company like Hyperlink InfoSystem means QA is built into the development process from the start - not bolted on at the end when the timeline is compressed and the damage is hardest to prevent.
The launches that go well aren't lucky. They're structured.
Top comments (0)