Two related jobs
Testing in game development covers two separate questions. The first is whether the game works as intended: does it crash, are features broken, does the content display correctly? That is the core of quality assurance, usually shortened to QA. The second is whether players understand and enjoy the game: do they know what to do, where to go, and why they are doing it? That is the purpose of playtesting.
The two overlap, and the same person can do both, but they use different methods and answer different problems. A game can be technically flawless and still baffling. It can also be delightful in design and riddled with crashes.
What QA testers do
QA testers play the game methodically with the aim of finding problems. Much of the work is deliberate and repetitive. A tester might run the same sequence on different hardware, try unusual combinations of actions, or push against the edges of the rules to see what breaks.
Typical activities include:
- Functional testing. Checking that each feature behaves as described, from menus to saving to combat.
- Regression testing. Re-checking old features after changes, since fixing one thing can quietly break another.
- Compatibility testing. Running the game across the range of supported hardware, operating systems, controllers and settings.
- Performance testing. Watching for slowdowns, stutter and long loads. Issues with frame rate or load times are often found this way.
- Localization testing. Checking that translated text fits on screen and displays properly.
- Compliance testing. Confirming the game meets technical requirements of the platforms it will be published on.
- Soak testing. Leaving a game running for a long period to expose memory problems or crashes that only appear over time.
Testers are not just looking for crashes. They also note visual glitches, missing sounds, text errors, objects that can be walked through, and places where the player can get stuck or skip content.
The bug report
When a tester finds a problem, they write a report so that developers can understand and fix it. A useful report generally includes:
- a short, specific title
- the exact steps to reproduce the problem
- what was expected and what actually happened
- the build version, platform and settings
- screenshots, video or logs where possible
- how often it occurs
The most valuable detail is reliable reproduction. A bug that happens every time can usually be fixed. One that appears rarely is much harder, and testers often spend a lot of time narrowing down the conditions.
Reports are tracked in a database, where each one is assigned a priority. Common labels run from crashes and data loss, which are urgent, to small cosmetic errors, which may be fixed later or left alone. Deciding what to fix before release is a judgment about severity, how many players it affects, and how much time remains.
What playtesting does
Playtesting asks people to play the game while the team observes. The people may be colleagues, friends, volunteers from a community, or recruited members of the target audience. The strongest feedback usually comes from people who have not seen the game before, because the developers know too much to see it fresh.
Methods vary. In an observed session, developers watch in silence, noting where the player hesitates, repeats an action, or looks confused, and avoid helping so they can see what truly happens. Some sessions ask players to speak their thoughts aloud. Others use questionnaires or short interviews afterwards. Remote tests can collect play data automatically, such as where players fail most often.
Playtesting commonly reveals:
- unclear goals or instructions
- controls that feel awkward
- interface elements that are hard to read, which touches on how game interfaces are designed
- difficulty spikes or sections that are boring
- features players ignore, or use in ways the designers did not expect
What players say and what they do can differ. A player may report enjoying a section while visibly struggling, or complain about something that actually works fine. Developers therefore weigh behaviour and comments together, and look for patterns across many testers instead of reacting to one opinion.
When testing happens
Testing is spread through the project. Early tests often use a rough game prototype to check whether the central idea is enjoyable. Spaces are tested as they are built, which is a large part of level design. Near release, QA activity ramps up, with full test passes, a stage when the team stops adding features, and a final candidate build checked before it ships.
Testing continues after launch as well. Updates and balance patches need their own checks, and reports from players often reveal issues that slipped through.
Accessibility and inclusive testing
Many teams include testing for players with different needs, such as checking captions, colour choices and control options. This is part of broader work on game accessibility, and feedback from disabled players is generally more informative than guesses made by sighted, fully mobile testers.
Why bugs still reach players
Even thorough testing cannot guarantee a perfect game. Modern games have a very large number of possible states and actions, and no team can test every combination. The range of players’ hardware is wide and constantly changing. Deadlines force trade-offs, and testers may find more problems than can be fixed in time. Players, in large numbers, also behave in ways testers never imagined.
Testing therefore reduces problems but does not remove them. It is best seen as a way of finding the most serious and most common issues early, while there is still time to deal with them.