The main types of game testing used in production today are functional, regression, smoke, performance, load, stress, stability, compatibility, localisation, usability, security, and certification. Every project mixes them differently, but the underlying split is the same: functional QA confirms features work, non-functional QA confirms the build holds up under real conditions, and platform certification confirms it can ship.
If you are scoping a QA cycle for a new build, a regression pass, or a device-lab compatibility sweep, talk to Game-Ace.
The two approaches behind every type of game testing
Every test method sits inside one of two approaches: black-box or white-box. Black-box QA runs the game as a player would, without visibility into the code; the tester exercises features, records defects, and files reproduction steps. White-box QA runs against the codebase itself, usually by developers, with unit tests and coverage tools written against known internals.
Black-box QA
Runs the game exactly as a player would, with no visibility into the code. The tester exercises features, records defects, and files reproduction steps.
White-box QA
Runs against the codebase itself, usually by developers, with unit tests and coverage tools written against known internals.
Grey-box QA
Sits in the middle: the tester knows the architecture at a high level and designs test cases against expected behaviour of subsystems (multiplayer sync, save-load, matchmaking).
Most production teams run both black-box and white-box. Developers cover white-box at the pull-request level; a dedicated QA team runs black-box across builds. The ISTQB foundation syllabus formalises this vocabulary, and most studios recruit QA leads familiar with it.
The main types of game testing, at a glance
Ten types of game testing cover the majority of production work across mobile, PC, console, web, and VR. The table below shows what each type validates, when it runs in the cycle, and what the QA team hands back to production.
| Type | What it validates | When in the cycle | Typical deliverable |
| Functional | Every documented feature behaves per the GDD | Pre-alpha through alpha | Feature-coverage report, bug list with repro steps |
| Regression | Recent code or content change did not break prior features | Every accepted fix; daily during alpha and beta | Regression suite pass/fail log |
| Smoke | Build is stable enough to hand to full QA | Every new build, before deep test execution | Smoke checklist result, go/no-go note |
| Performance | Frame rate, memory, load times on target hardware | Vertical slice through release candidate | Perf capture (fps, memory, CPU/GPU) per device |
| Load | Backend and matchmaking under concurrent user volume | Closed beta, pre-launch, live ops peaks | Load-test report with breaking point and bottleneck |
| Compatibility | Build runs across the target device and OS matrix | Beta for mobile, release candidate for console | Device-matrix pass/fail with defect list |
| Localisation | Text, UI, and cultural content work per locale | After text lock, mid-beta | Localisation defect log per market |
| Usability | Onboarding, controls, UX friction on real players | Closed and open beta | Session recordings, UX finding list, priority fixes |
| Security | No unauthorised access, exploit, or economy abuse | Pre-launch and every post-launch update | Pen-test report, remediation list |
| Certification | Build meets platform technical requirements | Release candidate | Cert submission pack, TRC/TCR checklist |
The split into functional and non-functional QA covers most of these types. Certification sits apart because the gate is external: platform holders (PlayStation, Xbox, Nintendo, Steam Deck verification) publish their own technical requirements, and the QA pack has to match.
Functional and regression: the two most common types of game testing
Functional testing checks that a feature does what the GDD says it should do. A QA engineer runs through the documented flow, records the outcome, and files a defect if behaviour does not match. When a feature is added or changed, functional QA validates that specific slice of behaviour.
Regression testing checks that the change did not break something else. The same QA team runs a fixed regression suite against a wider set of features, looking for side effects. Regression scales with the codebase; on a live game with weekly patches, an automated regression suite catches most integration defects overnight.
The Unity Test Framework is a common choice for automated regression on Unity projects, with edit-mode and play-mode tests running in the Editor and on target devices. On Unreal projects, the built-in automation system fills the same role. Selecting what to automate is the harder problem: economy math, save-load, and multiplayer sync usually pay back automation cost; one-off cinematic sequences rarely do.
Performance, load, and compatibility: the non-functional types of game testing
Non-functional QA measures how the build behaves, not what it does. Performance testing captures frame rate, memory footprint, CPU and GPU load, and startup time on target hardware. Load testing pushes the backend with concurrent-user traffic to find the breaking point. Compatibility testing runs the build across a device matrix; on mobile, that is often 40-80 handsets covering the Android and iOS footprint the game needs to support.
Stability testing runs the game for extended sessions and captures memory leaks, crash rate, and reliability metrics. Timing matters: performance work starts at the vertical slice, load testing peaks in closed beta, and compatibility work concentrates late in the cycle, because the build has to be stable enough that device-specific defects are the only signal left.
For platform-specific detail on mobile and Android device labs, see the Game-Ace mobile game testing and Android game testing guides.
Localisation, usability, security, and certification
Localisation QA runs after in-game text is locked. Testers check that strings fit UI layouts across languages, that culturally sensitive art and copy are adapted per market, and that regional legal notices render correctly. On projects with 10+ locales, localisation QA is usually a specialist vendor or a dedicated in-house team.
Usability testing looks at how real players behave with the build. Session recordings, structured interviews, and metric collection during closed and open beta feed a prioritised list of UX fixes. This is the least automatable QA type; the value comes from human observation.
Security testing prevents unauthorised access to the backend, economy exploits, and client-side tampering. On projects with in-game currency, marketplaces, or competitive leaderboards, security passes are mandatory before every launch and every content update.
Certification is a separate gate. Console platforms publish technical requirements (PS TRC, Xbox TCR, Nintendo Lotcheck); the release candidate has to pass every applicable item. VR headsets have their own store submission rules. For a deeper look at VR, see the Game-Ace testing VR games guide.
Manual and automated types of game testing
Most types of game testing run in both manual and automated modes; the split depends on payoff.
Manual QA covers:
- Exploratory testing and edge-case hunting.
- Usability and player-experience assessment.
- Localisation and cultural adaptation checks.
- Certification pack preparation.
- One-off cinematic and narrative sequences.
Automated QA covers:
- Regression suites on every build.
- Unit and integration tests written by developers.
- Performance captures across a device farm.
- Load tests against staging backend.
- Smoke suites triggered on every CI build.
The rule most studios settle on: automate what runs often and is stable, keep manual coverage on what is subjective or changing.
A QA case from Game-Ace
Welcome to Cricket Manager, a mobile sports MMO by Game-Ace
Cricket Manager is a mobile MMO sports simulator built full-cycle and in-house by Game-Ace, using server-side computation for smooth multiplayer play. The title reached 100K+ downloads after launch, with QA covering functional testing, device compatibility, and the graduated league system.
When to talk to Game-Ace about types of game testing
Game-Ace covers the full spectrum of types of game testing under Team Extension, Co-development, and Full-cycle delivery. Engagements typically start with a test-plan review against the project’s GDD, defined exit criteria per QA type, and a coverage split between automated regression and manual exploratory work. Standards vocabulary follows the ISTQB foundation syllabus, and internal test tooling includes the Unity Test Framework, Unreal’s automation system, TestRail or Xray for test management, and Jira for defects.
If types of game testing are part of your delivery plan, game development studio Game-Ace supports the QA cycle end to end with a 120+ specialist team, including dedicated QA engineers, test automation leads, and device-lab access. Related services include game testing services, the option to hire game testers, and game co-development for teams that want QA embedded alongside their in-house engineers. For the timeline view of a QA cycle across the full build maturity curve, see the companion piece on video game testing stages.
Two next steps if you are scoping QA support for an upcoming build or a live game:
Mobile game testing for iOS and Android: end-to-end guide 
Hiring a QA game tester: skills, cost, engagement models 
Game QA companies: a buyer's guide for studios 
Video game testing stages, from pre-alpha to live ops 
Android game testing that survives device fragmentation 
