How to Write Test Cases for Offline Mode (With Examples)

How to Write Test Cases for Offline Mode (With Examples): Core Principles

How to Write Test Cases for Offline Mode (With Examples): Core Principles

Writing test cases for offline mode requires a shift from typical online‑centric scenarios to situations where network connectivity is absent, intermittent, or degraded. The goal is to verify that the application continues to deliver core functionality, preserves data integrity, gracefully handles UI elements that depend on remote services, and recovers smoothly when connectivity returns. A well‑designed offline‑mode test suite catches crashes, ANRs, dead buttons, data loss, and misleading user feedback before they reach production.

The first step is to treat offline mode as a distinct feature area rather than an after‑thought. Identify every user flow that may be executed without a network—login, content browsing, form submission, media playback, settings changes, and any background sync. For each flow, enumerate the assumptions the code makes about network availability and replace those assumptions with explicit checks or fallbacks. This mindset drives the creation of test cases that are both high‑signal (they expose real defects) and maintainable (they map cleanly to requirements).

How to Write Test Cases for Offline Mode (With Examples): Anatomy of a High‑Signal Test Case

A test case that reliably uncovers offline‑mode issues follows a consistent structure. Each element serves a purpose: it makes the case reproducible, isolates variables, and clarifies the pass/fail criterion.

Test‑Case ID

A unique identifier (e.g., OFF‑001) enables traceability to requirements, test‑management tools, and change‑impact analysis. Use a prefix that signals the feature area (OFF for offline mode) and a sequential number.

Preconditions

Preconditions capture the exact state the device or browser must be in before execution. For offline mode this typically includes:

• Network interface disabled (airplane mode on, Wi‑Fi and cellular off, or Ethernet unplugged)
• Application installed to a known version
• Any required account logged in (if the test assumes an authenticated session)
• Data seed loaded (e.g., a local database populated with a specific set of records)
• Device locale, OS version, and any feature flags set

Steps

Steps are the atomic actions a tester or automation script performs. They should be imperative, concise, and free of ambiguity. Include any necessary waits or verification points. For example:

1. Launch the app from the home screen.
2. Navigate to the “My Orders” screen.
3. Tap the “Refresh” button.
4. Observe the UI for a loading indicator.
5. Verify that a toast message reads “No internet connection”.

Expected Result

The expected result describes the observable outcome after the final step. It must be testable and unambiguous. For offline scenarios, expected results often involve:

• UI elements showing appropriate offline state (e.g., disabled buttons, placeholder text)
• No network calls made (verified via network sniffing or instrumentation)
• Local data persisted correctly
• Error messages that are user‑friendly and actionable
• Graceful degradation (e.g., read‑only mode) rather than a crash

Postconditions (optional)

Postconditions reset the device to a clean state for the next test, such as re‑enabling Wi‑Fi, clearing app data, or rebooting the emulator. Including them prevents state leakage that could mask defects.

Attachments / Logs

Link to relevant logs, screenshots, or video captures. Automated frameworks can attach logs automatically; manual testers should note where to find them.

How to Write Test Cases for Offline Mode (With Examples): Positive, Negative, Edge, and Boundary Cases for Offline Mode

Categorizing test ideas helps ensure coverage across the spectrum of possible behaviors.

#### Positive Cases

Positive cases verify that the application works as intended when offline, assuming the offline mode feature is correctly implemented. Examples:

• The app launches and displays cached content without attempting a network request.
• A user can submit a form; data is stored locally and queued for later sync.
• Media playback continues from a locally stored file.

#### Negative Cases

Negative cases check that the app does not perform prohibited actions when offline. Examples:

• Tapping a “Buy Now” button does not initiate a payment gateway call; instead, an inline error appears.
• Attempting to sign up with a new account fails with a clear message that network is required.
• Pull‑to‑refresh does not trigger a spinner indefinitely; it stops after a timeout and shows an offline banner.

#### Edge Cases

Edge cases explore unusual but plausible conditions that sit at the limits of normal operation. Examples:

• The device switches from online to offline mid‑transaction; the app rolls back the operation and notifies the user.
• The app receives a push notification while offline; it stores the notification and displays it once connectivity is restored.
• The user enables airplane mode, then immediately disables it; the app resumes sync without duplicating queued actions.

#### Boundary Cases

Boundary cases focus on limits of data, timing, or resource usage. Examples:

• The local storage quota is exceeded while queuing offline actions; the app shows a storage‑full warning and stops accepting new inputs.
• A large file (e.g., 100 MB) is attempted to be downloaded while offline; the app fails gracefully and does not corrupt existing files.
• The app’s offline timer (time after which queued actions are discarded) is set to 0 seconds; actions are discarded immediately upon going offline.

