Game QA
Why game studios need AI QA
Put repeatable gameplay checks to work on each build, turn failures into evidence, and give your team more room for the decisions that need a player.
A studio ships a new build. Before the team can assess the new feature, someone needs to check that the tutorial still completes, progress still saves, and existing rewards still arrive. And the same questions come back with the next build — even when the people who'd answer them are needed somewhere else.
That repeated work is where AI QA earns its keep. Give a worker a defined journey, an expected result, and a run limit — it executes the check and hands back enough evidence for your team to decide what happened.
Choose work worth repeating
Start with a small set of journeys your team already relies on. For example: a new account can finish onboarding, a completed level unlocks the next one, or a settings change persists after a restart. State the starting conditions and the observable result for each check.
A recurring check only earns its place if someone actually uses the answer. Tie it to a build review or a release decision, and rerun it when the behavior it covers might have changed. A pile of runs nobody looks at is just another queue on your team's day.
Play the build the team needs to review
A gameplay journey moves through screens, inputs, state changes, and saved data. Testing it means actually playing the running game and watching what happens — not just checking the code behind it.
Take a tutorial where the Continue button ends up hidden behind another panel. A check on the button's underlying code could still pass — even though a real player can't reach it. Only playing through the interface catches that.
Keep every result tied to the exact build, device, and starting state you tested. A pass on one configuration only answers for that configuration — your team decides which others need their own check.
Make the result easy to review
A failed run should hand the developer a starting point: what was expected, what actually happened, and the path that got there. That's the point of gameplay evidence — the reviewer can check it themselves instead of taking a conclusion on faith.
Keep a failed check separate from a run that never got that far. A launch problem, a missing test account, and a missing reward each need a different next step — blur them together and the wrong person ends up with the work.
Retest the repair
When the next build ships a proposed fix, run the same accepted check again. Compare it against the earlier failure to confirm the expected behavior actually shows up now. Keep the check on hand for later builds as long as the journey still matters.
This is where repeatable checks pay off beyond one bug report — the same accepted expectation can follow a feature through every later change, and your team updates it on purpose, only when the design itself changes.
Put BugHunter on the team's work list
BugHunter is an AI QA worker your team operates. Nodemori helps connect your game and prepare the first checks. Your team selects the builds, assigns the work, reviews findings, and requests retests.
Freeplay, to follow an open-ended objective within a run limit; Testcase, to run approved steps against an expectation; Regression, to repeat accepted checks on a later build; Scout, to look at a selected area and draft candidate checks. Task availability depends on the game and build.
Pick the task based on the question you're asking. Exploring a new area turns up observations worth investigating. Repeating an approved testcase tells you whether a specific behavior meets the bar. Both are useful — you just judge them differently.
Keep the player in the decision
A test can confirm a tutorial reaches its final screen. Whether it actually teaches well, respects the player's attention, or makes the next step appealing — that's still a call for people who know the game and own its design.
AI QA lets you delegate the defined, repeatable execution and look at what comes back. You still set the expectations, accept the findings, and decide when a build is ready for players.