Mobile App Test Scenarios

How to use this catalogue

Each scenario is a condition plus an observation: put the app in a state, apply a mobile-specific disturbance, and check what the user sees and what the data looks like afterwards. Turn the ones that apply into test cases with preconditions, steps and expected results (the guide on writing test cases covers the format). Choose by risk: screens that hold unsaved input, features that need the network, flows that use permissions or leave the app (payment, sign-in with another app), and anything that stores data locally.

The app lifecycle can be modelled as a state machine, and many mobile defects are wrong transitions. For testing, a simplified cross-platform model with five states works well: not running, foreground, background, suspended and killed. Neither platform defines exactly this set: "suspended" is an iOS term, and "killed" stands for process death — the OS ends the process of an app in the background, and the user later returns to it from Recents expecting their state back. Modelling the critical screens as states and events (call arrives, app sent to background, process killed, app reopened from Recents) gives you a transition table and a clear list of which transitions you have and have not tested.

ID:        MOB-NET-04
Area:      Network — connection lost mid-request
Screen:    Checkout › Place order
Setup:     Signed-in customer, 2 items in cart, Wi-Fi on, mobile data off
Trigger:   Tap "Place order", then disable Wi-Fi within one second
Observe:   - A clear "no connection" state; no endless spinner
           - After reconnecting: exactly one order exists (order list and API)
           - Retrying does not charge the card twice
Devices:   Tier 1 Android and iOS

Try it: State Transition Generator Try it: Test Case Generator

Install, update, uninstall and reinstall

Updates are where data migration defects hide: a local database schema changed, a preference key was renamed, the stored token format changed, a cached file moved. Test the update from every older version you still support — keep old builds as artefacts so you can install them — and do it with realistic data on the device, not a fresh install.

• Clean install on the oldest and newest supported OS versions; first launch with no network connection.
• Install and first launch on a device with almost no free storage.
• Update from the previous version and from the oldest supported version with a signed-in session, drafts, queued offline actions, settings and downloaded files — everything survives and the user stays signed in.
• Update while a download or background sync is in progress.
• Forced update: a version below the minimum supported version shows a clear update prompt instead of failing API calls.
• Uninstall and reinstall: local data is gone, server data returns, backup and restore behaves as designed. On iOS some Keychain data can outlive the app, so decide and test whether a reinstall is treated as a new user.
• Clear app data (Android) or offload the app (iOS, which keeps documents and data) and relaunch.

# Android (adb) — examples
adb install shop-3.8.0.apk                # old version; now sign in, create drafts, change settings
adb install -r shop-4.0.0.apk             # update, keeping app data
adb shell pm clear com.example.shop       # clear app data
adb uninstall com.example.shop

# iOS Simulator (xcrun simctl) — examples
xcrun simctl install booted Shop-3.8.app
xcrun simctl install booted Shop-4.0.app  # install the new build, then check what data survived
xcrun simctl uninstall booted com.example.shop

Runtime permissions: grant, deny, revoke

Android asks for dangerous permissions at run time, and iOS asks the first time an app uses a protected resource, showing the app’s purpose text. On both platforms the user can change the answer later in Settings, and recent versions add choices such as allowing access only once or sharing approximate rather than precise location; Android also made notifications a runtime permission. The app must work — or degrade clearly — for every answer.

• Grant on first request: the feature works immediately, without restarting the app.
• Deny: the app explains what is unavailable and offers another path (type the address instead of using location).
• Deny again or "Don’t ask again": the app does not loop the prompt; it explains how to enable the permission in Settings.
• Allow once / only this time: the next session asks again, and the feature handles it.
• Approximate location or limited photo access: features that need more say so instead of failing silently.
• Revoke in Settings while the app is in the background. On Android the app’s process is killed when a permission is revoked; on return the app must restart cleanly on a sensible screen.
• The permission is requested in context, when the feature is used — not all at once on first launch — and the purpose text is accurate.

# Android
adb shell pm grant  com.example.shop android.permission.CAMERA
adb shell pm revoke com.example.shop android.permission.CAMERA

# iOS Simulator
xcrun simctl privacy booted grant  photos com.example.shop
xcrun simctl privacy booted revoke photos com.example.shop
xcrun simctl privacy booted reset  all    com.example.shop

Interruptions and the app lifecycle

An interruption is anything that moves the app out of the foreground or covers it. The dangerous one is invisible: while the app is in the background, the OS may kill its process to reclaim memory, and when the user returns the app must rebuild the screen and restore what they had typed. On Android the developer option "Don’t keep activities" destroys each screen as soon as the user leaves it — a cheap way to find missing state restoration. Configuration changes such as rotation, language, dark mode or font size also recreate the screen by default on Android.