How to Write Test Cases for Offline Mode (With Examples): Building the Test Matrix

A test matrix translates the categorized ideas into concrete, executable items. Below is a worked example for a typical offline‑first mobile banking app that supports account balance viewing, fund transfers, bill payments, and profile updates. The table lists 22 test cases; each row includes ID, preconditions, steps, and expected result.

*Notes*: Steps that involve toggling airplane mode can be performed via the UI or using adb shell svc wifi disable && adb shell svc data disable. For web tests, Chrome DevTools → Network → Offline achieves the same state.

How to Write Test Cases for Offline Mode (With Examples): Data Setup and Environment Preparation

Reliable offline testing hinges on reproducible data and controllable network conditions.

#### Android

• Airplane mode: adb shell settings put global airplane_mode_on 1 && adb shell am broadcast -a android.intent.action.AIRPLANE_MODE --ez state true
• Selective disabling: adb shell svc wifi disable && adb shell svc data disable (re‑enable with enable).
• Network throttling to zero: adb shell tc qdisc add dev wlan0 root netem loss 100% (replace wlan0 with the active interface).
• Data seeding: Use Android Debug Bridge to push a JSON file into the app’s private directory, then launch the app with a flag that loads the seed (adb shell am start -n com.example.app/.MainActivity --ez load_seed true).
• Clearing state: adb shell pm clear com.example.app removes databases and shared preferences; follow with a fresh install if needed.

#### iOS

• Airplane mode: Enable via Settings → Airplane Mode, or use xcrun simctl status_bar booted override --airPlaneMode true.
• Wi‑Fi/Cellular toggle: xcrun simctl io booted wifi off and xcrun simctl io booted cellular off.
• Network link conditioner: Install the Additional Tools for Xcode package, then create a profile with 100 % loss and apply via xcrun simctl io booted networkinterface en0 set-configuration .
• Data seeding: Utilize UIAutomation scripts to inject a JSON file into the app’s Documents folder, or use a launch argument (-SeedData ) if the app supports it.
• Clean slate: xcrun simctl erase booted wipes the simulator entirely.

#### Web (Chrome/Firefox)

• Offline toggle: Open DevTools → Network → check “Offline”.
• Custom throttling: DevTools → Network → throttling preset → “Slow 3G”, or set custom values (0 kbps download/upload, 500 ms latency).
• Service worker testing: Unregister or update the service worker via navigator.serviceWorker.getRegistrations().then(r => r[0].unregister()).
• Cache seeding: Use localStorage or IndexedDB to prepopulate data before disabling network.
• Automation: With Playwright, launch context with context.setOffline(true); or use page.route('**/*.{js,css,png}', route => route.abort()) to block specific resources.

#### General Tips

• Always verify the network state before each step (e.g., adb shell dumpsys connectivity or navigator.onLine in JS).
• Record logs with adb logcat (Android) or xcrun simctl spawn booted log stream (iOS) to confirm no unexpected network attempts.
• For CI pipelines, Docker containers can simulate offline mode using tc rules on the host network namespace.

How to Write Test Cases for Offline Mode (With Examples): Manual Execution vs Automated Scripts

Both manual and automated approaches have merit. The table below contrasts them across key dimensions relevant to offline‑mode testing.

A balanced strategy uses manual testing for early‑stage validation of new offline flows and exploratory checks, while automation guards against regressions and validates large data sets.

How to Write Test Cases for Offline Mode (With Examples): Prioritization and Traceability

Not all test cases carry equal risk. Prioritization ensures limited testing time focuses on the scenarios most likely to cause user‑visible harm or revenue loss.

#### Risk‑Based Priority Levels

• P0 (Critical): Scenarios where data loss, financial incorrectness, or security exposure could occur. Example: submitting a fund transfer while offline that later duplicates or fails to persist.
• P1 (High): Core user journeys that must remain usable offline, such as viewing cached account balances or reading articles.
• P2 (Medium): Enhancements or secondary features where offline degradation is tolerable but should be graceful (e.g., unable to upload a profile picture).
• P3 (Low): Nice‑to‑have interactions that rarely affect core value, like browsing animated tutorials that require online assets.

Assign each test case a priority label in the test‑management tool. During a sprint, execute all P0 and P1 cases; schedule P2 for nightly runs; reserve P3 for weekly exploratory sessions.

#### Traceability Matrix

Link each test case to one or more requirements (user stories, design specs, or regulatory clauses). A simple matrix helps answer “If this requirement changes, which tests are affected?” and “Does every requirement have at least one verifying test?”

Maintain this matrix in a spreadsheet or a dedicated traceability plugin; update it whenever a requirement is added, modified, or removed.

