mobile
14 articles
-
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.
-
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.
-
Android fragmentation for a mobile game — what MIUI, One UI, EMUI, and Oppo/Vivo battery savers break
«Works on Pixel, crashes on Xiaomi, different bugs on Samsung, no Google Play on Huawei.» Complete 2026 fragmentation guide: 6 OEMs with their quirks, what breaks in games, the minimum QA lab, a checklist, and bug-report format.
-
Accessibility checklist for a mobile app in 2026
On 28 June 2025 the EU's European Accessibility Act came into force — for b2c apps a11y is now a legal requirement. 11 sections of a QA checklist: VoiceOver/TalkBack, Dynamic Type, contrast, touch targets, semantics, automation.
-
Cloud Save in a mobile game — a testing checklist
A player finished 30 levels on iPad, opens iPhone — progress is gone. The most reputation-expensive part of a mobile game. 9 sections and a QA checklist for cloud save: APIs, conflicts, cross-platform, corruption, recovery.
-
Testing on a bad network — 8 scenarios and tools
Most QA checklists cover only «internet works» and «Airplane mode». Real users live between those. 8 network-degradation scenarios with tools and acceptance tests.