• Incoming call, answered and declined, during form entry, video playback, recording and payment.
• Notifications from other apps; pulling down the notification shade or Control Center mid-flow.
• Switch to another app and come back after a few seconds, a few minutes and several hours (session expiry).
• Lock and unlock the screen while waiting for an OTP or while a timer runs.
• An alarm fires, or a low-battery warning appears; battery saver or Low Power Mode turns on.
• Bluetooth headphones disconnect during audio playback — playback should pause.
• Process death: send the app to the background, kill the process, reopen it from Recents.
• Round-trips to other apps — a bank app, a browser for sign-in or 3-D Secure — return to the right screen with the right state.
• Split screen, picture-in-picture, and folding or unfolding a foldable mid-flow.

# Android — force the conditions
adb shell am kill com.example.shop          # kill the background process, then reopen from Recents
adb shell dumpsys battery unplug
adb shell dumpsys battery set level 5       # simulate a low battery
adb shell dumpsys battery reset
adb shell dumpsys deviceidle force-idle     # put the device into Doze
adb shell dumpsys deviceidle unforce

# Android emulator — incoming call and SMS
adb emu gsm call 5551234
adb emu sms send 5551234 "Your code is 482913"

Try it: State Transition Generator

Network changes, offline mode and sync

On mobile the network is a variable, not a constant. Test the transitions and the quality of the connection, not only "online" and "offline". For apps that work offline, synchronisation is the main risk: queued changes sent twice or in the wrong order, conflicts between devices resolved silently, and actions queued under a session that expired in the meantime.

• Wi-Fi to cellular and back during an upload, a download and streaming.
• Airplane mode on and off in the middle of a request.
• Launch while offline: cached content with a visible offline indicator; actions queued or disabled with an explanation.
• Slow network (high latency, low bandwidth): loading states, sensible timeouts, and no duplicate submission from impatient taps.
• Flaky network (drops and packet loss): retries with back-off, no duplicate records; order and payment requests are idempotent.
• Captive portal (hotel or airport Wi-Fi): connected but no internet — the app receives an HTML login page instead of JSON and must show a network message, not a parsing error.
• Offline conflict: edit a record offline on device A, edit the same record online on device B, reconnect A — the agreed conflict rule is applied and visible.
• Queued actions sent after the session expired offline; device clock or timezone changed while offline.
• Data saver or restricted background data enabled.

# Android
adb shell svc wifi disable     # and: enable
adb shell svc data disable     # and: enable

# Android emulator — start with a throttled network
emulator -avd Pixel_Test -netspeed edge -netdelay gprs

# iOS — Network Link Conditioner (device Developer settings, or Xcode additional tools for the Mac)

# Server side — point the app at an endpoint that answers slowly or with an error code

Try it: API Status Code Simulator Try it: Mock Error Response Generator

Screens, orientation, gestures and input

• Rotate on every screen with input: typed text, selections, scroll position and open dialogs survive.
• Switch dark mode while the app is open; check contrast and images in both modes.
• Largest font size or Dynamic Type size: no clipped or overlapping text, and long screens scroll.
• Change the Android display size; test the smallest and largest screens in your matrix.
• Keyboard: the right type for each field (numeric for OTP and phone, email for email), the focused field and the submit button stay visible, "Next" moves focus, and OTP autofill works where the platform supports it.
• Gestures: tap, double tap, long press, swipe, pinch, drag and pull-to-refresh; custom edge swipes do not fight the system back gesture.
• Rapid repeated taps on submit buttons do not create duplicates.
• Right-to-left: in Arabic the layout mirrors, swipe directions and back arrows make sense, mixed Arabic and Latin text displays correctly, and inputs accept Arabic-Indic digits where the app allows them.

# Android
adb shell settings put system font_scale 2.0     # large text (reset with 1.0)
adb shell wm size 1080x2400                      # emulate another screen (reset: wm size reset)
adb shell wm density 480                         # (reset: wm density reset)
adb shell cmd uimode night yes                   # dark mode on (no = off)

# iOS Simulator
xcrun simctl ui booted appearance dark
# larger text: raise the text size in the simulator’s Settings app

Try it: Arabic Test Data Generator Try it: Multilingual Test Data Generator Try it: Fake Phone Number Generator

Battery, CPU, memory, storage and data

Resource defects rarely fail a functional test. They show up later as battery complaints, "App not responding" dialogs, sluggish scrolling and the OS killing the app. Measure on real devices with the platform profilers (Android Studio’s profilers, Xcode Instruments) and compare each release with the previous one rather than against an absolute number.

