Mobile app offline testing checklist: saved work, retries and sync

To test a mobile app offline, remove connectivity at specific points in a task, check what the app keeps locally, then reconnect and verify the saved result. Include a run where the server accepts a change but the phone never receives its confirmation. A screen that says “Try again” doesn't tell you whether the first attempt succeeded.

What should the app do without a connection?

Choose a feature and agree its offline behaviour before testing. A field-service app might save a completed inspection for later upload. A booking app might let you browse saved details but require a connection to reserve a slot.

Write down which actions the tester should be able to complete, which should wait and which should be blocked. For saved data, agree how the app shows that it may be out of date. For pending changes, agree how the tester knows whether they are saved on the phone or accepted by the service.

Android's offline-first guidance describes different write strategies, including online-only and queued writes. An offline queue is a product choice, not a universal pass condition.

Use a test account and a harmless item such as Offline check A. Record the installed build, backend environment and device. For purchases or other consequential actions, use the team's sandbox test flow.

Which offline scenarios should you test?

Start with the app in the foreground. Keep app switching and screen locking for a later run so you can tell whether losing the connection alone triggers the problem.

Scenario	How to set it up	What to check
Open without a connection	Open after a verified disconnection; test previously used and clean app states separately	Usable saved content or a clear recovery route; no endless loading
Read saved and uncached content	Load one item online, disconnect, then open that item and another that wasn't loaded	The app distinguishes available content from content it cannot fetch
Make a supported offline change	Disconnect before editing or adding an item	Work is retained and its pending status matches the agreed behaviour
Lose the connection while sending	Start an upload or submission, then remove connectivity	Inputs and attachments survive as specified; the next action is clear
Lose the confirmation	Use a controlled setup that accepts the change but withholds its response	Recovery establishes the result without applying the same action twice
Reopen with pending work	If the feature promises to retain offline work, close and reopen the app before reconnecting	The pending item and its attachments remain available
Reconnect with pending work	Restore a working connection and follow the documented sync or retry route	Pending items reach a final state and match the saved records
Repeat a connection change	Disconnect and reconnect again during recovery	No missing items, misleading success state or duplicate effects

Adapt the list to the feature. An app that doesn't cache documents still needs a useful response when a document cannot load, but it doesn't need to invent a cached copy.

Keep a separate run for poor connectivity. A slow or unreliable connection can leave an action pending for longer than a complete disconnection. Record the test tool and its delay or loss settings so engineering can repeat it.

How can you tell that the phone is actually offline?

Check both Wi-Fi and mobile data, and record what you changed. Turning off Wi-Fi may leave a working mobile connection. On iPhone, Wi-Fi can be used while Airplane Mode is active, as Apple's Airplane Mode guide explains. The plane icon alone isn't enough evidence that your test had no connection.

Also test a network that is connected but cannot reach the service, using an approved test router or engineering's failure setup. Android's network-state documentation distinguishes a network configured for internet access from one whose access has been validated. Even validation cannot guarantee that a particular request will succeed.

Ask engineering for a repeatable way to delay or drop the selected request. If you open Settings to change connectivity, record the trip away from the app: that run includes an interruption. Use an external network control when you need to isolate connection loss. The interruption testing checklist covers the separate checks for leaving and returning to the app.

What should you check after reconnecting?

Watch the app's pending items through to the agreed outcome. If recovery requires a manual retry or reopening the screen, follow that route and record it. Don't assume that every app promises automatic background sync.

1. Check each item: Confirm the text, attachments and intended destination survived. Compare them with what you entered before disconnection.
2. Check the saved result: Use an authorised server view, another online client or engineering's test inspection to confirm what was accepted. A success banner alone is weak evidence.
3. Check retries: Retry where the app offers it, then inspect the result again. Count saved records and relevant effects such as notifications, not just outgoing requests.
4. Check later access: Reopen the item after recovery. Verify that a pending label clears when appropriate and that the app hasn't merely hidden a failed upload.

For the lost-confirmation case, have engineering verify that the server accepted the first attempt before withholding the response. Without that check, label acceptance as unknown. The HTTP standard's guidance on idempotent requests explains why automatic retries need care when repeating an action could have another effect. Check whether one intended action produced the agreed result once.

If the feature allows edits on multiple clients, add a conflict test: change the same test item on an offline phone and an online client, then reconnect. Agree the expected winner, merge or conflict prompt first. Check that the displayed result follows that rule; “last write wins” isn't the right expectation for every feature.

For account-based queues, also agree what happens if the tester signs out before sync. Check that work from the first account cannot appear or upload under a second account. Use separate test accounts and record the intended handling of the pending work.

What should you record for each offline test?

Copy this into your test record. Give every attempt its own item reference so an earlier successful sync doesn't look like the current attempt passing.

Feature / expected offline behaviour:
App version and build / distribution channel:
Backend environment:
Device / OS / physical or simulated:
Account state / starting data:
Test item reference:

Connection before / how it was removed:
Exact task stage when connection changed:
Time disconnected / any delay or loss settings:
App stayed foregrounded: [yes / no; actions taken]
Observed offline status / retained work:

How connectivity was restored:
Recovery action: [automatic / Retry / reopen / other]
Server accepted first attempt: [yes / no / unknown; how checked]
Final saved result / number of resulting items:
Expected result / actual result:
Failures / attempts:
Evidence / issue link:
Outcome: [passed / failed / blocked]
Conditions not covered:

Choose device and OS coverage with your mobile device test matrix. Record a simulator result separately from a physical-phone run, particularly for Wi-Fi and mobile-data transitions.

How should you report a failure found during offline testing?

Put the task and connection change in the title. Describe the final result as well as the error screen. This fictional example shows why both matter:

Title: Retrying an inspection after connection loss creates two saved inspections
Build: 4.1.0 (612), internal distribution, staging backend
Device: Pixel 8, Android 15, physical phone
Setup: Test account; inspection reference OFFLINE-27; app kept foregrounded

Steps:
1. Complete OFFLINE-27 online and tap Submit.
2. In the controlled test setup, accept the write and drop its response.
3. Wait for the app to show "Couldn't submit".
4. Restore the connection and tap Retry once.
5. Open the staging inspection list using the authorised test view.

Expected: One completed inspection; the app shows its final status.
Actual: Two completed inspections contain the same test reference and answers.
Frequency: 2 failures / 2 attempts with a new reference per attempt.
Evidence: Attempt times, reviewed screenshots and test record references attached.
First-attempt acceptance: Verified by engineering in the test setup.

Keep credentials and personal data out of screenshots, logs and any exported network trace. If you couldn't inspect the server result, report the duplicate shown in the UI and leave the server count as unknown. Include the test reference so engineering can check it.

Use the bug report template generator to turn the failing run into an issue. Keep the connection timing, recovery action and final saved result beside the steps when you hand it over.