In short. Interruption testing checks how an app behaves when something from outside happens while it is being used. Incoming calls, notifications, screen rotation, a low battery, a dropped network and sending the app to the background are the most common. A good app brings the user back to where they were and keeps what they entered. This guide covers the types of interruption, what to check for each and how to automate these tests.
What is interruption testing?
When we test, the phone is usually ideal. Fully charged, fast network, held upright, nobody calling. The user’s phone is not like that. The phone rings on the checkout screen, a message arrives, the phone turns sideways, the battery hits 5 percent.
Interruption testing tries exactly those moments. The question is the same every time. When the interruption ends, where is the app, and is everything the user did still there?
Types of interruption and expected behaviour
| Interruption | What happens | What the app should do |
|---|---|---|
| Incoming call | The call screen covers the app | Return to the same screen after the call, pause video or audio |
| SMS or notification | A notification appears at the top | Not break the flow, and coming back after tapping it should work |
| Screen rotation | The screen turns to landscape or portrait | Keep what is in the form and what was selected |
| Low battery warning | A system warning covers the screen | Carry on once the warning closes |
| Network drop | The internet goes away or slows down | Show a clear message and allow a retry |
| Sent to background | The user goes home, then comes back | Keep the session and the screen |
| Screen lock | The phone locks and unlocks | Continue from where it was |
| Language change | The phone’s language changes | Show text in the new language that still fits the screen |
The most common interruption bugs
The form empties. The user types their card details, turns the phone sideways and every field is empty. On Android, when the phone rotates, the screen is built again from scratch. If the app does not keep what was on screen, the new screen comes up empty. One screen in a flow can survive while the next one empties, which tells you the fault is in that screen’s code, not the phone.
The action is sent twice. A request is left half done during the interruption, the user comes back, taps the button again and the same action goes out twice.
The session is lost. The app returns from the background and throws the user back to the login screen.
The screen freezes. After a call ends, the video or the game does not resume and stays on a black screen.
Text overflows. When the phone’s language changes, long words spill out of buttons.
How to do interruption testing
Manual testing
The simplest way is for the tester to hold the phone and cause the interruption. Ask a colleague to call, turn the phone, switch airplane mode on and off.
Manual testing helps when trying a new screen, but it is hard to repeat on every build. Hitting the right moment is hard too. The call has to arrive in the second the payment button is tapped.
Emulator commands
The Android emulator can trigger calls, SMS and rotation with commands. That makes the test repeatable. But writing the test, sending the command at the right moment and checking the result still takes code.
The interruption inside the scenario
The sturdiest way is to make the interruption a step of the test. The test reaches checkout, the phone rings, the call ends and the test checks the form is still filled in. The interruption arrives at the same moment every time, so results can be compared.
An interruption testing checklist
- Pick your three most critical flows. Usually login, checkout and a long form.
- Decide the moment in each flow when the interruption arrives. For example, just before the payment button.
- Try each type of interruption once at that moment.
- After each one, check three things. Is it the same screen, is what the user entered still there, did the action go out only once?
- Record every bug you find with video, because interruption bugs are hard to describe and easy to show.
FAQ
Is interruption testing the same as performance testing?
No. Performance testing looks at an app’s speed and resource use. Interruption testing looks at whether the app behaves correctly after an outside event.
Which interruption matters most?
It depends on the app. For apps that take payments, calls and network drops. For form-heavy apps, rotation. For games, calls and low battery.
Is interruption testing on an emulator the same as on a physical phone?
The events the app receives are the same. A call, a rotation or a notification reaches the app the same way. Still, a final check on a few physical phones before release is a good habit.
Do we need interruption tests on every build?
For critical flows, yes. A small change to one screen can make it lose its data on rotation. Run automatically, these tests add no work for the team.
Interruption testing with TestSafe
In TestSafe, interruptions are ready-made steps in the scenario. While the test runs you can make the phone ring, answer or end the call, send an SMS, drop the battery, slow the network or turn the phone sideways. After the interruption the agent reads the screen and checks whether what you expected happened. The result comes back as a video report.
See which conditions can be set on the Device Conditions page.