Stop 09 · Mobile TestingTopics · 5/8

Mobile-Specific Test Scenarios

Part of the QA Testing Roadmap

In short

Halfway through paying, a call comes in. Or the network drops. Or the phone hits 5% battery. Real users live in these moments, so your tests should too.

Testing scenarios unique to mobile — app backgrounding/foregrounding, interruptions (calls, notifications), network switching (Wi-Fi to cellular), and low battery/storage conditions.

The purple blob stirs a pot of dal while a pressure cooker steams and a phone buzzes on the counter.

Think of it like this

Cooking with constant interruptions

You're making dal when the doorbell rings, the phone buzzes and the pressure cooker whistles. A good cook handles each one and the dal still turns out fine. A good app handles calls, notifications and network drops without losing your work.

Watch it happen

The interrupted checkout

Fill form
Call comes
Backgrounded
Return
Data safe?

1/5The user enters a delivery address and is about to pay.

The big ideas

What you need to know

Lifecycle events

Background, foreground, rotate, lock. Each can wipe unsaved state if the app isn't careful.

Network switching

Wi-Fi to 4G to nothing in the middle of an upload. Does it retry or fail clearly?

Low battery and storage

Battery saver can limit background work. A full disk can break downloads and photo capture.

Notifications and deep links

Tapping a notification should open the right screen, even when the app was closed.

See it in code

Walk through the code

bash
1# Turn Wi-Fi off and on during a flow2adb shell svc wifi disable3adb shell svc wifi enable4 5# Fake an incoming call on the emulator6adb emu gsm call 55512347 8# Pretend the battery is at 5%, then reset9adb shell dumpsys battery set level 510adb shell dumpsys battery reset11 12# Send the app to the background with the Home key13adb shell input keyevent KEYCODE_HOME

1/4Cut the network at the worst moment, like right after tapping Pay.

Android commands to create interruptions on demand. The gsm call command works on emulators only.

Save yourself the pain

Common mistakes

Oops

Testing every flow in one smooth go with no interruptions.

Do this instead

Add interruption cases to key flows: login, payment, upload and long forms.

Oops

Accepting 'the app restarted from the home screen' after backgrounding.

Do this instead

Users expect to return where they left off. Losing a half-filled form is a real bug.

Your mission

Interrupt a real app

~25 min

Quick check

A user is uploading a photo, switches from Wi-Fi to mobile data, and the upload silently disappears. What's the best label?

Go deeper

  1. 1Design 5 mobile-specific test scenarios beyond standard functional testing.
  2. 2Learn why testing app behavior during an interruption (like an incoming call) catches real bugs.
  3. 3Practice testing an app's behavior when switching between network conditions.

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge