Network & Resilience Testing — Testing on Dirty Networks

The connection on a developer’s desk is fast, stable, and always there. The connection a courier has in a concrete loading dock, or a farm worker has three valleys out from the nearest tower, is none of those things. It is slow when it works, gone when it does not, and worst of all it flickers between the two. Software written and tested only on the good network has never met the conditions it will spend its life in.

This is not an edge case in NZ — it is the centre case for whole sectors. Agritech runs on phones and tablets in paddocks. Logistics runs on scanners in trucks, warehouses, and rural delivery runs. Field health workers, meter readers, surveyors, and contractors all work where the signal is thin. When a Waka Kotahi roadside inspection app, an IRD myIR session on a back-country marae, or an ANZ goMoney transfer on a State Highway with no bars behaves badly, the cause is almost always a network condition that was never tested.

The three lessons here build on each other. First you learn to test the network itself — slow, dropped, and offline. Then you learn to test what happens when the systems on the other end of that network misbehave. Then you learn to test the quiet damage left behind — the stale caches and corrupted state that make a bug appear and vanish depending on what the app remembered from last time. Together they cover the failures that real users hit and that office testing never finds.