← Back to sample work
Mobile App QA Flow DocumentationProduct / QA

Standard documentation sample

Mobile App QA Flow Documentation

Document ID
002
Owner
Affordable Digital Solutions (ADS)
Effective date
May 19, 2026

1. Purpose

This document defines how the QA team validates the mobile application before each release. It gives testers a repeatable set of flows, expected results and severity definitions so that two different testers reach the same verdict on the same build.

2. Scope

Applies to the iOS and Android consumer apps for every scheduled release and hotfix. It covers manual regression testing of critical user flows, bug reporting and release sign-off.

Not covered: load testing, penetration testing and backend API contract testing.

3. Test environment

ItemValue
Build sourceTestFlight (iOS) / Internal testing track (Android)
EnvironmentStaging, seeded with the QA test account set
Reference devicesiPhone 13 (iOS 17), Pixel 6 (Android 14), one low-end Android device
Network conditionsWi-Fi, 4G and throttled 3G for the checkout and upload flows

4. Severity definitions

SeverityDefinitionRelease impact
S1 — BlockerCore flow cannot be completed; app crashes on launch; data loss.Release is blocked.
S2 — MajorCore flow completes only with a workaround; incorrect data displayed.Release blocked unless product owner signs a written exception.
S3 — MinorNon-core feature broken; layout issue that does not prevent the task.Ship and schedule for the next sprint.
S4 — CosmeticCopy, spacing or icon inconsistencies.Ship; log to the backlog.

5. Critical flow test cases

TC-01 — New user registration

Precondition: App freshly installed; no cached session; test email unused.

  1. Launch the app and tap Create account.
  2. Enter a valid email and a password that meets the stated policy.
  3. Submit the form and retrieve the verification code from the QA mailbox.
  4. Enter the code and complete the profile step.

Expected result: Account is created, the verification code is accepted on the first attempt, and the user lands on the home screen with their display name shown.

TC-02 — Sign in and session persistence

Precondition: Verified account exists; app installed.

  1. Sign in with valid credentials.
  2. Force-quit the app and relaunch it.
  3. Toggle airplane mode on, relaunch, then toggle it off.

Expected result: Session persists across relaunch, offline launch shows the cached home screen with an offline banner, and content refreshes when connectivity returns.

TC-03 — Checkout and payment

Precondition: Signed-in account with a saved address; sandbox card details available.

  1. Add two items to the cart and open the cart screen.
  2. Change the quantity of one item and confirm the total recalculates.
  3. Proceed to checkout and pay with the sandbox card.
  4. Repeat the payment step with the declined-card test number.

Expected result: Totals are correct at every step, a successful payment produces an order confirmation with an order ID, and a declined payment shows an actionable error without clearing the cart.

[ Screenshot placeholder ]
Figure 1. Order confirmation screen. Order ID, total and delivery estimate must all be present.

Tester note

Run TC-03 on throttled 3G at least once per release. Double-charge and duplicate-order bugs surface almost exclusively on slow connections.

TC-04 — Push notification deep link

  1. Trigger an order-update push from the QA console.
  2. Tap the notification with the app closed, then repeat with the app backgrounded.

Expected result: Both taps open the matching order detail screen, not the home screen.

6. Bug report template

FieldWhat to enter
Title[Platform] Short description of the observed behaviour
Build / versionVersion number and build number exactly as shown in Settings → About
Device / OSDevice model and OS version
Steps to reproduceNumbered steps starting from app launch
Expected vs actualOne sentence each
SeverityS1–S4 using the definitions in section 4
EvidenceScreen recording or screenshot, plus console log if available

7. Release sign-off checklist

  • All S1 and S2 defects closed or formally waived
  • Full regression suite executed on both reference devices
  • Checkout flow tested on throttled 3G
  • Push deep links verified from closed and backgrounded states
  • Crash-free session rate on the staging build above 99.5%
  • Release notes reviewed by product owner
  • Sign-off recorded with tester name, build number and date

8. Revision history

VersionDateSummary of changes
1.02026-02-11Initial QA flow documentation published.
1.22026-05-19Added severity matrix, throttled-network requirement and sign-off checklist.

Document ID: 002 · Sample prepared for portfolio review. Client names and figures are anonymised.