How to test a mobile game

01Direct answer

02What counts as a mobile game

A mobile game here is a free-to-play or paid iOS and Android game with in-app purchases of currency, items or passes, live services such as matchmaking and events, and players who may be children. It covers purchase confirmation, server-side inventory, loot box odds, chat defaults, parental consent and backend capacity at launches and events. Console and PC releases of the same game and real-money gambling apps are out of scope.

Adjacent product types not covered here

• kids app: A kids app is built for children with no matchmaking or live events, so ad SDK certification and parental gates lead instead of launch-day load.
• social network: A social network ranks posts in a feed and sells no in-game currency, so self-harm content and public-by-default profiles replace accidental purchases and loot box odds.
• messaging app: A messaging app carries chats between known contacts, so address book notices and reconnect storms replace chat with strangers matched into a squad.

03Risk map

04Mandatory tests (8)

1. 1

   Step 1: release smoke tests

   Why:store-rejection

   Done when: On the release build, a new player completes the tutorial, buys one item with a sandbox account and finds it in the inventory after a restart, and the loot box screen shows item odds before the buy button.

   Tool class: mobile automation. Who usually runs it: QA engineer.

2. 2

   Step 2: end-to-end functional tests

   Why:user-harmregulatory-penalty

   Done when: A new account set to under 13 starts with voice and text chat off, and only a verified parent can turn them on.

   Tool class: mobile automation. Who usually runs it: QA engineer.

3. 3

   Step 3: exploratory testing

   Why:money-lossuser-harm

   Done when: A tester acting as a child tries to buy currency and chat with strangers, and each attempt stops at a parental gate.

   Tool class: test management. Who usually runs it: QA engineer.

4. 4

   Step 4: data integrity and migration testing

   Why:money-loss

   Done when: For a sample of sandbox purchases, every charge in the store's purchase records matches a purchase the player confirmed in the game, and each purchased item appears in the player's inventory once.

   Tool class: data validation. Who usually runs it: developer.

5. 5

   Step 5: payment and money-flow testing

   Why:money-loss

   Done when: No sandbox purchase can start from a loading screen, sleep wake or item preview, and every purchase asks for a confirmation that names the item and price.

   Tool class: mobile automation. Who usually runs it: QA engineer.

6. 6

   Step 6: compliance checks

   Why:regulatory-penaltystore-rejection

   Done when: A reviewer confirms each loot box shows item odds before purchase, and a player under 13 cannot reach chat or purchases without a parent's consent.

   Tool class: test management. Who usually runs it: product manager.

7. 7

   Step 7: performance and load testing

   Why:outage-under-load

   Done when: A load test at the launch or event forecast plus the margin the team set keeps login and match start within the team's target.

   Tool class: load generator. Who usually runs it: developer.

8. 8

   Step 8: resilience and failure testing

   Why:outage-under-load

   Done when: When the service-discovery cluster or session store degrades, players see a queue screen and keep their inventory and progress after recovery.

   Tool class: chaos tool. Who usually runs it: developer.

05Recommended and optional tests

• unit testsrecommended

  Becomes mandatory when drop rates, rewards or pricing rules change.

• regression suiterecommended

  Becomes mandatory when live content ships between client releases.

• penetration testingrecommended

  Becomes mandatory when currency or items can be traded between players.

• device and browser compatibilityrecommended

  Becomes mandatory when crash reports concentrate on low-memory devices.

• analytics and event tracking testsrecommended

  Becomes mandatory when an ad or attribution SDK is added to a build rated for children.

• accessibility testingoptional

  May help when players report that menus or subtitles cannot be read.

• localization testingoptional

  May help when the game launches in markets with another language.

• offline and poor-network testingoptional

  May help when matches are played on mobile networks that drop mid-session.

06Not needed and why

• contract tests

  Not needed: one team owns client and server. Becomes recommended when a separate team or partner ships against the game API.

• usability testing

  Not needed: purchase confirmation and chat defaults are checked by the payment, compliance and end-to-end items. Becomes recommended when tutorial drop-off is high.

• security scanning

  Not needed: payments and accounts stay with the store. Becomes recommended when the game stores payment details or player accounts outside the store.

07Order of work

08Tools

Listed alphabetically inside each test type, filtered to the tests above and to the platforms of mobile game (ios, android). Not recommendations.

09What to send to the person who will test

Send the checklist and the brief below. The printable checklist for mobile game has the same 8 items with checkboxes.

Download the checklistMarkdownCSVBrief (Markdown)

Acceptance criteria wording

A release of the mobile game is accepted when a new player completes the tutorial, buys an item in the sandbox and keeps it after a restart, and no purchase starts from a loading screen, sleep wake or item preview without a confirmation naming the item and price. A new account set to under 13 starts with voice and text chat off, and each loot box shows its odds before the buy button. A load test at the event forecast keeps login and match start within the team's target, and every store charge in a sample matches a purchase the player confirmed.

Brief

# Test brief: mobile game

Product type: mobile game. A free-to-play or paid game with in-app purchases and live services.
Risk map and evidence: https://howtotestaproduct.com/how-to-test/mobile-game/
Printable checklist: https://howtotestaproduct.com/checklists/mobile-game/

Run these 8 mandatory tests in this order. A test is done only when its done condition is true on the build you will release.

1. release smoke tests (risks: store-rejection). Tool class: mobile automation. Usually run by: QA engineer.
   Done when: On the release build, a new player completes the tutorial, buys one item with a sandbox account and finds it in the inventory after a restart, and the loot box screen shows item odds before the buy button.
2. end-to-end functional tests (risks: user-harm, regulatory-penalty). Tool class: mobile automation. Usually run by: QA engineer.
   Done when: A new account set to under 13 starts with voice and text chat off, and only a verified parent can turn them on.
3. exploratory testing (risks: money-loss, user-harm). Tool class: test management. Usually run by: QA engineer.
   Done when: A tester acting as a child tries to buy currency and chat with strangers, and each attempt stops at a parental gate.
4. data integrity and migration testing (risks: money-loss). Tool class: data validation. Usually run by: developer.
   Done when: For a sample of sandbox purchases, every charge in the store's purchase records matches a purchase the player confirmed in the game, and each purchased item appears in the player's inventory once.
5. payment and money-flow testing (risks: money-loss). Tool class: mobile automation. Usually run by: QA engineer.
   Done when: No sandbox purchase can start from a loading screen, sleep wake or item preview, and every purchase asks for a confirmation that names the item and price.
6. compliance checks (risks: regulatory-penalty, store-rejection). Tool class: test management. Usually run by: product manager.
   Done when: A reviewer confirms each loot box shows item odds before purchase, and a player under 13 cannot reach chat or purchases without a parent's consent.
7. performance and load testing (risks: outage-under-load). Tool class: load generator. Usually run by: developer.
   Done when: A load test at the launch or event forecast plus the margin the team set keeps login and match start within the team's target.
8. resilience and failure testing (risks: outage-under-load). Tool class: chaos tool. Usually run by: developer.
   Done when: When the service-discovery cluster or session store degrades, players see a queue screen and keep their inventory and progress after recovery.

Acceptance criteria wording:
A release of the mobile game is accepted when a new player completes the tutorial, buys an item in the sandbox and keeps it after a restart, and no purchase starts from a loading screen, sleep wake or item preview without a confirmation naming the item and price. A new account set to under 13 starts with voice and text chat off, and each loot box shows its odds before the buy button. A load test at the event forecast keeps login and match start within the team's target, and every store charge in a sample matches a purchase the player confirmed.

Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file).

Licence: CC BY 4.0.

For founders: what to forward and what to ask back. For product managers: turning this page into tickets.

10Questions about testing a mobile game

11Evidence

1. ev-0263court-or-fineprimary

   Fortnite Video Game Maker Epic Games to Pay More Than Half a Billion Dollars over FTC Allegations of Privacy Violations and Unwanted Charges, Federal Trade Commission

   Children and teens have been bullied, threatened, harassed, and exposed to dangerous and psychologically traumatizing issues such as suicide while on Fortnite.

   Supports user-harm for a kids app with chat or multiplayer: the FTC tied harm to children to voice and text chat being on by default, tied unwanted charges to confusing purchase buttons, including purchases triggered when waking the game from sleep, on a loading screen or while previewing an item, and found personal information collected from children under 13 without notifying parents or getting their consent.

   published 2022-12-19 · verified 2026-10-07

2. ev-0290court-or-fineprimary

   In the Matter of Apple Inc., Federal Trade Commission

   Supports money-loss for a mobile game: the case concerns children's in-app purchases in games billed to parents without their consent.

   published 2014-01-15 · verified 2026-10-07

3. ev-0024regulatorprimary

   Children's Online Privacy Protection Rule (COPPA), U.S. Federal Trade Commission

   COPPA requires verifiable parental consent before collecting personal information from children under 13 on sites and apps directed to children or with actual knowledge.

   published undated · verified 2026-10-07

4. ev-0291post-mortemsecondary

   Bringing Pokémon GO to life on Google Cloud, Google Cloud

   Within minutes of launching in Australia and New Zealand, player traffic surged well past Niantic's expectations.

   Supports outage-under-load for a mobile game: the cloud provider's engineering write-up describes launch traffic for a location-based mobile game far above the publisher's forecast and the scaling work that followed.

   published 2016-09-30 · verified 2026-10-07

5. ev-0292post-mortemprimary

   Roblox Return to Service, Roblox

   Enabling a relatively new streaming feature on Consul under unusually high read and write load led to excessive contention and poor performance.

   Supports outage-under-load for a mobile game: the company's post-mortem shows a game platform used on phones taken down when its service-discovery cluster failed under high load.

   published 2022-01-20 · verified 2026-10-07

6. ev-0001store-guidelineprimary

   App Review Guidelines, Apple

   Apple reviews every iOS, iPadOS and macOS App Store submission against these guidelines, including crashes and bugs at review, privacy disclosures, in-app purchase rules and extra rules for medical, financial and kids apps, and apps with user-generated content must let users report offensive content and block abusive users (guideline 1.2), and apps offering loot boxes or similar mechanisms must disclose the odds of each item type before purchase (guideline 3.1.1).

   published undated · verified 2026-10-07

7. ev-0003store-guidelineprimary

   Designing apps for children and families, Google Play

   Google Play Families policy sets extra requirements (ads, data collection, SDKs) for apps whose target audience includes children.

   published undated · verified 2026-10-07

12Disclaimer

This page lists tests and risks for a product category, not for your product. Risks are attached only with the evidence shown in the Evidence section. Tools are listed alphabetically and are not recommendations. Nothing here is legal, regulatory or security advice; where a regulator or a store sets a requirement, their page is linked and takes precedence.