# 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.