In short. Most apps are tested on the developer’s fast connection, but users open them on the subway, in lifts and on crowded Wi-Fi. Bad network testing checks how an app behaves on a slow, laggy, lossy or completely dropped connection. Four settings cover most situations. A bandwidth cap, latency, jitter and packet loss. This guide explains those settings, gives sample profiles and lists what to check at each one.
What is bad network testing?
Bad network testing checks that an app works correctly on a less than ideal connection. The goal is not for the app to be fast, but for it to stay clear when it is slow. Users should see that something is loading, know what to do when there is an error and never lose what they typed.
It matters most for three kinds of app.
- Apps that take money or orders. If a request breaks halfway, a payment can go through twice or not at all.
- Real-time apps. Chat, maps, ride hailing and multiplayer games.
- Apps that upload content. Photos, video and files.
The four settings behind a bad network
| Setting | What it means | What the user feels |
|---|---|---|
| Bandwidth cap | How much data can pass per second | Images and lists load slowly |
| Latency | How long a request takes to go and come back | A wait after every tap |
| Jitter | Latency that keeps changing | An app that is fast one moment and stuck the next |
| Packet loss | Part of the data sent never arrives | Requests time out and get retried |
Two more situations belong on the list. A connection that drops completely, and switching between Wi-Fi and mobile data. The second is often skipped, yet it happens every day when the user leaves home.
Sample test profiles
These values are not measurements of a real network. They are starting settings for tests. Adjust them to your users.
| Profile | Bandwidth | Latency | Packet loss | What it tests |
|---|---|---|---|---|
| Slow mobile data | 750 kbps | 200 ms | 0% | General slowness, loading screens |
| Crowded Wi-Fi | 2 Mbps | 150 ms, jittery | 2% | Stuck requests, retries |
| Subway tunnel | 250 kbps | 600 ms | 10% | Timeouts, error messages |
| No internet | 0 | · | 100% | Offline behaviour, cached data |
What to check at each profile
- Is there a loading indicator? The user should not stare at a blank screen. It should be clear that something is on its way.
- Is the error message clear? Not “Something went wrong” but a message that says what to do, like “Check your internet connection”.
- Can the user retry? They should be able to start the action again without closing the app.
- Does the action go out twice? If the button is tapped again during a slow request, the same order or payment must not be sent twice.
- Is what the user typed kept? The form should not empty when the connection comes and goes.
- Does the app recover when the connection returns? It should carry on by itself, without a restart.
- What shows offline? Content loaded earlier should stay visible, not a blank screen.
How to simulate a bad network
Emulator settings
The Android emulator has its own network speed and latency settings. They are enough for a quick check, but they are limited and do not fully simulate things like packet loss.
A proxy in between
A proxy tool on your computer can sit between the phone and the internet and slow the traffic down. It is flexible, but each test needs setup and the phone has to trust the proxy.
Network settings inside the test
The most repeatable way is to make the network setting a step of the test. The test reaches checkout, the connection drops to the subway tunnel profile, the button is tapped and the result is checked. Then the connection comes back and you see whether the app recovers. The same situation happens at the same moment on every build.
Common mistakes
- Only testing with no internet. Most apps already handle a fully dropped connection. The real bugs show up on slow and unstable ones.
- Only testing the launch screen. A bad network does the most harm in the middle of an action.
- Timeouts that are too long. Users close the app long before a minute passes.
- Unlimited retries. The app keeps trying quietly and the user never knows what is going on.
FAQ
Do I need a physical phone for bad network testing?
No. Slowing the network is done on the connection, not on the phone itself. What matters is that the settings are the same in every test.
Which settings should I start with?
Pick one bad profile first, such as slow mobile data. Run your most critical flow on it once. The problems that show up tell you which profiles to add next.
How do I test switching between Wi-Fi and mobile data?
During the test, turn Wi-Fi off and mobile data on, or the other way round. The app should not lose the request or sign the user out during the switch.
How do I test a game on a bad network?
With the same settings. For games, also check whether progress is saved and whether the game picks up where it left off when the connection returns.
Bad network testing with TestSafe
In TestSafe, network conditions are a step in the scenario. You can set the bandwidth cap, latency, jitter and packet loss during the test, and turn Wi-Fi and mobile data on and off. Save the same settings to an environment and reuse them in every test. After each step the agent reads the screen and brings back the result as a video report.
See every phone setting, the network included, on the Device Conditions page.