Video game testing stages cover the full QA life cycle, from internal dev-build smoke checks through pre-alpha, alpha, beta, release candidate, gold master, soft launch, and live ops. Each stage has a different scope, a different test audience, and a different exit gate. This guide walks through what happens at each stage, what tools studios reach for, and where outsourced QA partners fit.
How the video game testing stages map to a build cycle
Most studios run video game testing stages along the build maturity curve. A build moves from internal dev builds (unit and smoke tests) into pre-alpha (vertical slice with first integrated systems), then alpha (feature-complete with placeholder content), beta (content-complete with live load and external testers), release candidate, gold master, soft launch in selected territories, and finally live ops once the title is public. The exit criteria tighten at every step: pre-alpha closes when core loops play end to end, alpha closes when functionality matches the GDD, beta closes when crash rate and severity-1 bug count fall under release thresholds.
The split is not academic. It determines who runs the tests, what hardware they use, and what the QA report needs to contain.
Industry test-process vocabulary follows the ISTQB foundation syllabus, which standardises terms such as test plan, regression set, smoke test, and exit criteria. Reading the foundation glossary saves time when QA vendors and internal teams disagree on what "alpha exit" actually means. See ISTQB testing standards for the official taxonomy.
| Stage | Build scope | Who tests | Exit criteria |
| Pre-alpha | Vertical slice, first integrated systems | Internal dev QA | Core loop playable end to end |
| Alpha | Feature-complete, placeholder content | Closed QA team, sometimes external partner | All GDD features present, no severity-1 blockers |
| Beta (closed) | Content-complete, balancing in progress | Invited external testers, 50–200 people | Crash rate under target, balance issues triaged |
| Beta (open) | Public test client, telemetry on | Real player base, often 10,000+ accounts | Server stability, monetisation funnel validated |
| Release candidate | Frozen build for certification | Internal QA plus platform cert | All known severity-1 and 2 bugs closed |
| Gold master / soft launch | Submission build, soft launch in selected regions | Live players in limited markets | Retention and ARPDAU at target, no rollback triggers |
| Live ops | Live build with patches and content drops | QA partner running regression on each patch | Regression suite green, telemetry stable |
Pre-alpha and the alpha stage of a game
Pre-alpha is the first stage where a build is testable end to end, even if assets are placeholders and content is thin. Developers run unit tests against gameplay code, and a small QA group runs smoke checks against new commits. The alpha stage of a game starts once features are complete against the GDD. At alpha, every system documented in the design is present in the build, even if it still uses grey-box environments, programmer art, or default audio. Closed alpha is run by a dedicated QA team, in-house or contracted, against a written test plan.
Alpha is where most of the deep test execution happens. Functional QA validates every documented feature, non-functional QA covers performance, load, memory budgets, localisation, and platform-specific behaviour.
Two patterns recur in alpha plans. First, smoke-then-deep: run a daily smoke suite that exits in under 30 minutes, then route deep test execution onto a slower nightly run. Second, regression-on-merge: every accepted bug fix triggers a focused regression set, not a full sweep. This is where automated test frameworks pay back, whether that is the Unity Test Framework for C# play-mode and edit-mode tests or Unreal Engine's automation system for functional and screenshot tests.
Game-Ace runs alpha cycles for partner studios under co-development and full-cycle agreements, with test plans structured against the project's GDD and a defined exit gate.
Beta testing: closed beta, open beta, and what comes after
Beta starts once the build is content-complete and the severity-1 blocker list is empty. The exit gate moves from "do features work?" to "is the experience release-ready under real player load?". Beta runs in two phases. Closed beta uses 50–200 invited testers, often with NDA, to capture remaining functional defects and balance issues. Open beta routes the build to a wider public audience, frequently tens of thousands of accounts, with telemetry and crash reporting enabled to validate server stability, monetisation funnels, and live ops tooling.
What comes after beta is not one thing. For console and certified titles, the next gate is the release candidate, submitted to first-party certification. For mobile and live service titles, soft launch in selected territories comes next, used to tune retention and economy before a global push. For PC and live multiplayer games, the gold master often coincides with a public release on the launch storefront, with patches already queued for day-one.
Difference between alpha and beta in games, stated cleanly: alpha asks whether the features exist and work; beta asks whether the product is shippable under real conditions. Alpha is about functional completeness against the GDD. Beta is about external validation against a real audience.
Typical beta deliverables Game-Ace QA produces for partner studios include:
- Daily crash digest with stack traces grouped by signature.
- Bug list with severity, reproduction steps, build, and hardware profile.
- Telemetry sanity check against the analytics spec.
- Localisation defect log for any markets included in the beta.
- Pre-cert checklist when the next gate is platform submission.
QA types studios run across the video game testing stages
Stages define when tests run; QA types define what they check. The two axes are independent. Functional QA, regression, performance, compatibility, localisation, and certification each have a place in the cycle.
Most teams allocate QA types roughly like this:
- Functional QA: heavy in pre-alpha and alpha, lighter once feature work freezes.
- Regression: every accepted fix, daily during alpha and beta, on every patch in live ops.
- Performance and load: starts at vertical slice, peaks in closed beta with real server traffic.
- Compatibility: device matrix testing peaks in beta for mobile, in release candidate for console.
- Localisation: scoped after lock of in-game text, usually mid-beta.
- Certification: only at release candidate, against platform technical requirements.
Tool selection follows the QA type. Test management runs in TestRail, Xray, or PractiTest. Defect tracking sits in Jira or Azure DevOps. Automation runs through Unity Test Framework or the Unreal automation system. Performance captures use platform profilers, RenderDoc, and engine telemetry. For headset builds, VR game testing also checks frame stability, comfort risks, controller tracking, and headset-specific behaviour. The mix is project-specific.
How long the video game testing stages typically take
Timing depends on scope and engagement model. As a rough benchmark for mid-sized projects:
- Pre-alpha: 2–4 weeks of focused QA support after the first integrated build.
- Alpha: 6–12 weeks for a feature-complete cycle on a mid-sized project.
- Beta (closed and open combined): 4–10 weeks before the release candidate gate.
- Release candidate to gold master: 2–6 weeks, longer on console with certification cycles.
- Live ops regression per patch: 3–10 days depending on patch scope.
Mobile projects compress alpha and beta into a tighter window because the soft-launch window itself acts as a long live-fire beta. Console projects stretch the release candidate phase because of platform certification iterations. Game-Ace plans test cycles against the project calendar before alpha begins, not after.
Game-Ace project involving game QA
Cricket Manager, a mobile sports MMO developed by Game-Ace
Cricket Manager is a mobile sports MMO developed full-cycle by Game-Ace. The project team included two QA specialists and worked on stable mobile performance, server-side processing, and social features for players worldwide.
Talk to Game-Ace about your QA cycle
If you are scoping a QA cycle for a new build, a regression pass on a live game, or co-development on test automation with your in-house team, talk to Game-Ace.
When to talk to Game-Ace about video game testing
Game-Ace runs video game testing stages for partner studios under Team Extension, Co-development, and Full-cycle delivery. Engagements cover test planning against the GDD, alpha and beta execution, automation in Unity Test Framework and Unreal automation, device-matrix compatibility, localisation QA, certification prep, and live ops regression. Since 2005, the team has shipped 200+ projects with 120+ in-house specialists, including dedicated QA engineers. If video game testing is part of your roadmap, the Game-Ace game development studio handles QA cycles as a stand-alone engagement or as part of a wider production scope.
Mobile Game Testing: Types, Tools, and More 
Understanding the Role of QA Game Testers in Game Development Projects 
Game QA Companies: What Is Their Role and How to Choose the Best? 
Android Game Testing: Things to Keep in Mind and Check 
What Are the Main Types of Game Testing? Your Questions Answered 