• Battery: a typical 30-minute session on a real device, compared with the previous release; location updates, sensors and wake locks stop when the user leaves the screen; background work respects Doze and Low Power Mode.
• CPU and rendering: long lists scroll smoothly on the lowest-end supported device; nothing keeps working in the background without reason.
• Memory: repeat the main flow twenty times and check that memory returns to its baseline; open large images; test on low-RAM devices.
• Storage: with a nearly full device, writes fail gracefully; caches have a limit and are cleared; the app’s size after a week of use is reasonable.
• Data: cellular data used by a typical session; images sized for the screen; large downloads on cellular only with the user’s consent.
• Start-up: cold and warm start times on the lowest-end device; heat during long camera, video or map sessions.

# Android — quick measurements
adb shell dumpsys meminfo com.example.shop
adb shell dumpsys gfxinfo com.example.shop       # frame rendering stats
adb shell dumpsys batterystats --reset
# ...run the session on battery...
adb shell dumpsys batterystats com.example.shop

Try it: Response Size Analyzer

Push notifications

A push notification crosses several systems: the app registers with the platform service (Firebase Cloud Messaging on Android, APNs on iOS), receives a device token, sends it to your back end, and the back end sends messages through the platform service. A failure anywhere looks the same to the user — nothing arrives, or the wrong thing opens — so test the chain and the app states separately.

• Notification permission denied: the app still works and offers in-app alternatives; the app’s own notification settings are respected.
• Delivery with the app in the foreground (in-app banner or silent update, as designed), in the background and killed.
• Tapping opens the right screen with the right record — also when the user was signed out, in which case the target opens after sign-in.
• Sign out, then sign in as another user: notifications for the first user no longer arrive (the token is unregistered or reassigned).
• Reinstall or restore: the back end receives the new token and stops using the old one.
• Content: localized text, Arabic right-to-left, long text, emoji and images; no sensitive data visible on the lock screen.
• Badges are cleared, notifications are grouped, and Android notification channels have the intended importance.
• Scheduled notifications arrive at the correct local time across timezones.

# iOS Simulator — deliver a test notification without a server
xcrun simctl push booted com.example.shop order-shipped.apns

# order-shipped.apns
{
  "Simulator Target Bundle": "com.example.shop",
  "aps": { "alert": { "title": "تم شحن طلبك", "body": "Order A-1042 is on its way" }, "badge": 1 },
  "orderId": "A-1042"
}

Try it: Arabic Test Data Generator

Defect examples and what to put in a mobile bug report

A mobile bug report needs more environment than a web one: device model, OS version, app version and build, network type, orientation, language, font size, permission state, and how the app reached that state (fresh install or update from which version). Attach a screen recording and the device log — logcat on Android, the device console on iOS. The bug report guide covers the rest of the format. The titles below are illustrative examples of the defects this catalogue finds.

[Android, Pixel] Checkout crashes on resume after process death on the payment step
[iOS] Draft message lost when a phone call arrives while typing
Offline queue sends "Add to cart" twice after switching from Wi-Fi to 4G
Update 4.1 → 4.2: saved addresses missing (local database migration skipped)
"Order shipped" notification opens Home instead of order A-1042 when the app was killed
Location permanently denied: map screen shows an endless spinner and no link to Settings
Font size 200%: "Confirm" button off-screen on the OTP screen and not scrollable
Captive-portal Wi-Fi: app shows "Unexpected token <" instead of a network message

Frequently asked questions

References

• Certified Tester Mobile Application Testing (CT-MAT)ISTQB · 2019ISTQB's specialist syllabus on mobile testing: app types, device and platform challenges, test types and tools.
• Core app quality guidelinesAndroid Developers (Google)Google's baseline quality criteria for Android apps — visual experience, functionality, performance, privacy and security — with the tests used to check them.
• Test apps on AndroidAndroid Developers (Google)Android's official testing guidance: test types and scopes, local vs instrumented tests, and testing best practices.
• XCTestAppleApple's framework for unit, performance and UI tests of Xcode projects on iOS and other Apple platforms.
• OWASP Mobile Application Security Verification Standard (MASVS)OWASP FoundationOWASP's security requirements for mobile apps, grouped into control areas such as storage, cryptography, authentication, network and platform interaction.
• Test your app's accessibilityAndroid Developers (Google)How to test an Android app's accessibility manually with TalkBack and other services, and automatically with the platform's testing tools.
• Accessibility — Human Interface GuidelinesAppleApple's accessibility design guidance for iOS and other platforms: VoiceOver, Dynamic Type, contrast, touch targets and motion.