Most mobile and web bugs around connectivity do not show up as a crash. They show up as a lost form, a duplicate payment, a cart that empties, or a sync that silently overwrites newer data when the connection comes back. Testing offline and reconnect flows means deliberately cutting, degrading and restoring the network in the middle of a journey, then checking what the user sees and what the system kept. This guide covers what to test and which tools can help, as of November 2026.
TLDR:
- Test the transitions, not just the offline state: going offline mid-action, staying offline, and coming back online.
- Check three things after reconnect: what the user sees, what was saved locally, and what reached the server (no loss, no duplicates).
- Device clouds such as BrowserStack and Digital.ai let scripted tests set offline, airplane and throttled network profiles.
- Maestro, MobileBoost and QA Wolf each offer ways to test offline behavior; the details differ by platform and product.
- mini can go offline and back online mid-run, on Android and web.
What Offline and Reconnect Testing Covers
Offline and reconnect testing checks how an app behaves when connectivity drops, stays poor, or returns during a user journey. The goal is not to prove the app works without a network. It is to prove the app does the right thing at each transition.
Typical flows worth covering:
- Submit while offline: a form, a message, an order or a delivery confirmation.
- Queued actions: actions stored locally and replayed on reconnect, in the right order.
- Payment retries: a payment attempted during a drop must not charge twice.
- Sync conflicts: data changed on two devices or sessions while one was offline.
- Session state: login tokens and carts surviving a reconnect or an app restart.
- User feedback: clear offline banners, disabled actions and retry prompts.
For a worked example in delivery apps, see testing offline-to-online sync.
How to Design Offline and Reconnect Test Cases
- Pick the journeys with real stakes. Payments, submissions, field work and anything a user cannot easily redo.
- Define the cut point. Before the action, during the request, or after the response but before the UI updates.
- Define the expected end state. One record on the server, one charge, the latest version kept, and a clear message on screen.
- Cover degraded networks too. High latency and packet loss often trigger timeouts and retries that a clean offline test never reaches.
- Check after restart. Kill and relaunch the app while offline, then reconnect.
- Keep evidence. A video of the run plus server-side checks make failures easy to triage.
Our mobile app test environment guide covers how to set up accounts and data so these runs stay repeatable.
Tools That Help Test Offline and Reconnect Flows
Minitap
Minitap is an AI QA employee that compresses multi-day regression on web and mobile apps. Its agent, mini, writes test scenarios with acceptance criteria from the context your team provides (specs, tickets, documentation, existing test cases) and runs them as black-box visual tests. mini can go offline and back online mid-run, on Android and web. That lets an offline and reconnect check sit inside the same regression scenario as the rest of the journey, with a video and findings for each run.
BrowserStack App Automate
BrowserStack's network simulation docs describe no-network and airplane-mode profiles, predefined 2G to 4G profiles, and custom profiles with bandwidth, latency and packet loss, for Appium tests on its real-device cloud. For Maestro builds, BrowserStack notes the network profile is set when the build starts and applies to the whole build, and that network profiles require a paid plan.
Maestro
Maestro has setAirplaneMode and toggleAirplaneMode commands to test offline behavior inside a flow. Per Maestro's docs, these commands work on Android; on iOS simulators and web, the command passes without changing the network.
MobileBoost
MobileBoost lists offline mode on iOS simulators, plus network capture and mocking to simulate failures and edge cases without hitting production systems.
QA Wolf
QA Wolf lists offline modes and 2G/3G network conditions among the scenarios it automates as part of its managed test service.
Digital.ai Testing
Digital.ai Testing lists network throttling to simulate 3G, 4G, 5G, offline and lossy connections, along with network logs and HAR capture on real and virtual devices.
Comparison of Offline and Reconnect Testing Options
| Tool | How you test network changes (per vendor) | Who writes the tests |
|---|---|---|
| Minitap | mini can go offline and back online mid-run, on Android and web | mini writes scenarios; the team reviews proposed updates |
| BrowserStack App Automate | Offline, airplane, predefined and custom network profiles | Your framework tests |
| Maestro | setAirplaneMode / toggleAirplaneMode commands | Your YAML flows |
| MobileBoost | Offline mode on iOS simulators; network mocking | Agent-generated tests, editable |
| QA Wolf | Offline modes and 2G/3G conditions | QA Wolf's managed service |
| Digital.ai Testing | Network throttling, offline and lossy profiles | Your framework tests |
Common Offline Bugs to Look For
- Duplicate orders or charges after a retry.
- Local drafts lost on app restart.
- Stale data shown as current after reconnect.
- Infinite spinners instead of a retry prompt.
- Sync that overwrites newer server data with older local data.
- Session expiry during offline periods that logs the user out without saving work.
FAQ
What is offline and reconnect testing?
It checks how an app behaves when the network drops, degrades or comes back during a user journey: what the user sees, what is saved locally, and what reaches the server, with no lost or duplicated actions.
Can Minitap test offline and reconnect flows?
Yes. mini can go offline and back online mid-run, on Android and web, inside a regression scenario, and each run comes with a video and findings.
Which tools let scripted tests simulate poor networks?
BrowserStack App Automate documents offline, airplane and throttled network profiles for framework tests, and Digital.ai Testing lists network throttling with offline and lossy profiles. Maestro has airplane mode commands, and MobileBoost lists offline mode on iOS simulators.
What should a reconnect test check?
Check the end state on three levels: the screen (clear status, no stuck spinner), local storage (draft or queue kept), and the server (one record, one charge, latest version kept).
How do we keep offline tests from being flaky?
Use isolated test accounts and data, set the cut point explicitly, wait for observable states rather than fixed timers, and keep a video of each run so failures are easy to tell apart from environment issues.
Final Thoughts on Testing Offline and Reconnect Flows
Connectivity bugs hide in transitions. Pick the journeys with real stakes, define the cut point and the expected end state, and test degraded networks as well as full drops. To run those checks as part of regression on web and mobile, see how Minitap works on your product.