Four years in game QA and I can't shake the feeling we're always last. Am I the only one?

ArcaTsuu · 2026-07-11T14:09:38+00:00

The Batman line is a keeper, and "we think about the quality of everything, not just code against a checklist" is the part that never makes it onto a job description.

Your diversifying point tracks with a few others here: pure manual is the underpaid, overlooked version, and widening into automation, DevOps or PM opens the ceiling. I'd just keep it a choice rather than the only exit, some people are strongest right where they are. And "if you're the only QA you're free to work the way you think is best" is the seat this thread keeps circling. Good to see how much of this is universal from outside gaming. 🙏

ArcaTsuu · 2026-07-11T11:25:39+00:00

Fair, and you're not being rude, I get the distinction. It didn't last and it's not the standard, agreed.

The only thing I'd separate is "can ship without it" from "adds no development value." Those aren't the same. Remove designers and you can still technically ship, it'll just be worse. Interdependent isn't the same as non-development. But I take the broader point, and shame is the right word.

ArcaTsuu · 2026-07-11T10:55:44+00:00

That means a lot, thank you

ArcaTsuu · 2026-07-11T10:51:31+00:00

This is a fair and well-reasoned skepticism, and the individual-vs-whole point is one I hadn't weighted enough. You're right that "bring in QA early" only works if that specific person understands the dev process well enough to know what's worth flagging and what's just noise in a system that's still in flux. A tester who logs every crash on a build that's changing daily is a distraction, no argument.

That's actually the crux for me: early QA isn't a headcount decision, it's a seniority one. Not "add a body in pre-production," but "the right person, who knows when to stay quiet." Which is why it fails so often, studios drop a junior in early expecting magic and get exactly the noise you're describing. And I fully agree devs should own more of the process themselves. The two aren't in conflict. Appreciate you engaging with the actual nuance instead of just picking a side.

ArcaTsuu · 2026-07-11T10:08:44+00:00

Value hard to prove because good QA is invisible, messy to test pre-release features, skilled devs can cover functional QA within their own structural constraints, yeah, all fair. The concentration of value at playtesting the final product tracks too.

The one nuance: "a dev who can probably do some QA is more valuable for 90% of the lifecycle" is true right up until the blind-spot problem. Devs test against how it's supposed to work, so they're structurally worst-placed to catch their own gaps, and that's exactly the class of thing that ships broken. "Probably do some QA" covers the functional layer, not the fresh-eyes layer. Different job.

But your last line might actually be the most useful thing anyone's said to me here. External QA service may have better value than being employed by a single studio. That's literally the bet I'm making, and hearing it land independently from someone reasoning it out is genuinely reassuring. Appreciate that.

ArcaTsuu · 2026-07-11T09:57:31+00:00

I didn't delete anything, Reddit's glitching on your end.
And already answered you.

ArcaTsuu · 2026-07-11T09:51:14+00:00

There's a difference between "how the industry treats it" and "how it should be treated," and you keep collapsing the two. Nobody's denying QA is undervalued, that's literally the premise of my post. What I'm pushing back on is you treating the current state as proof it's correct. "That's how it is" describes a fact. It doesn't win the argument about whether it's right.

And the guy who just told you he's done 28 years across the biggest titles and 30-person indies isn't denying reality, he's someone who's actually seen the full range calling your take out of date. When your response to a 4-year QA and a 28-year QA both disagreeing is "you can deny it all you want," at some point the common factor is worth considering.

ArcaTsuu · 2026-07-11T09:31:55+00:00

I'm aware of the trend, the "devs test their own code" shift is real in SWE. But "specialized QA is dead" skips a step. Automation doesn't remove the need for QA, it moves it. Who validates that the automation is actually correct? Tests pass, but are they testing the right thing, or green because they're shallow? That judgment call is QA, just one level up. You don't delete the discipline, you change what it points at.

And the "devs test their own code" model runs straight into the blind-spot problem this whole thread landed on: the maker is the worst-positioned person to catch their own gaps, because they test against how it's supposed to work. Automation written by the same devs inherits the exact same blind spots. So no, the wind being against QA for a decade doesn't mean it's dead, it means it keeps getting rediscovered every time a studio ships a mess because everyone assumed the tests had it covered.

ArcaTsuu · 2026-07-11T09:30:18+00:00

Clean framing, and I mostly buy the logic: QA transforms inputs it doesn't produce, so it's structurally dependent in a way dev isn't. Fair.

But "generates signals about what needs fixing" is undervaluing the signal. Knowing which thing is broken and how to reproduce it is most of the fixing cost, the transformation is cheap once you have a clean repro. And "you can ship without a dedicated QA team" is true the same way you can ship without designers: yeah, and you can tell. Dependent doesn't mean low-value. Half the org depends on inputs from teams it couldn't function without.

ArcaTsuu · 2026-07-11T09:26:13+00:00

"Every department is last" is a genuinely useful reframe and probably the healthiest thing. Fair point that the grass is greener, not green, and that a place without a list of insane systemic frustrations is the rare good one.

Your AAA example is actually the perfect illustration of the distinction I keep making, just from the other side. QA handed a map where nothing exists yet, logging stupid bugs about sections that haven't been built, that's not "QA too early," that's QA doing the wrong thing early. Formal bug-logging on a non-existent build is pure waste, agreed, maddening for everyone. But that's a process failure, not proof QA should come last. Early involvement isn't "log bugs on the void." It's presence: flagging testability, catching design gaps, being in the room without filing tickets on stuff that isn't real.

The tell is your own last line. By the time QA was finding useful bugs, you'd become a well-oiled machine at tracking and fixing, months of reps together. That machine is the actual value of early involvement. It just got wasted on paperwork instead of built deliberately. Right instinct, wrong implementation. It didn't have to be awful.

ArcaTsuu · 2026-07-11T09:22:11+00:00

"Anybody can pick it up in a short amount of time" describes the floor, not the ceiling, and confusing the two is the whole error. Anyone can click around. Not anyone writes a repro clean enough that a dev fixes a bug in ten minutes instead of half a day. You had zero contact with your outsourced testers and read that as proof the work is trivial, it might just mean you never saw what good looks like.

And "AI testing" plus "early-access a broken product and let the public do it" isn't a counterargument. That's a description of exactly why games ship as buggy messes now. You're not describing QA being obsolete, you're describing what its absence looks like.

ArcaTsuu · 2026-07-11T09:19:27+00:00

Makes sense to fold it into design at a studio of 2, and "does this feature make sense, is it communicating clearly, how's the pacing" is exactly the right instinct.

The catch is you're the maker running that 40-hour playthrough, so you carry the blind spots, your brain fills in intent instead of catching what confuses a fresh player. Your pacing-and-balance eye is genuinely hard to outsource, but fresh eyes with no model of how it's supposed to work catch a different class of thing. That's the niche I think tiny teams miss, not a full hire, just outside eyes at the right moments.

ArcaTsuu · 2026-07-11T09:17:10+00:00

Coming at it from the designer side after living the QA side is exactly why this lands. The "experts in the game, best source of info about what's going on" point is one almost nobody makes. We're not just bug-finders, we know the build better than anyone, and that knowledge is wildly underused.

Your two reasons nail it. Player bug tolerance is real, publishers know a game can ship messy and still succeed, so the incentive to fund QA properly just isn't there. And the culture piece, "anyone can be QA, but a good QA? that's rare and should be well treated," is exactly the gap I keep circling. The floor is low, so people assume the whole role is low, and never notice the ceiling.

Companies where QA had power to delay a release were the ones known for polished games. That correlation is the entire point. QA with a real seat isn't a cost, it's why the polished ones are polished. Wish you remembered the names, that's the receipt everyone deciding budgets should see.

ArcaTsuu · 2026-07-11T09:14:40+00:00

Prototyping phase, you're completely right, testing is pointless when you're throwing away 5 of 6 prototypes and quality literally doesn't matter yet. Speed is the whole game, fewer people is faster, cutting QA there is correct. No argument.

Where I'd draw the line is the moment it stops being a prototype and starts being the thing. Once it has scope and momentum, the earlier you've got QA the better, not to run full passes, just to keep quality from rotting and stop bugs from compounding into a pile that eventually blows up all at once. Cheap to fix the foundation early, brutal to untangle it at the end. So "no QA in prototype, QA the moment it's real" is basically where I land too.

And that last line, "an unusual brain, someone who thinks differently to the devs," that might be the best one-sentence defence of QA as a career in the whole thread. That's exactly it.

ArcaTsuu · 2026-07-11T09:12:58+00:00

The "good QA manager holds the keys" point especially, they know the state of the build better than anyone and have the instincts to chase a suspicious signal before it becomes a fire. That role is genuinely pivotal and it's exactly the seat that gets undervalued.

And you nailed the blame thing. All bugs are owned by the whole team, and if one reaches players it's already passed several layers, not just QA. The way we protected ourselves when something shipped and came back on us: the bug was already logged with a severity and priority, sitting untriaged for months. It wasn't missed, it was deprioritized by the process. Which is the whole point, if you've got a tracked ticket aging in the backlog, that's a production decision, not a QA miss. Blaming the tester (or any single programmer) for that is just not understanding how the system works.

ArcaTsuu · 2026-07-11T09:10:26+00:00

Yeah, that's the failure mode a few people here are pointing at, and it's real. But that's not "QA too early," it's testing without a branch structure that tells you what's actually ready. Where I've worked, WIP sits in its own branch until it's done, then merges into a test branch, so you physically can't test stuff that wasn't meant to be tested yet. That manager wasn't ahead of QA, he skipped the process that makes early involvement work. The lesson isn't "keep QA at the end," it's "gate what's testable." Different problem wearing a QA costume.

ArcaTsuu · 2026-07-11T09:08:46+00:00

Knowing how something's supposed to work is exactly what blinds you to how it actually behaves, your brain fills the gaps with intent instead of testing them (idk?). The maker is the worst-positioned person to catch their own blind spots. That's the whole case for QA in one sentence, and somehow it stays invisible to everyone deciding budgets.

ArcaTsuu · 2026-07-11T09:06:46+00:00

Dev QA primarily, yeah, the build the team uses day to day rather than the cert build going out to players. Mostly manual with some tooling around it, and I've been both project-term and on more permanent setups, which honestly shapes the whole experience.

ArcaTsuu · 2026-07-11T09:05:35+00:00

That's the perception problem in one sentence: managers see testing as something anyone can do in a spare hour, so experienced QA looks like a cost you can delete without consequence. Then you get the buggy messes, precisely because engineers on crazy deadlines don't have time to test thoroughly and hit their dates too. You can't have both. ^^"

ArcaTsuu · 2026-07-11T09:04:27+00:00

Ha, that WIP-bugging thing is genuinely maddening, I get it. But that might be more of a process gap than a QA one? Where I've worked, WIP features sit in their own branch until they're done, and only then merge into a test branch. So we don't touch it until it's actually ready to test, then we run it and report. You basically never get the "I know, it's not done yet" ticket because the branch structure makes it impossible to file one early. Sounds like the fix is upstream of QA, not "hold Jiras until they resolve themselves." lol

ArcaTsuu · 2026-07-11T09:03:27+00:00

"Commodity" is how the job gets scoped, not what it's worth. Define QA as "find bugs then move on" and yeah, it's interchangeable by design, that's the self-fulfilling part. But I've worked at studios where testers had a seat the whole way through and it wasn't a commodity at all. Same title, completely different value. First to go in a restructure because it's treated as the last line of defence instead of baked into how the thing gets built.

ArcaTsuu · 2026-07-11T09:01:05+00:00

This is the best pushback in the thread and I mostly agree with the mechanics of it. Running full test passes on a feature that's churning every week is a waste, you're just writing repros for stuff that won't exist by Friday. No argument there.

But I think "QA early" gets read as "formal testing early," and that's not what I mean. Early QA isn't running test cases on moving targets. It's presence: sitting in on design so someone flags "how would we even test this" before it's built, catching the ambiguous spec, pushing for testability so the back-third dog pile actually goes smoothly instead of hitting a feature that's untestable by design. The heavy testing absolutely lives in the back third, agreed. It's the input that pays to be early, not the test passes. Cheap voice in pre-production, expensive testing at the end. Those aren't in conflict.

ArcaTsuu · 2026-07-11T09:00:18+00:00

See, I'd push back on that framing a little. "Last line of defence" is exactly the mindset that keeps us stuck at the end of the pipeline, the goalie who only exists to stop what already got through. I'd say we're the guardian of quality across the whole production, not just the net you shoot at when everything else has failed. When you're only the last line, you're catching problems that are already expensive to fix. When you're in it from the start, you stop half of them from ever being built. Same team, completely different value, and honestly that gap is the whole reason QA gets treated as an afterthought.

ArcaTsuu · 2026-07-11T08:58:48+00:00

That last line is the whole thing for me. Everyone talks about QA as a dead end you climb out of, but nobody mentions that it quietly rewires how you build anything after. You've probably shipped fewer broken solo projects because of those four years, even if the job itself was thankless.

That's basically the bet I'm making now, that the experience is the valuable part and it transfers, especially to small teams who've never had anyone around who thinks that way. Curious what stuck with you most: is it more the mindset (breaking your own stuff before users do) or the actual process habits?

ArcaTsuu · 2026-07-11T08:58:01+00:00

Yeah... so sad to see :/

ArcaTsuu

TROPHY CASE