Mobile Game Testing: Devices, Crashes and Release Checks

Passing every level does not exercise a lost connection during a purchase. Mobile game testing needs to cover the transitions around play: installation, sign-in, backgrounding, saving, updating and recovery. These are often where a correct game mechanic meets an unreliable device or service.

The aim of a QA plan is to produce evidence for a release decision. “Tested on Android and iOS” says little unless the report identifies the devices, build, scenarios and unresolved defects.

Start with the minimum supported hardware and system versions, then add devices that expose different risks: limited memory, a different graphics processor, a high-refresh-rate screen or an unusual aspect ratio. Include real iPhones and Android devices. Simulators and emulators are useful for repeatable functional work but do not reproduce every thermal, GPU or input behaviour.

Prioritise coverage using actual audience and incident data as those become available. A large device list without a reason for each selection can consume testing time while missing a vulnerable older model.

An illustrative matrix of 6 device configurations, 4 network conditions, 3 account states and 2 installation paths contains 144 combinations. If each takes 8 minutes, one complete pass needs 1,152 minutes, or 19.2 hours, before retesting defects.

This calculation helps budget work; it does not prescribe a universal matrix. Use risk-based selection and pairwise coverage where suitable, while retaining full end-to-end cases for high-impact flows. Account creation, paid-item delivery, save migration and account deletion need explicit scenarios even if a combination generator would omit them.

A smoke test answers whether the build is usable enough for further testing. It should include launching, starting a level, completing an action, saving and reopening. Keep this pass short enough to run on every candidate build.

Regression testing checks whether changes broke established behaviour. A change to a shared inventory service should trigger tests for rewards, purchases, spending and save loading, even if the visible change affects only one screen. Identify the dependency rather than retesting unrelated menus by habit.

An endurance test follows repeated play and transitions over time. For a project's sample plan, repeat a 30-minute route with level changes and background-resume cycles. Record memory, thermal state, frame-time spikes and crashes. The duration is a team-selected test condition, not an operating-system requirement.

A disconnected client does not prove the server rejected an operation. In the lost-response case, the server may have committed it. The test must inspect the authoritative result and confirm that a retry does not duplicate an item or charge the player twice inside the game economy.

A crash terminates the process; an Android Application Not Responding event indicates unresponsiveness under defined conditions. Google's documentation describes an input-dispatch timeout when an app fails to respond to an input event within five seconds. That number is not a safe time budget for ordinary UI work: delays far shorter than five seconds can already make play unpleasant.

Keep long disk access and network waits away from the UI thread. If a deadlock occurs, moving one operation to a background thread may not fix the ownership problem. Capture thread stacks and determine which resource each thread is waiting for.

Xcode provides Address Sanitizer for memory-access problems and Thread Sanitizer for data races, alongside other diagnostics. Check the supported runtime: Thread Sanitizer for iOS is used in Simulator, not on an iPhone. Sanitizer-enabled runs are diagnostic experiments; their overhead makes them unsuitable as direct release-performance benchmarks.

Preserve the matching debug symbols and build identifiers needed to interpret native crash stacks. Group failures by a stable signature and affected version. A thousand copies of one crash require a different response from a thousand unrelated failures.

A useful report includes the build identifier, device, system version, starting state, steps, expected result, observed result and reproduction frequency. Add a short video or log excerpt where it explains the issue. Remove access tokens and unnecessary personal data before sharing diagnostic material.

For example: “On build 204, starting from save revision 17, disconnect after tapping Continue, reconnect and tap again. The reward appears twice in 3 of 5 runs.” This gives an engineer a concrete state and a concurrency clue. “Rewards broken sometimes” does neither.

Run a level with sound disabled and check that its essential instructions still make sense. Inspect colour-coded teams or puzzle pieces using the alternative symbols the game provides. A colour filter alone cannot establish that a puzzle remains playable; someone must complete the task using the available cues.

Test longer translations, right-to-left layout where supported, subtitles and the largest text option the game exposes. Enter unusual but permitted account names and check result screens, leaderboards and support forms. A label that fits the menu can still overlap another element during a reward animation.

Include interrupted input: drag an object beyond its target, release outside the screen region and switch apps while a button is held. Check that returning to play does not preserve a stuck movement command. If controllers are supported, disconnect and reconnect one during a session and verify the visible prompts match the active input method.

Apple currently allows up to 100 internal TestFlight testers and up to 10,000 external testers. A TestFlight build can be tested for up to 90 days. External testing involves a review process, so include time for that step rather than treating upload as immediate distribution.

Assign testers specific work, such as migrating an old save or using a tablet with large text settings. Track which build they actually installed. Broad feedback about whether the game is enjoyable helps game design, but it does not replace a pass/fail record for purchase delivery.

Define which defects block release before reviewing the final candidate. A reproducible account takeover, lost paid entitlement or destructive migration should not be hidden inside a favourable overall crash rate. Assign ownership and a verification step for every accepted limitation.

For a clearly defined example, 10 sessions containing a crash out of 2,000 total sessions produces a 0.5% crash-affected session rate and a 99.5% crash-free session rate. Counting raw crash events instead gives a different metric when one session crashes repeatedly. Do not mix session-based and user-based rates in a trend.

Watch release metrics by build, device group and cohort. A small rollout can miss a rare failure, especially before enough users exercise the affected flow. Stopping distribution does not remove a bad build already installed, so prepare server compatibility, feature controls and a corrective release as appropriate to the problem.