Mobile network problems extend beyond having no internet connection. A phone may connect to Wi-Fi without reaching the server, switch networks, receive delayed responses, or disconnect after sending data. Effective offline testing checks unavailable connectivity and state transitions.
QA's central question is what the user knows about the operation's outcome. A missing response does not mean the server did nothing. This uncertainty is particularly risky for orders, transfers, and messages.
Define offline capabilities first
Not every application needs full offline functionality. Specify cached reads, permitted local edits, queued work, and features requiring connectivity. Define acceptable data age separately.
Offline-first design makes core functionality available without internet and deliberately manages a local data source. A single cached screen does not make the entire product offline-first.
Distinguish network conditions
Build a matrix around failure cause and timing. No signal, a slow response, and an API error need different handling even when users see the same loading indicator.
- →No active connection before launch
- →A connection exists but the target server is unreachable
- →A request is sent but the response is lost or severely delayed
- →Wi-Fi changes to cellular during an operation
- →The server returns an error or invalid data over a healthy network
Airplane mode is convenient, but verify its actual state: Wi-Fi can be enabled separately. A network icon also does not prove a specific API is reachable.
Preparing an experiment
Choose one scenario and observation points: tap, request transmission, server record, response receipt, and screen update. Retain operation IDs and initial data state.
Use controlled delays and failures in a test environment, a proxy, or lab network tools. HTTP-proxy throttling models some conditions but does not reproduce radio networks, cell handovers, or every packet-loss pattern.
Practical example: sending a message
Consider a chat that stores outgoing messages locally and sends them after reconnection. Expect one message with a clear status even if connectivity disappears at an inconvenient moment.
- 1.Open a conversation online and record its latest server message.
- 2.Disconnect, enter new text, and send. Expect a local pending message if this mode is supported.
- 3.Restart offline. The text and correct status should persist.
- 4.Restore connectivity. Verify sending, status change, and exactly one message for the recipient.
- 5.Repeat, disconnecting after server acceptance but before the client receives the response.
- 6.Retry and inspect the server. Where duplicate protection is specified, the same logical message must not be created twice.
If requirements omit that protection, record the risk and agree on the expected model. A Retry button alone does not resolve uncertain outcomes.
Interface states
Distinguish loading, no data, stale cache, and network failure. An empty screen after a timeout must not imply that saved objects no longer exist.
Manual retry should be accessible and avoid unbounded parallel duplicate requests. Reconnection must not repeatedly refresh the screen, clear entered text, or replay obsolete error messages.
Queues and retries
Check persistence after restart, business-required ordering, retry limits, and permanent-error handling. Retrying temporary network failures and access denials through one infinite algorithm is dangerous.
Check the queue after logout and login as another user. The previous account's local changes must not be sent as the new user. Expired sessions need the intended authentication recovery while retaining permitted context.
Conflicts and freshness
Two devices can edit one object independently. Create a conflict: device one edits offline, device two saves online, then device one reconnects. Product policy determines whether to merge, choose a version, or report a conflict.
Do not assume the last visible record is correct. Compare server version, local result, and user explanation. Silent overwrites of important data can be serious defects despite technically successful requests.
Additional regression coverage
Include first launch without cache, large queues, low storage, prolonged offline use, and expired sessions. Test relaunch after process termination and backgrounding during synchronization.
Assess battery and data use separately: frequent failed retries can turn a small connectivity issue into sustained load. Derive intervals and limits from product architecture rather than a universal number.
Common mistakes and lessons
The most common mistake is disconnecting on the homepage, seeing a banner, and stopping. Principal risks occur at operation boundaries: uncertain outcomes, duplicates, lost drafts, and version conflicts.
Report the interruption point, actual network conditions, cache state, operation ID, and server outcome. A strong offline test demonstrates preserved data and predictable recovery, beyond a “no internet” message.