Offline Mode Testing Checklist (2026)

Offline Mode Testing Checklist (2026)

Offline Mode Testing Checklist (2026)

A practical, item‑by‑item guide you can apply today to verify that your mobile or web app behaves correctly when the network disappears, stays spotty, or comes back after a long pause. The list below groups 30+ concrete checks into logical areas, supplies pass/fail criteria, shows real‑world examples, and points out where manual effort shines and where autonomous exploration can sweep the majority of items in a single run.

---

Understanding Offline Mode Requirements

Defining offline scenarios

Offline mode is not a single state; it is a spectrum that includes:

Each scenario forces the app to rely on locally persisted state, to hide missing data gracefully, and to resume correctly when the link returns. The checklist below treats each as a separate test condition unless noted otherwise.

Business impact of offline failures

When offline handling is weak, users experience:

• Lost input (e.g., a typed message that vanishes).
• Stale UI showing “Loading…” forever.
• Crash or ANR that forces a restart.
• Security gaps if sensitive data is written to unencrypted storage.

Quantitatively, a 2025 study of 12 million sessions found that apps with poor offline recovery saw a 23 % increase in abandonment after the first network hiccup. The checklist aims to eliminate those leak points.

---

Happy Path Tests

Core functionality persists

Goal: Verify that the primary user journey completes without network.

Real example: A food‑delivery app lets users browse menus offline, add items to cart, and checkout. When the network returns, the app sends the order and shows a confirmation toast. If step 5 fails, the order is lost—a critical regression.

Data persistence integrity

Goal: Ensure that any data written while offline is correctly stored and later retrieved.

• Use Android’s SharedPreferences or iOS UserDefaults for lightweight flags.
• Use Room/SQLite or Core Data for structured entities.
• Verify that writes are atomic (no half‑written rows) even if the process is killed mid‑write.

Test:

1. Enable airplane mode.
2. Create 50 entities (e.g., notes) via rapid UI taps.
3. Force‑close the app (swipe away).
4. Re‑launch offline.
5. Confirm all 50 notes appear, sorted as expected.

Pass: zero missing or corrupted entries.

Sync after reconnection

Goal: Confirm that the reconciliation logic resolves conflicts without data loss.

• If the server has a newer version of a record, the client should merge or overwrite per business rule.
• If the client has pending changes, they should be uploaded and the server’s response applied.

Test:

1. Online, edit a contact’s phone number to “111”.
2. Go offline, edit same contact to “222”.
3. Re‑connect.
4. Verify final server value is “222” (client win) or follows defined policy (e.g., timestamp‑based).

Pass: final state matches policy, no duplicate records.

---

Error Handling Tests

Network loss mid‑transaction

Goal: The app must not crash or leave the UI in an indeterminate state when the connection drops during a request.

• Intercept the failure at the networking layer (OkHttp, Alamofire, fetch).
• Show a non‑blocking snackbar: “Lost connection – changes saved locally”.
• Keep any partially filled form fields intact.

Test script (Android Espresso):

@Test fun `order placed loses network`() {
    // enable airplane after clicking place order
    onView(withId(R.id.placeOrderBtn)).perform(click())
    // simulate loss
    adb shell svc wifi disable
    // verify UI shows pending state
    onView(withText(R.string.pending_sync)).check(matches(isDisplayed()))
}

Pass: No exception logged, UI shows pending state, data persists after reconnection.

Graceful degradation of non‑essential features

Goal: Features that require live data (e.g., map tiles, video streaming) should fallback to a usable state rather than blocking the whole app.

• Show cached map tiles with a “stale data” banner.
• Disable video autoplay, show placeholder thumbnail.
• Allow user to manually retry when back online.

Test:

1. Start video playback online, note network usage.
2. Switch to airplane mode mid‑play.
3. Verify video pauses, overlay shows “Offline – tap to retry”.
4. Tap retry while still offline → toast “No connection”.

Pass: No crash, user can continue navigating elsewhere.

User notifications and feedback clarity

Goal: Users must understand why something is unavailable and what they can do.

• Avoid generic “Error” dialogs. Use specific copy: “Unable to load news – you’re offline”.
• Provide an action button: “Try again” or “Go to settings”.
• Ensure the message respects accessibility (see later section).

