One of the most important things from the user’s perspective is how the app behaves to interruptions. It is the key to a smooth user experience which is the most important thing for the app developers. Ideally, any app should resume its operation as if there was no interruption. Suppose you are using a food delivery app and while placing the order and filling up the details you get a call. Even if the call lasts for a long time, when you disconnect the call the app in the background should contain all the details that you filled in that particular page. To ensure this, interrupt testing is performed on the apps where different types of interruptions are simulated in different testing environments.
Interruption Testing Scenarios
Interruption testing, like most of the other mobile testing types, can be performed on real devices as well as online android emulator. Here are some common interruption scenarios that might occur during the use of the application.
Incoming/Outgoing call or SMS: This is the most common interruption which happens while you have opened your app. The app is supposed to work in the background while you are attending the call and once you hang up, the app should resume to normal functioning.
Data/charging Cable Removal and insertion: When you attach or detach the data cable there will be a dialog box pop up. This can be a hindrance while working on some other app and once the pop up disappears, the app in the background should resume functioning.
Low Battery: There are pop-ups when the battery is low and in some devices, you will also get an option to get into power saving mode. Now you need to check how the app behaves when the battery low notification comes and the device gets into power saving mode.
Battery Removal: Just open your app, remove the battery and put it back again to check if the app retains all the data or if the app resumes from where it stopped.
Network Coverage: The app might stop or hang in low or no network areas but the app should be working smoothly once the device is in the range of the network.
The application is expected to behave in any one of these ways:
Call to Action: Whether it is a mobile alarm, app update message or low battery alert, the app should come back to the normal functioning once you perform the action. Like in the case of app update you either tap on update or on cancel only after that it will start with the usual.
No Impact: The alerts and notifications like SMS received or clock alarm can come in the header and it won’t affect the app. Even when the devices connect to the network or when connected to the charging cable the notification comes in the header and does not affect the apps functioning.
Run in Background: The app is supposed to work in background when a higher priority activity initiates and come back to usual once the interruption is stopped. for example, while using a calendar you get a call, then you either attend the call or reject it. After any of these actions, the calendar should pop up again with the data that was entered before the call.
These are the common interrupt testing scenarios that occasionally occurs in every other phone. Apart from these, the tester can come up with a set of app/device specific scenarios that might affect the apps functioning. Every app has different functionality and different system requirements according to which the behavior is to be monitored.
Author: Suyash Dubey
Author Bio: He is a content strategist working with pCloudy. A writer by day and a reader by night, he is determined to share knowledge and help people to get familiar with the latest technology.
Content is interested: