QA Is Not Playtesting: What the Difference Costs Studios Who Confuse Them
Photo by on Unsplash
Your QA team can verify that a tutorial button fires correctly every single time. What they cannot tell you is whether any player actually understands what the button is asking them to do. That gap, between "it works" and "it makes sense," is where games quietly fail. Studios that treat QA and playtesting as interchangeable are running only half the picture, and the half they're skipping tends to be the one players notice first.
What QA Actually Does (And What It Doesn't)
Quality assurance is about functional correctness. Your QA team is asking: does the game do what it's supposed to do, technically? They hunt crashes, verify build stability, check that mechanics execute as designed, and confirm that the experience ships without breaking. That work is essential. It's also not the same as understanding whether players enjoy it, get it, or want to keep playing.
QA testers are trained to break the game on purpose. They take paths players would never take, input nonsense values, stress-test edge cases. That's exactly the right mindset for finding technical defects. It's the wrong mindset for understanding how a first-time player will feel when they hit your onboarding sequence cold, with no context, no tutorial text already memorized, and no patience for friction.
According to Antidote's breakdown of QA vs. playtesting, studios frequently fall into the trap of assuming that a bug-free build means a playable one. Those are genuinely different standards, and conflating them is one of the most common and costly mistakes in game development.
What Playtesting Does That QA Can't
Playtesting puts real players, not trained testers, in front of your game and watches what happens. The questions being answered are different: Do players understand the goal? Are they having fun? Where do they get confused, bored, or frustrated? What do they do when they don't know what to do next?
These are behavioral questions, not technical ones. A playtester who gets lost in your level two isn't reporting a bug. They're showing you something about your design. That signal is only visible if someone is watching for it, and it requires the right participants. A QA tester who knows your game inside out will almost never surface it, because they already know where to go.
The observer context matters too. Research on remote playtesting consistently shows that players behave more naturally when they're in their own environment, not sitting in a studio lab with team members watching over their shoulders. Remote sessions often produce more honest behavior, which means more usable data.
The Real Cost of Mixing Them Up
When studios only run QA before ship, they tend to find out about experiential problems the hard way: reviews, social posts, and day-one churn numbers that don't make sense given the months of internal testing that happened. The game worked. It just didn't connect.
Fixing a UX problem during development costs a few hours of a designer's time. Fixing the same problem after launch costs you players who already made up their minds, press coverage you can't take back, and a community perception that's harder to shift than most studios expect. The math on early playtesting is not subtle.
A few specific failure modes that playtesting catches and QA doesn't:
- Invisible onboarding gaps. Your FTUE makes total sense to the team who built it. To a player with no context, step three might as well be in another language.
- Difficulty spikes that feel unfair, not challenging. QA confirms the spike is working as intended. Playtesting tells you whether "working as intended" is actually fun.
- Unclear core loops. If players can't articulate what they're supposed to be doing after fifteen minutes, the loop isn't clear enough, regardless of whether every mechanic is functioning.
- Misleading UI. A button label that your team reads one way might be read completely differently by someone who didn't build the screen.
How to Run Both Without Blowing Your Schedule
The practical question isn't whether to do both. It's how to sequence them without turning your production calendar into a research project.
A useful framing: QA runs continuously and confirms your build is stable. Playtesting runs at defined milestones and confirms your experience is landing. Those are different cadences, different participants, and different questions. They don't need to compete for the same time or the same budget.
Early playtesting, even rough and informal, is almost always better than no playtesting until the game is nearly done. A twenty-minute session with five representative players in vertical slice can surface problems that your team has been too close to the project to see. That's not a critique of the team. It's just how familiarity works.
Studios that build playtesting checkpoints into their roadmap rather than bolting it on at the end tend to ship with more confidence and fewer post-launch surprises. VGM's research services are set up to slot into exactly that kind of phased approach, whether a studio needs help designing the study, recruiting the right players, or running sessions remotely at scale.
Getting the Right Players in the Room
One reason playtesting gets skipped isn't laziness; it's recruiting. Finding players who match your actual target audience, not just whoever's available or whoever works at the studio, takes effort that most teams don't have bandwidth for mid-development.
This is where the QA-vs-playtesting confusion often compounds. Studios use their QA team as playtesting proxies because they're already there. But a QA tester who has played the game a hundred times is not a representative first-time player. They can't be, no matter how hard they try to forget what they know.
Solving the recruiting problem is solvable, but it requires planning. Who is your game actually for? What platforms do they play on? What games do they already love? Those questions need answers before you can recruit the right participants, and getting that wrong means your playtest data is measuring the wrong thing.
Frequently Asked Questions
Can QA testers also do playtesting?
Not effectively. QA testers are trained to find technical failures, and they know your game too well to simulate a first-time player's experience. Playtesting requires participants who are genuinely unfamiliar with the game and represent your actual target audience. Using internal QA for playtesting is one of the most common ways studios end up with biased session data.
How early in development should playtesting start?
Earlier than most studios expect. Even a rough prototype or a single playable level can generate useful signals about whether your core loop is readable and whether the tone is landing. Waiting until late beta means you're testing against a deadline, which limits what you can actually fix based on what you learn.
How many playtesters do you need for a useful session?
For qualitative usability work, five to eight players per session is generally enough to surface the most significant patterns. For quantitative signals like retention curves or difficulty calibration, you need larger samples. The right number depends on what questions you're asking, which is why defining your research goals before you recruit matters.
What does a playtesting session actually look like?
It varies based on what you're testing, but a typical session involves a player with no briefing playing a defined section of the game while a researcher observes, either in the room or via screen share. The researcher notes where the player hesitates, gets confused, or makes unexpected choices. Debrief questions follow. It's less formal than it sounds and more revealing than most teams expect.
Is remote playtesting as useful as in-person?
For most types of game research, yes. Remote sessions reduce the observer effect, give players a more natural environment, and make it much easier to recruit from your actual target audience rather than whoever lives near your studio. In-person sessions are still worth it for specific hardware or accessibility testing, but remote is the practical default for most studios today.