Test:

• Capture all toast/snackbar/dialog strings while offline.
• Verify each contains the word “offline” or “no connection” and an actionable cue.

Pass: 100 % of messages meet the guideline.

---

Edge/Boundary Cases

Large data sets offline

Goal: The app must handle situations where the local cache grows beyond typical thresholds (e.g., user saves 10 000 images for offline viewing).

• Monitor disk usage; warn when > 80 % of allocated quota.
• Implement LRU eviction or user‑controlled “clear cache”.
• Verify that UI remains responsive when scrolling through a large list.

Test:

1. Pre‑populate cache with 200 MB of images via a background sync.
2. Go offline, open the gallery.
3. Scroll fast; measure frame drops (< 16 ms per frame).

Pass: ≤ 2 % jank frames, no OutOfMemoryError.

Intermittent connectivity (flapping)

Goal: Rapid toggles should not cause request storms or duplicate submissions.

• Use exponential backoff and request deduplication (e.g., idempotency keys).
• Queue outgoing requests; send only when a stable window (≥ 2 s) is detected.

Test:

• Use tc on Linux or Network Link Conditioner on macOS to simulate 500 ms up / 500 ms down cycles.
• Perform a sequence of 10 button taps that each trigger a POST.
• Inspect server logs: exactly 10 requests received, no duplicates.

Pass: Request count matches taps, no 500 errors from server.

Battery‑low / power‑save mode

Goal: When the OS imposes background restrictions, the app should still honor user‑initiated offline actions.

• Disable periodic sync alarms; rely on user‑triggered refresh.
• Ensure foreground service (if any) respects setForegroundServiceType.

Test:

1. Enable Android Battery Saver (or iOS Low Power Mode).
2. Go offline, perform a data‑saving action (e.g., draft email).
3. Verify action completes locally and is queued for later upload.

Pass: No silent failures, queued items persist after reboot.

---

Accessibility Checks

Screen reader compatibility

Goal: All offline‑specific announcements (e.g., “Offline mode – changes saved locally”) must be spoken clearly.

• Use contentDescription for icons, accessibilityLiveRegion for dynamic messages.
• Verify that TalkBack/VoiceOver reads the message without cutting off.

Test:

• Enable TalkBack, go offline, trigger a save action.
• Listen for the full phrase; ensure no truncation.

Pass: Message spoken in full, no extra noise.

Touch target size and spacing

Goal: Offline UI must still meet WCAG 2.1 AA minimums (44 × 44 dp).

• Inspect buttons, list items, and custom controls.
• Use Android Studio Layout Inspector or Xcode Accessibility Inspector.

Test:

• Run automated rule via axe-android or axe-core for iOS.
• Confirm zero violations for targets < 44 dp.

Pass: 100 % compliance.

Color contrast and visual cues

Goal: Users with low vision must discern offline indicators (e.g., banner, icon).

• Contrast ratio ≥ 4.5:1 for text vs background.
• Do not rely solely on color; add an icon or pattern.

Test:

• Use the Stark plugin or contrast-checker CLI.
• Record any failures; adjust colors or add supplemental glyphs.

Pass: No contrast failures.

---

Security and Privacy

Local data encryption

Goal: Sensitive data persisted offline (e.g., authentication tokens, health records) must be encrypted at rest.

• Use Android EncryptedSharedPreferences or iOS Keychain.
• For files, employ AES‑256 GCM with a key derived from hardware-backed keystore.

Test:

1. Enable airplane mode, log in, obtain token.
2. Use adb run-as to pull the app’s private files directory.
3. Verify token is not readable plaintext (look for base64‑like cipher).

Pass: No plaintext secrets found in offline storage.

Secure deletion on cache clear

Goal: When the user clears offline data, remnants should not remain recoverable.

• Overwrite file blocks or use SecureDelete APIs.
• Confirm that a forensic tool cannot retrieve previous versions.

Test (Android):

• Write a known pattern to a file, clear cache via settings.
• Use dd to image the partition and search for the pattern with strings.

Pass: Pattern not found after clear.

Permission handling in offline mode

Goal: Permissions that depend on network (e.g., ACCESS_FINE_LOCATION for live updates) should not be requested unnecessarily while offline, reducing user friction.

