What testing is for
Testing a game means looking for the gap between what the team intended and what actually happens on a player’s screen. Sometimes that gap is obvious, like a crash on startup. Sometimes it is subtle, like a door that opens only if you approach it from the left. Either way, the tester’s job is to find the gap, describe it clearly and help confirm it is closed.
The formal name for this work is quality assurance, usually shortened to QA. The term comes from manufacturing, where it describes the processes that keep a product consistent. In games it covers a wide range of activity, from a person systematically trying every menu option to automated scripts that start the game overnight and check that it loads.
What testers actually do
The picture of someone paid to play all day is only partly accurate. Much of the work is repetitive and deliberate. A typical day might include:
- Following a written test plan that lists features and the checks to run on each.
- Trying unusual input: pressing every button at once, pausing during a loading screen, disconnecting a controller mid-match.
- Writing up each problem so a developer can reproduce it.
- Re-checking fixes in a new build to confirm they work.
- Checking that nothing nearby broke as a side effect.
Testers often work on a particular build, which is a specific compiled version of the game. Because the game changes daily during production, a note about which build a problem appeared in is part of almost every report.
The main kinds of checks
Teams name their checks in different ways, but a few categories appear almost everywhere.
Functional testing asks whether features do what they should. Does the inventory open, does the save button save, does the score add up?
Compatibility testing asks whether the game behaves on the range of hardware, screens and software that players use. It deserves its own treatment because the combinations multiply quickly.
Performance testing looks at frame rate, memory use and load times, ideally with measurements rather than impressions.
Localization and text checks confirm that translated text fits in its boxes and that nothing is left in the wrong language.
Certification checks apply to console and storefront releases, where the platform holder publishes requirements a game must meet before it can ship. The details vary by platform and change over time, so teams read the current documents rather than relying on memory.
Accessibility also belongs here. Checking that remapping works, that text is legible and that comfort options behave is part of accessibility testing, ideally with disabled players involved rather than guessed at by the team.
Severity and priority
Not every defect deserves the same urgency. Many teams label each one twice. Severity describes how bad the effect is: a crash that loses progress is more severe than a misspelled item name. Priority describes how soon it should be fixed, which depends on the schedule and how many players will meet it. The two can disagree. A typo on the main menu is low severity but might be high priority because everyone sees it.
These labels are judgment calls, and reasonable teams draw the lines differently. What matters is that the team agrees on what the labels mean, so a tester’s rating is not argued over each time.
How QA differs from playtesting
The two activities are often confused because both involve people playing the game. The difference is the question being asked.
QA asks: does the game work as specified? A tester knows the intended behavior and looks for deviations. They are expected to be thorough and to repeat things.
Playtesting asks: do players enjoy this, understand it and get stuck? The people involved are often outsiders who have never seen the game, because their confusion is the data. A playtester who reads the instructions carefully and never gets lost tells you less than one who wanders into the wrong room.
A game can pass QA and fail a playtest. Every button might work exactly as designed while a new player still cannot work out what to do first, which is a question for player onboarding and interface usability rather than for bug tracking. The reverse also happens: a design that players love can ship with a broken save feature that QA would have caught.
Playtesting with real players is covered in its own article, so the key point here is that the two efforts feed each other. Playtest feedback may become design changes, which then need QA to verify.
Where testing sits in a schedule
Testing is not one phase at the end, although the heaviest effort usually comes late. Small teams might test informally from the first day by simply running the game after each change. Larger teams often bring in dedicated testers once features are playable and expand the group as release approaches.
Development stages are often named alpha, beta and release candidate, and the exact meaning of each varies by studio. A common pattern is that early stages focus on whether features exist and work, while later stages narrow to fixing the most serious problems and avoiding new ones. If a change late in production is risky, teams may deliberately accept a minor flaw rather than disturb working code.
Once a game is out, testing continues. Updates need checking, and each fix raises the chance of regression testing finding that an older problem has returned.
Automation and its limits
Automated tests can run the same checks repeatedly and quickly, which suits tasks like verifying that every level loads or that a calculation returns the expected value. They are less suited to judgments such as whether an animation looks wrong or a puzzle feels unfair. Most teams use a mix, with machines handling the repetitive checks and people handling the judgment.
Automation also needs maintenance. A script that checks a menu layout breaks when the layout changes, so a small team may find that writing the script costs more than running the check by hand a few times.
What testing cannot promise
No amount of testing proves a game is free of defects. It can only reduce the number and severity of those that reach players, and the combinations of hardware, input and player behavior are too many to check exhaustively. This is why launch-day updates are normal, and why teams often invite outside players into a beta testing period to see how the game behaves in conditions the internal team could not reproduce.
Good testing is therefore less about perfection than about making informed choices: knowing which problems exist, how serious they are and which ones the team is willing to ship with. Clear, reproducible reports from testers are what make those choices possible.