How to Write Test Cases for Offline Mode (With Examples): Leveraging Autonomous Exploration (SUSA) to Augment Manual Cases

Modern QA workflows benefit from combining scripted test cases with intelligent, self‑directed exploration. SUSA (SUSATest) is an autonomous QA platform that, given an APK or a web URL, drives the application through realistic user interactions without pre‑written scripts. It models several personas—curious, impatient, novice, accessibility‑aware, power user, and even adversarial—to uncover issues that scripted cases might miss.

When applied to offline‑mode testing, SUSA can:

1. Discover hidden navigation paths that lead to screens requiring network calls but are not covered in the manual matrix (e.g., a deep‑linked promotional banner that attempts to fetch a video).
2. Vary timing of connectivity loss by toggling airplane mode at random points during a session, revealing race conditions between UI state changes and background sync tasks.
3. Test multiple personas simultaneously; for example, the “impatient” persona may rapidly tap buttons while offline, exposing toast‑spamming or UI lock‑up issues that a methodical manual tester might not trigger.
4. Generate regression artifacts; after each run, SUSA exports Appium scripts for Android and Playwright scripts for the web, capturing the exact sequences it exercised. These scripts can be added to the automated suite, continuously expanding coverage.
5. Track learning across sessions; the platform remembers which screens have been visited and which actions led to dead ends, so subsequent runs focus on unexplored areas, increasing efficiency over time.

To invoke SUSA for an offline‑mode test, first ensure the device or emulator is in the desired network state (airplane mode on). Then run the CLI:

pip install susatest-agent   # if not already installed
susatest run \
    --app ./my‑app.apk \
    --offline \
    --personas curious impatient power \
    --output-dir ./susa‑run‑2025‑09‑26 \
    --generate‑scripts

The --offline flag tells SUSA to disable network before launching the app and to keep it disabled throughout the session. The resulting scripts appear under ./susa‑run‑2025‑09‑26/scripts and can be committed to the repository alongside hand‑written Appium or Playwright tests.

How to Write Test Cases for Offline Mode (With Examples): Checklist for Reviewing Offline‑Mode Test Suites

Before signing off a test suite, run through this concise checklist to confirm that it addresses the most common sources of offline‑mode defects.

• [ ] Network state verification: Each test case begins with a confirmed offline condition (airplane mode on, Wi‑Fi/cellular disabled, or DevTools offline).
• [ ] No false network calls: Use a network sniffer (e.g., adb logcat | grep "HTTP" or Chrome DevTools) to ensure the app does not attempt a request that should be blocked.
• [ ] User‑visible feedback: Offline states are communicated via toast, banner, placeholder, or disabled controls—not silent failure.
• [ ] Data persistence: Any user input generated offline is stored locally and survives app kill/reboot.
• [ ] Sync correctness: When connectivity is restored, queued actions are applied exactly once, in the correct order, and conflicts are resolved according to business rules.
• [ ] Graceful degradation: Features that require online resources are hidden or disabled, with a clear indication why they are unavailable.
• [ ] Storage limits: Tests cover scenarios where local storage is exhausted, verifying that the app notifies the user and stops accepting new data.
• [ ] Background behavior: The app maintains correct state when moved to background while offline and resumes without corruption upon foreground.
• [ ] Accessibility: Offline error messages and UI states meet WCAG contrast and screen‑reader readability requirements.
• [ ] Recovery from interruptions: Simulate loss of connectivity mid‑transaction (e.g., toggle airplane mode after a few seconds) and verify rollback or resumption logic.
• [ ] Performance: UI remains responsive; no ANRs or excessive battery drain observed during prolonged offline usage.
• [ ] Cross‑platform consistency: For hybrid apps, verify that the offline behavior matches on Android, iOS, and web wrappers.

If any item is unchecked, revisit the corresponding test cases or add new ones to fill the gap.

How to Write Test Cases for Offline Mode (With Examples): Closing Takeaways

Writing effective test cases for offline mode is a disciplined exercise in defining precise preconditions, scripted steps, and observable expectations. By decomposing the feature into positive, negative, edge, and boundary scenarios, and by recording them in a structured matrix, teams gain repeatable coverage that catches data‑loss, sync faults, and misleading UI before they reach users. Pairing these manually crafted cases with autonomous exploration—using tools like SUSA—extends reach into unexpected pathways and generates reusable regression scripts. Prioritization based on risk, coupled with a traceability matrix, ensures that testing effort aligns with business impact and regulatory demands. Finally, a concise review checklist guards against common oversights such as hidden network calls or inadequate offline feedback. Apply these principles consistently, and your offline‑mode test suite will become a reliable safety net for any application that must stay useful when the network disappears.