• Defer permission prompts until the feature is actually used and network is available.
• Show rationale that explains why the permission is needed for the upcoming online action.

Test:

• Launch app offline, navigate to a feature that would normally request location.
• Verify no permission dialog appears.
• Go online, trigger the feature; confirm dialog appears with appropriate explanation.

Pass: No premature prompts, correct timing.

---

Performance and Resource Usage

CPU, memory, and battery impact

Goal: Offline processing should not cause excessive resource drain that leads to thermal throttling or premature battery loss.

• Profile with Android Studio Profiler or Instruments.
• Keep main thread work < 16 ms per frame; offload heavy parsing to coroutines or dispatch queues.

Test:

• Record a 2‑minute session of repetitive offline actions (e.g., adding 100 items to a list).
• Check average CPU usage (< 15 % on a mid‑tier device) and memory growth (< 5 MB leak).

Pass: Metrics within thresholds, no sudden spikes.

Launch time offline

Goal: Users expect the app to start quickly even when no network is available to fetch config or remote features.

• Measure time from Application.onCreate to first visible UI frame.
• Target ≤ 1.5 s on a typical device (Snapdragon 7‑gen 2 or equivalent).

Test:

• Disable all radios, launch app via adb shell am start -n com.example/.MainActivity.
• Use logcat to timestamp Displayed event.

Pass: Launch ≤ 1.5 s.

Disk I/O efficiency

Goal: Frequent writes (e.g., queuing network requests) should not cause excessive flash wear or UI jank.

• Batch writes; use SQLite transactions or Core Data save points.
• Align writes to OS page boundaries (typically 4 KB).

Test:

• Enable adb shell dumpsys diskstats before and after a burst of 500 queued requests.
• Compute total write KB; ensure < 2 MB for the batch.

Pass: Write amplification low, no UI stalls observed.

---

Release Readiness

Regression suite inclusion

Goal: Every offline‑mode checklist item must have an automated test that runs on each CI build.

• Map each checklist row to a test case ID (e.g., OFFLINE-07).
• Tag tests with @Offline for selective execution.

Table: Sample regression mapping

Pass: 100 % of checklist IDs covered by at least one automated test.

CI pipeline integration

Goal: Fail fast if offline regressions appear.

• Add a dedicated stage that runs the emulator in airplane mode.
• Use Docker images with pre‑installed susatest-agent for autonomous validation (see later).
• Publish a badge: “Offline‑mode verified”.

Example GitHub Actions snippet:

jobs:
  offline-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up Android
        uses: reactivecircus/android-emulator-runner@v2
        with:
          api-level: 33
          target: google_apis
          arch: x86_64
          offline: true   # airplane mode enabled
      - name: Run SUSATest agent
        run: |
          pip install susatest-agent
          susatest explore --apk app-release.apk --offline

Pass: Pipeline green; any failure blocks merge.

Documentation and release notes

Goal: Users and support teams need clear guidance on what works offline and what does not.

• Maintain a markdown file OFFLINE_FEATURES.md listing each feature with ✅ (fully offline), ⚠️ (limited), ❌ (requires network).
• Include troubleshooting steps for common symptoms (e.g., “Pending sync not clearing”).

Test:

• Verify that the file is updated in the same PR that modifies offline behavior.
• Use a link‑checker to ensure no broken references.

Pass: Documentation matches implementation.

---

Autonomous Exploration with SUSATest

How the agent covers the checklist in one pass

SUSATest’s autonomous explorer treats the app as a black‑box state machine. When launched with the --offline flag, it:

1. Disables all radios via ADB (or sets the network throttling profile to “none”).
2. Starts from the launcher activity and performs guided walks: taps, long‑presses, swipes, text entry, and system dialog handling.
3. Records every UI transition, noting whether a network request was attempted (by intercepting HTTP layer) and whether the app displayed any offline‑specific UI.
4. After a configurable exploration depth (default 30 s per screen), it enables the radios again and validates that any queued actions were sent correctly.

Because the agent exercises *all* reachable screens without pre‑written scripts, it implicitly validates many checklist items:

