game-qa
14 articles
-
Game Balance Breaks Through Numbers, Not Bugs: Catching Exploits with a Simulator
A tester beat my idle game to wave 199 in one evening, even though everything 'worked'. A first-person breakdown: why balance can't be tested by hand, how to write a player simulator, a stress test for a maxed-out build, and the four holes it found. With a QA checklist.
-
Multiplayer in a Mobile Game: Testing Network, Lag and Reconnect Without a Hundred Players
Multiplayer doesn't break in game logic, it breaks at the seams: latency, packet loss, desync, a dropped connection mid-match. We cover how game networking works, which bug classes it produces, and how one tester with two phones can reproduce all of it. With a reconnect matrix and a checklist.
-
Testing Mobile App Interruptions and Lifecycle
A mobile app never runs in a vacuum — the OS interrupts at any moment, and that's where the bugs hide. Interruptions (calls, push, notification shade, split-screen), lifecycle and background process kill, rotation, network drops, low-memory kill and battery saver, revoked permissions. A checklist and how to reproduce it all.
-
How to Test a Mobile Game's Economy and Catch Cheaters
A game's economy is the prime target: every cheat hits revenue directly. A first-person take: why you can't trust the client (server authority), duplication bugs and purchase idempotency, device-clock manipulation, save-file editing, negative balance and overflow, fake IAP receipts, and cheat tools. With a checklist of attacks QA must run.
-
Interruption Testing in a Mobile Game: A Call, a Backgrounded App, and a Lost Session
The player is on the deciding move — then a call comes in. They return, and the progress is gone, the audio is silent, the rewarded-ad reward never arrived. A first-person take: the catalog of interruptions (call, push, backgrounding, lock, ad, headphones, split-screen), what actually breaks on resume, iOS vs Android differences, how to reproduce each case, and a checklist.
-
Real-Device Testing: How to Build a Device Matrix and Why Your Phone Lies
Everything ran fine on my Pixel — the reviews said "crashes on launch." Real bugs don't live on your device. A first-person take: why one or two phones lie; how to build a matrix along risk axes (OS, hardware class, vendor/skin, screen, locale) from your own analytics; real devices vs emulators vs cloud farms; what to test specifically on varied hardware (OOM, thermals, vendor process-killing, safe-area, update-over-install).
-
LiveOps events — releases without App Review that get the least testing
A live game runs on events: battle passes, tournaments and sales ship via server config with no release and no store review — straight to production, on top of any client version. A first-person take: window boundaries and timezones (UTC+13 and UTC-11), clock manipulation as the main cheat, config landing on old clients, claiming rewards exactly once, "a misplaced comma = top-tier sword for 1 coin", time travel on staging as a must-have, the kill switch, and an event launch checklist.
-
Update testing — the bugs only users on old versions ever see
The release was tested perfectly — on a clean install. But almost every user gets it as an update on top of an old version with old data. A first-person take: why an update means new code reading old data, the N-5 → N version matrix and migration chains, updates landing mid-session, force update and its bypasses, staged rollout and a server that must support two versions at once, downgrade as a crash loop, first launch after an update ≠ FTUE — and why an archive of old builds must exist.
-
Crashes and ANRs in a mobile game: catching what won't reproduce for you
Crashes almost never happen on your device — they live on other people's, where memory is tight and the network drops. A first-person walkthrough: why you should test the crash reporter itself first (a real case where Crashlytics initialized after the crash and the exception handler was grabbed by the ad SDK), how a crash differs from an ANR, why you need symbolication and context in the report, managed vs native crashes in Unity, and how to deliberately recreate other people's conditions.
-
Testing runtime permissions in a mobile app: states, on-the-fly revocation, and edge cases
Permissions aren't 'granted or not' — they're a state matrix. A five-state model, pre-permission priming, graceful fallback on denial, process death on on-the-fly revocation, background and precise/approximate location, ATT and limited Photos on iOS, 'Don't ask again' on Android, verifying via Proxyman traffic, and a 12-point checklist.
-
AI bots that play your game: game-QA automation in 2026
AI agents for game testing: how they differ from scripted automation, what they actually do (24/7 exploratory play, crashes, balance, video logs), the limits and risks, who's on the market (modl.ai, AltTester, GameDriver), when to use AI bots and when plain automation is enough. A pilot checklist.
-
FTUE / onboarding in a mobile game: what to test in the first session
The first session (FTUE) through a QA lens: the matrix of entry points (install/reinstall/deep link/login), tutorial interruptions, skip and mandatory steps, returning player and updates, idempotent reward, A/B and funnel analytics. A 12-point checklist.
-
Testing deep links: deep links, Universal Links, App Links and the state matrix
Deep links through a QA lens: three link types, the state matrix (foreground/background/killed/not installed), deferred deep linking and attribution, fallbacks and broken links, security, AASA/assetlinks verification, tools adb/simctl/Proxyman. A 12-point checklist.
-
Testing ads in a mobile game: rewarded, interstitial, mediation and edge cases
Ad monetization through a QA lens: how to test rewarded and interstitial ads, reward idempotency (SSV), no-fill, mediation and waterfall, frequency capping, ATT/GDPR consent, network and analytics. A 13-point checklist.