Release Testing on Pawn to Don
Owning full release-candidate validation on a shipped mobile RPG (1M+ downloads), and tracing an elusive bug with nothing in the logs back to its architectural cause.
QA / Release Testing (Embedded)
Funcell Games · Pawn to Don
Unity · Android Mobile
1M+ DLs, 4.4★ (21.2K ratings)
Oct 2024 – Nov 2025
RC Sign-Off, CI/CD, Profiling
1M+ DLs
4.4★ across 21.2k reviews3 Tiers
Low-end to high-end Android0 Blockers
Zero crashes, clean analyticsSave Library
Instant branch regressionContext & Complexity
Pawn to Don is a 30-day branching narrative crime RPG: the player has 30 in-game days and a $100,000 target, with choices splitting between a legal grind and criminal operations.
That branching structure is exactly what makes a game difficult to test properly. There is no single “the game” — there are dozens of paths through it, and a bug three choices deep down one branch can be invisible on every other path.
Being embedded in development at Funcell rather than sitting in a siloed QA function meant owning release-candidate validation end to end: performance, functional, and regression passes, analytics and content-delivery verification, and go/no-go sign-off before every Google Play Store submission.
The Release Validation Process
Every release candidate received a structured validation pass prior to Play Store submission: roughly 45 minutes to 1 hour 45 minutes per pass, executed across 3 device tiers spanning low-end to high-end Android hardware.
1. Device & Platform Checks
Startup time across device range, frame rate consistency against a 30fps floor, and screen orientation flips (portrait/landscape testing to detect UI layout ruptures).
2. UI & Settings Persistence
Element positioning, visibility, and interactivity across menus; confirming volume sliders, audio mute, and custom toggles persisted cleanly between cold restarts.
3. Gameplay Play-Throughs
Full play-throughs capturing gameplay regressions, level loading/unloading integrity, rendering artifacts, and visual anomalies.
4. Technical & Addressables
Validating analytics event dispatches and ensuring server-hosted Addressables/DLC loaded and unpacked seamlessly without corrupted assets.
The Sign-Off Bar & Retest Discipline
Sign-off bar: Zero crashes, zero progression blockers, verified analytics events. Minor cosmetic issues were permitted as known issues for the subsequent patch.
No spot-checks: If a build failed any validation gate, it returned to engineering and was retested with a full pass rather than an isolated spot-check, preventing regression side effects.
Efficiency Innovation: Full replays of a 30-day branching narrative to test a single fix are prohibitively expensive. Built a library of save files at key narrative nodes, enabling regression passes to jump directly into affected story branches in minutes.
Bug Tracking & Regression Strategy
Bugs were tracked in Jira with severity and priority logged separately. A bug that is severe (substantially breaks mechanics) isn't necessarily urgent (blocking the current milestone), and combining them into one field destroys critical triage nuance.
Every filed report included detailed reproduction steps, build numbers, platform specifications, and an attached save file or video capture.
Triage & Lifecycle Protocol:
- Bi-Weekly Engineering Triage: Reviewed open tickets directly with developers twice a week, re-aligning priorities against current milestone goals.
- Verification Loop: Tickets flowed through
In Progress → Blocked → Testing → Complete. Any ticket landing in Testing returned to QA to verify against the next clean build before closure. - Prioritized Verification: Each new build received a start-to-finish pass for crashes and blockers first, followed by a targeted pass down priority tiers.
Investigation: The Bug with Nothing in the Logs
The report was simple and unhelpful: the game would sometimes just stop. Not a crash. Not a black screen. It rendered cleanly, accepted input, but refused to advance. No unhandled exception. No Android ANR dialog. Logcat was completely clean.
How the Cause Was Isolated:
- Analytics Breadcrumbs: Developers fired analytics through the same internal event system driving game progression. Used this stream as a breadcrumb trail: played until the lockup occurred, then checked exactly where the event stream stopped. This gave a precise frame and state in the cutscene sequence.
- Profiler & FPS Overlay Correlation: Re-ran the sequence with the Unity Profiler and in-build FPS overlay active. Every lockup correlated with an acute frame spike during a heavy cinematic animation.
- Unmasking Dropped Animation Events: Dialogue was synced to the cinematic animation, and animation events drove both state transitions and analytics. When the frame spike hit, the engine dropped the animation event. Because that event was the sole trigger telling the game to advance, a dropped event left the game waiting forever on a callback that never arrived. Nothing had errored — it was idling in a state with nowhere to go.
Differentiating Symptom vs. Underlying Architectural Fragility
Optimizing the cinematic animation eliminated the frame spike and resolved the immediate symptom. However, I flagged to the lead engineer that this was not a true fix: it removed the trigger, not the fragility.
The critical path still advanced exclusively on animation events with zero timeout fallback. Any device slow enough to drop a frame would trigger the exact same soft-lock. In a live user base of over 1 million devices, that failure was guaranteed to occur.
“Finding the bug is table stakes for QA. Recognizing that the fix addressed a symptom rather than the underlying fragility, and being able to say precisely why, is the difference between ‘found a bug’ and understanding a system well enough to know when a fix is incomplete.”
Backend & Content Verification
QA extended beyond the local client into end-to-end telemetry and server pipelines:
- End-to-End Analytics: Confirmed telemetry events dispatched from the client via Android logcat, and corroborated on the backend server that events landed with valid user IDs, timestamps, and parameters.
- Addressables & DLC Delivery: Tested server-hosted downloadable content packages across the device range, verifying hash validation, download retry loops, and asset unpacking.
- Network Resilience: Emulated packet loss, flaky cellular connections, and abrupt disconnects using Charles Proxy to verify automatic reconnection and save preservation.
- Battery & Thermal Profiling: Monitored power drain and CPU throttling on Android using dumpsys and Battery Historian.
Outcome & Live Impact
Pawn to Don shipped on Google Play and successfully crossed 1M+ downloads with a 4.4★ average rating across 21,200+ player reviews.
In a branching narrative game deployed to a massive live audience, unresolved soft-locks or regression failures surface immediately in reviews and churn. Rigorous release candidate validation and root-cause engineering ensured stability at scale.
1M+ Shipped
4.4★ (21.2k)
0 Critical ANRs
Moses Kamau Mbugua
QA Engineer (PC & VR) · 8 Years Testing · 10 Years Engineering