AppReviewX Log in

Mobile app test plan template

A one-page plan: scope, risks, devices, test types, schedule and exit criteria.

In this guide

A test plan is a decision written down: what you test, what you skip, on what, by when, and when you stop. For a small app it fits on one page. Copy the block, fill every field, delete what does not apply.

Template (copy and paste)

TEST PLAN: <app name> <version>
Owner: <name>            Date: <date>

1. GOAL
   What must be true for this release? (one or two sentences)

2. SCOPE
   In scope:     <features, flows, platforms>
   Out of scope: <what you will not test, and why>

3. TOP RISKS (what hurts most if it breaks)
   1. <risk>  -> covered by: <test type>
   2. <risk>  -> covered by: <test type>
   3. <risk>  -> covered by: <test type>

4. DEVICES AND OS
   <device / OS version / why it is on the list>
   <device / OS version / why it is on the list>

5. TEST TYPES
   [ ] Smoke test on every build
   [ ] Core flow tests (sign-up, main task, payment if any)
   [ ] Regression list
   [ ] Exploratory sessions (who, how long)
   [ ] Interruptions, offline, permissions
   [ ] Accessibility basics
   [ ] Text and translation pass

6. TESTERS
   <who, how many, what they get, how they report>

7. SCHEDULE
   Build ready: <date>    Testing: <from - to>    Fixes: <until>    Decision: <date>

8. BUG HANDLING
   Where bugs are logged: <place>
   Severity scale: <link or short definition>

9. EXIT CRITERIA (when testing is done)
   - No open bug of severity <level> or higher
   - All core flows pass on <devices>
   - <your own condition>

10. DECISION
    Go / No-go: <decision>   Reason: <short>

Example (illustrative, not a real project)

TEST PLAN: Example Habit Tracker 1.4
Owner: Sam           Date: 2026-11-02

1. GOAL
   Reminders fire reliably and existing user data survives the update.

2. SCOPE
   In scope:     reminders, habit list, backup/restore, Android 12-15
   Out of scope: tablet layout (not supported), widget (unchanged)

3. TOP RISKS
   1. Reminders do not fire after reboot -> covered by: exploratory + reboot test
   2. Data lost on update               -> covered by: update test from 1.3
   3. Crash on first launch             -> covered by: smoke test

4. DEVICES AND OS
   Mid-range phone / Android 13 / most common in our users
   Older phone / Android 10 / lowest supported version

...
9. EXIT CRITERIA
   - No open crash or data-loss bug
   - Smoke test and reminder flow pass on both devices

How to adapt it

  • Solo developer: keep sections 1, 3, 4, 9. Fill the rest in one line each.
  • Sharing a build with outside testers: add what you want them to try in section 6, and see the test report template for the write-up afterwards.
  • Choose devices by risk, not by count. Pick the oldest supported OS, a common mid-range device and one small screen. Use only information you actually have about your users.
  • Updates to a live app: add an update-from-last-version test. See how to test an update to a live app.
  • Google Play closed test: plan the tester group and its duration against the current Google Play requirement. At the time of checking, Play Console Help says personal developer accounts created after November 13, 2023 need at least 12 testers opted in continuously for the preceding 14 days before applying for production access; read the current page for your account. See closed testing with 12 testers.
  • Exit criteria must be checkable. "Feels stable" is not one.

Need testers and a structured way to collect their findings? Get started on AppReviewX.