Mobile app interruption testing checklist for Android and iOS

Mobile app interruption testing checks whether someone can finish a task after a call, screen lock or app switch. Start with an unfinished form, upload or submission, trigger one interruption, then return and check the saved work and final result. A screen that looks correct can still hide a lost attachment or a duplicate order.

Choose the flows that matter to your Android or iOS release, and agree what each should do before running the test.

What should you agree before interrupting a task?

Write down what the user should find on return. For a form, name the fields and attachments that should remain. For an upload, agree whether it continues while the app is away, waits until it returns or offers a retry. For a recording, decide whether it stops and where the recorded portion should appear.

Those answers depend on the feature. A banking app may deliberately hide a screen and require authentication on return. Test that recovery path against the agreed behaviour rather than expecting every app to reopen the same screen immediately.

Choose a recognisable test item, such as a draft labelled Interruption test A. Use sandbox transactions for checkout tests. Record the installed build, device, OS, account state and network condition. Keep the network stable for the first run so you can tell whether leaving the app is enough to trigger the failure.

Which interruptions should your checklist cover?

Pick events your users can encounter during the selected task. Run them separately first; combine them later if a reported failure needs that sequence.

Interruption	How to run the check	What to inspect on return
App switch	Leave a populated form, use another app, then return	Text, selections, attachments and position in the task
Screen lock	Lock during editing or a pending submission, then unlock	Authentication, saved work and the submission's status
Incoming call	Test declining and answering in separate runs	Task recovery; playback or recording behaviour where relevant
Alarm or competing audio	Trigger it during playback or recording	Whether audio pauses, stops or resumes as specified; agreement between controls and sound
Notification opened	Tap a test notification while another task is unfinished	Destination, Back behaviour and whether the earlier task remains recoverable
Longer absence	Return after a recorded interval, including session expiry if relevant	Recovery, reauthentication and any pending result

A notification banner, an accepted call and a tap on a notification can produce different outcomes. Record what you actually did and saw. “Interrupted by notification” doesn't tell engineering whether you stayed on the form or opened another screen.

For each run, continue the task after returning. Check the saved record or completed upload, not just whether the app is responsive.

When should you interrupt a submission?

Repeat the submission with the interruption at each of these points:

1. Before sending: Fill in the form, leave and return, then submit. Check that the inputs survive as agreed and can still be sent.
2. While the result is pending: Tap Submit, interrupt while the app shows progress, then return. Check that it can establish whether the operation completed and offer a usable next step.
3. After acceptance but before confirmation appears: With engineering's controlled test setup, let the server accept the action while delaying the response. Leave, return and follow the recovery path. Check that the original action isn't applied twice.

You can't reliably identify the third case by looking at a spinner. Ask engineering for a way to control the response and inspect the test record. A pending screen alone doesn't establish whether the server received anything.

If the app offers Retry, use it and check the result again. Two HTTP attempts don't necessarily mean two orders; count the saved orders or other user-visible effects. Keep a harmless test reference beside the result so someone else can verify it.

What differs between Android and iOS?

On Android, leaving the screen and losing the app process are different test conditions. The system may destroy a background process while the user is elsewhere. A quick switch away and back may leave it alive and miss a restoration bug. Android's UI state guide also distinguishes system-initiated destruction from a user dismissing or force-quitting the app.

Keep separate runs for ordinary app switching, verified recovery after process death and deliberate user dismissal. Ask engineering to supply and verify the process-death procedure for your test build. Record the method; don't label a Settings force-stop as proof of system-initiated recovery.

On iOS, an app's scene can move into the background and become suspended. UIKit can disconnect a background or suspended scene to reclaim resources, as Apple's app lifecycle guide explains. Returning after a few seconds doesn't cover every restoration path. Include a separate controlled restoration test when the feature depends on keeping unfinished work.

Audio needs its own expectations. Apple's audio interruption guide describes interruption handling and decisions about resuming playback. Test what you can hear alongside the visible controls, including a run where the user pauses playback before the interruption. Avoid a blanket rule that everything should automatically resume.

Use physical phones for the call, lock and audio behaviour your testers need to verify. Record any emulator or simulator coverage separately in your mobile device test matrix.

What should you record for each run?

Copy this into your existing test record. Replace “a while” with an elapsed time, and name the route back: the app icon, recent apps or a notification.

Flow / expected recovery:
App version and build / distribution channel:
Device model / OS / physical or simulated:
Account, starting data and network:
Test item reference:

Task state before interruption:
Interruption / exact action:
Time away:
How the app was reopened:
Process restart: [verified / not observed / unknown; method]

[ ] Saved work matches the agreed behaviour.
[ ] Screen and controls match the actual task status.
[ ] Authentication recovery works where required.
[ ] Media behaviour matches the agreed result, if applicable.
[ ] The task can be completed or retried.
[ ] Final saved result has no missing or duplicate items.

Expected result / actual result:
Failures / attempts:
Evidence / issue link:
Outcome: [passed / failed / blocked]
Conditions not covered:

If you can't verify whether the process restarted or the server accepted the action, write “unknown”. You can still report the observed failure and ask for the missing check.

How do you report a bug found after an interruption?

Put the unfinished task and interruption in the title. Then include enough starting state to repeat the sequence. This fictional report describes a form that loses work after a call:

Title: Delivery note disappears after answering a call on an unfinished job form
Build: 3.2.0 (418), internal test build
Device: Pixel 8, Android 15, physical phone
Setup: Test account; job TEST-142; Wi-Fi unchanged throughout

Steps:
1. Open TEST-142 and enter "Leave at reception" in Delivery note.
2. Receive and answer a call on the test phone.
3. End the call after 45 seconds.
4. Return through recent apps and inspect the note.

Expected: The unfinished delivery note remains editable.
Actual: Same job form opens, but Delivery note is empty.
Frequency: 2 failures / 3 attempts from the same starting state.
Process restart: Unknown; not checked during these attempts.
Evidence: Reviewed before/after screenshots and attempt times attached.

A recording may miss the call screen, device lock or time spent away. Write those actions into the steps even when you attach a clip. Remove phone numbers, notification previews and other personal information before sharing evidence. The screen recording guide covers how to pair a clip with the details needed to reproduce it.

Use the bug report template generator to format the failure for your tracker. Keep the interruption and return route in the steps so the next person tests the same sequence.