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:
- What happens at zero, at maximum, and one past maximum of any counter
- Every screen entered and left by every available route, including back
- Every action performed twice, quickly
- Every input during a transition or animation
- Suspend and resume at each distinct state
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.
This is what we do day to day — game, app and website QA at Factorial Studio.