Low connectivity, flaky networks and offline behaviour

A mobile app lives on a network that is nothing like the developer's office wifi. Real users are on patchy mobile data — 3G in a basement, a signal that drops in a lift, a connection that is there but painfully slow, a switch from wifi to mobile mid-action. An app tested only on fast, stable wifi will be full of bugs that only appear on a real network. This lesson is testing connectivity — the single richest source of mobile bugs for an app that talks to a server, and doubly important when money is involved.

The network is not the office wifi

The developer builds and tests on fast, stable wifi, where every request completes instantly and never fails. Real users are on:

Slow connections — 2G/3G, or a congested cell, where a request that takes 50ms on wifi takes 5 seconds, or 30.
Intermittent connections — signal that comes and goes: in a lift, a basement, a moving vehicle, a crowded area. The connection drops mid-request and comes back unpredictably.
High-latency, low-bandwidth — the connection works but every round trip is slow, and large responses crawl.
Network switches — wifi to mobile data as the user walks out of the door, mid-action.
No connection at all — offline, in a dead spot.

Every one of these is normal for a real user and never happens on the developer's wifi — so every one is a class of bug the developer did not see. Testing connectivity is where a mobile QA finds a huge share of the real bugs, because it is exactly the condition the app was not built and tested under.

What breaks under bad connectivity

The failure modes to hunt, because apps mishandle them constantly:

No feedback on a slow request. The user taps "top up", nothing visibly happens (the request is slowly in flight), so they tap again — and again. Without a loading state and a disabled button, a slow network turns one action into several (the double-charge risk — the money lesson).
No timeout or a bad one. The request hangs forever with a spinner that never ends, or times out with a useless error, leaving the user stuck.
Losing the response. The request succeeds on the server, but the connection drops before the app gets the response — so the app thinks it failed. The user retries, and now it happens twice. This is the most dangerous connectivity bug for a money app, and it is subtle: the failure is not "it didn't work", it's "it worked but the app doesn't know".
No offline handling. The app assumes it is online — it crashes, shows a blank screen, or gives a cryptic error instead of a clear "you're offline" message, when there is no connection.
Bad recovery. When the connection comes back, does the app recover gracefully (retry, refresh), or stay broken until restarted?
Partial data. A slow or dropped connection delivers half a response or half a list — does the app handle incomplete data, or show garbage/crash?

Notice how many of these are about the unhappy network path — the developer tested "request succeeds instantly", the QA must test "request is slow / fails / drops after succeeding / comes back".

How to test connectivity deliberately

You cannot rely on walking into a lift — you simulate the conditions:

Network throttling / conditioning tools. Both Android and iOS, and their emulators/simulators, let you throttle the network to 2G/3G, add latency and packet loss, or go fully offline. Chrome DevTools and proxy tools (Charles, Proxyman) can throttle and, importantly, manipulate traffic. Use these to reproduce slow, flaky and offline conditions on demand.
Airplane mode / toggling. The simplest real test: turn the network off mid-action, or toggle it, and see what the app does. Turn it off after tapping confirm but before the response — the critical "lost the response" case.
A proxy to drop or delay responses. A tool that lets you delay a specific response, or let the request reach the server but block the response, reproduces the "succeeded but app doesn't know" scenario precisely — the one that causes double-charges.
Test each step of a flow under each condition. For the top-up flow, ask at every step: what if the network drops here? Before the request, during it, after the server processed it but before the response, during the retry. Map the flow against the network states.

The mindset (from the QA-mindset lesson): for every network-using action, "what if the connection is slow / drops / comes back / never was there?" — and then make it happen with the tools.

Why this matters most for money

For the mobile-money apps this course targets, connectivity is not just about a smooth experience — it is about money correctness, which makes it critical:

The lost-response case (request succeeded, app didn't hear) plus a retry is exactly how a top-up charges twice or a transfer duplicates. The connectivity bug becomes a money bug.
No-feedback double-tap on a slow network is the same danger from the UI side.
Offline during a transaction — does the app queue it safely, reject it clearly, or lose it?
Recovery — after a drop, does the balance reconcile correctly, or show a stale/wrong number?

So the connectivity tests and the money-flow tests (the next-but-one lesson) overlap heavily: the worst money bugs are triggered by bad connectivity. A mobile QA on a money product spends serious time deliberately dropping the network at the exact wrong moment of a transaction, because that is precisely where real money goes wrong for real users on real networks — and precisely what the developer's fast wifi never revealed. This is the highest-value testing on the whole product.

Check your work

The network is not office wifi. Real users are on slow (2G/3G), intermittent (drops in lifts/basements), high-latency, switching (wifi↔mobile), and offline connections — none of which happen on the developer's fast, stable wifi, so all are unseen bug classes.

What breaks. No feedback on a slow request (user re-taps → duplicates); no/bad timeout (stuck spinner); losing the response (server succeeded, app thinks it failed → retry duplicates — the worst); no offline handling (crash/blank/cryptic error); bad recovery when connection returns; partial data. Mostly the unhappy network path.

How to test it. Network throttling/conditioning (emulators, DevTools, proxies) for slow/flaky/offline; airplane-mode toggling at the critical moment (off after confirm, before response); a proxy to delay/drop the response; test each step of a flow under each network state.

Why money makes it critical. Lost-response + retry = double-charge; no-feedback double-tap = duplicate; offline mid-transaction and recovery affect balance correctness. Connectivity bugs become money bugs — the highest-value testing; deliberately drop the network at the wrong moment of a transaction.

Practice

List the network conditions a real user meets that never occur on office wifi, and one bug each could cause.
Using airplane mode (or a throttling tool), test a top-up: turn the network off after tapping confirm but before the response, then reconnect and retry. Observe whether it double-charges.
Throttle to 2G and test whether a slow request shows a loading state and disables the button, or lets you double-tap.
Go fully offline and check the app's behaviour on a network action — clear message, or crash/blank/ cryptic error?
Use a proxy to let a request reach the server but block the response; confirm whether the app handles "succeeded but not heard".
Map the top-up flow against network states (drop before / during / after-server / on-retry) and write a test case for each.

Official documentation

Android — Test network conditions / connectivity — Emulator network throttling and testing connectivity.
Charles Proxy — Throttling, delaying and manipulating requests/responses for testing.
MDN — Network throttling (DevTools) — Simulating slow and offline conditions.

Next: permissions, interrupts, backgrounding and battery.