• Happy path – reaches core flows and checks for placeholders.
• Error handling – triggers natural loss by disabling radios mid‑action and verifies UI feedback.
• Edge cases – generates rapid toggles via the built‑in “flap” mode (alternating enable/disable every 750 ms) to test deduplication.
• Accessibility – runs axe-android on each visited snapshot and logs violations.
• Security – scans the app’s data directory for plaintext secrets after each exploration cycle.

The result is a JSON report that maps each observed behavior to a checklist ID, giving you a quick “coverage %” before you even write a single manual test.

Example run output (truncated)

{
  "exploration_id": "susa-2026-04-12-01",
  "device": "Pixel 8 (API 33)",
  "offline_mode": true,
  "screens_visited": 27,
  "checklist_coverage": {
    "OFFLINE-01": "PASS",
    "OFFLINE-04": "PASS",
    "OFFLINE-07": "FAIL – missing snackbar on lost connection",
    "OFFLINE-12": "PASS",
    "OFFLINE-18": "PASS",
    "OFFLINE-22": "PASS"
  },
  "recommendations": [
    "Add a Snackbar with action 'Retry' when network loss detected during order placement.",
    "Increase touch target size for the 'Save draft' button to 48dp."
  ]
}

The engineer can then focus manual effort on the flagged failures, confident that the rest of the checklist is already verified.

---

Manual vs Automated Approaches

A balanced strategy uses the agent for nightly regression and manual sessions for usability polishing and complex interruptions (e.g., simulating a phone call while offline).

---

Short Offline‑Mode Checklist (Copy‑Paste Ready)

• [ ] Launch – App starts ≤ 1.5 s in airplane mode, shows cached UI.
• [ ] Core flow – Primary task completes without network; placeholders visible.
• [ ] Pending actions – User‑initiated changes are queued locally, UI shows “Pending sync”.
• [ ] Re‑sync – On reconnection, all queued requests sent, UI updates to success/failure.
• [ ] Mid‑transaction loss – Network drop during request does not crash; snackbar shown.
• [ ] Graceful degradation – Non‑essential features fallback to cached/stale state with clear notice.
• [ ] Large data set – Offline cache of > 100 MB does not cause OOM or > 2 % jank frames.
• [ ] Flapping network – 500 ms up/down cycles produce no duplicate server requests.
• [ ] Battery saver – Offline actions still queue correctly when power‑save mode active.
• [ ] Screen reader – All offline announcements spoken fully, no truncation.
• [ ] Touch targets – Every interactive element ≥ 44 dp, verified with inspector.
• [ ] Color contrast – Text/icon contrast ≥ 4.5:1, non‑color cues present.
• [ ] Encryption at rest – No plaintext secrets found in app private storage after offline use.
• [ ] Secure deletion – Clearing cache removes recoverable data fragments.
• [ ] Permission timing – No network‑gated permission prompts while offline.
• [ ] CPU/memory – Avg CPU < 15 %, memory growth < 5 MB during repetitive offline actions.
• [ ] Disk I/O – Batched writes < 2 MB per 500 queued requests.
• [ ] Regression coverage – Each checklist ID mapped to an automated test ID in CI.
• [ ] CI gate – Offline‑mode job must pass before merge.
• [ ] Documentation – OFFLINE_FEATURES.md updated, matches feature flags.

Tick each item after a test pass; any unchecked box signals work remaining.

---

Closing Takeaways

A robust offline mode is not a nice‑to‑have extra; it is a core quality attribute that directly influences retention, trust, and compliance. By treating offline handling as a first‑class citizen and verifying it with a concrete, repeatable checklist, you turn a fuzzy “it works most of the time” feeling into measurable confidence.

The checklist above gives you a concrete matrix of 30+ items, each with a clear pass/fail rule and a real‑world illustration. You can run the majority of these checks automatically with a modern autonomous explorer like SUSATest, freeing manual testers to focus on subtle UX nuances and edge‑case scenarios that require human judgment.

When you integrate the automated suite into your CI pipeline, publish a simple “Offline‑mode verified” badge, and keep the documentation in sync, you create a feedback loop that catches regressions before they reach users. The result is an app that feels reliable whether the user is on a high‑speed 5G link, in a subway tunnel, or deliberately conserving data—exactly the experience users expect in 2026.

Keep this checklist close, run it early, run it often, and let the data, not guesswork, guide your release decisions. Happy testing.