Factorial Studio›Blog›Game QA
Game QA

How to Test a Game You Did Not Build

You have a build, no documentation, and nobody to ask. That is the normal case, not the hard one.

By Muhammad Qasim·

External QA almost always begins here. The instinct is to start playing. The better first hour is spent mapping instead, because an unmapped game produces findings that cluster in the first ten minutes and miss everything after.

Map before you test

Play once, deliberately, writing down every screen, every state and every transition. You are building a list of places, not looking for bugs yet. Note what the game appears to want you to do, and what it allows you to do instead — the gap between those two is where most defects live.

Find the boundaries

Without source access, probe for edges:

Most defects in a finished build are at boundaries and in transitions, not in the main path. The main path is what the developers tested.

Report so it is actionable without you

You will not be in the room when someone reads your report, and you cannot explain it. Numbered steps from a known state, a severity you can defend, the build and device on every finding. The full shape is in what a usable bug report contains.

The short version Spend the first hour mapping, then attack boundaries and transitions. The main path has already been tested by the people who built it.

This is what we do day to day — game, app and website QA at Factorial Studio.

Muhammad Qasim
Muhammad Qasim
Founder & CEO, Factorial Studio

Runs Factorial Studio in Lahore — game QA, WebGL porting, console certification and playable ads. Has shipped and tested games on Unity and Unreal for studios in eight countries.

Got a build that needs this kind of attention?

QA, WebGL porting, console certification and playable ads — send us the build and we will tell you what we find.

Start a project →