Read an overview of mobile app testing.
Mobile Interrupt Testing is a form of mobile application testing that deals with the behavior of an application when it is interrupted in the foreground and resumes to a state before the interruption.
Interrupt Testing, on the other hand, applies to any application type, i.e. web, mobile, stand-alone, etc. However, the variety of devices, networks, configurations, etc. makes this form of testing appropriate for mobile applications.
What is Mobile Interrupt Testing?
We all have our daily interruptions in day-to-day life. Consider a real-life example of being interrupted by a call when reading a newspaper. Some of us may notice the call, ignore it and continue to read the paper, some see the call, acknowledge it, and continue reading, a few more might attend the call, and then resume reading the paper. However, in all the above instances, one’s thought process when reading the paper has been interrupted or lost. To translate this to mobile technology, Interrupt Testing tries to find out which behavior your application exhibits when an interruption occurs.
Given below are a few examples of interruptions in smartphones:
- Battery low
- Battery full – when charging
- Incoming phone call
- Incoming SMS
- Incoming alert/push notification from another mobile application
- Plugged in for charging
- Plugged out from charging
- Device shut off
- Application update reminders
- Alarm or calendar reminders
- Network connection loss
- Network connection restoration
This list is not exhaustive and only includes the most common scenarios.
Before we move on let us understand the phrases, ‘application running in the foreground’ and ‘application running in the background’.
The application running in the foreground is the app on which the user has direct control and which will be seen on the smartphone screen.
Background applications are those apps running on the smartphone but on which the user will not have direct control until it is brought to the foreground. Apps running in the background are expected to resume to the last controlled screen/action when called to the foreground.
Usually, an app goes to the background when we open multiple apps and then we toggle between apps based on our need without closing/quitting the app. The app which is in the background will be using the memory of the phone till it is quit by killing.
The application needs to handle the interruptions adequately to meet user requirements. The expected behavior of an app for these interruptions might resemble the following:
- Run in the background: The interruption takes over while the application goes to the background. It gains control after the interruption ends. For example, A phone/WhatsApp/Skype call that you attend while you are reading/playing a game on the smartphone. When the call ends the game or the activity you were involved with, should resume to the state it was in, before the interruption.
- Show alert. Alert disappears, and you work as usual. ‘SMS received’- messages appear in the header. The user does not bother about it and continues working with the application as normal. Other mobile app alerts, such as a new friend request on Facebook or WhatsApp messages, also fall into this category. But if the user decides to read the message, the behavior described in Point 1 is followed. If ignored, the application’s state is unchanged.
- Call to Action: Alarms have to be turned off or snoozed before you continue working. The same thing applies to app update messages. You either have to ‘Cancel’ or ‘Accept’ the changes before you proceed. Another example is that of the low battery alert – You can choose to continue as usual or go into a low power mode (if the device allows it).
- No impact: An example is: if a network connection becomes available and your device connects to it. Also, when you plug your device in for charging, no alert or call to action step is necessary. It will probably do its job while you continue using your application.
Thus, depending on the interruption you are testing for, understand the behavior, and see if your application satisfies it.
Also, the behaviors described above need not be the same for all applications and devices. Be sure to find out specific details about your particular Mobile App.
Now that we understand what Interrupt Testing is and what to validate when conducting it, it is time to talk about how to do it.
How to Conduct Mobile Interrupt Testing
Look at this scenario: Google Chrome or any browser app for that matter has to run in the background when the user receives an incoming phone call.
Would you not call this a functional requirement of the google chrome app? I know, I would.
So, Interrupt Testing is a subset of Mobile Application Functional Testing. And, to conduct Interrupt Testing, you would follow the same Mobile Application Test Frameworks and Tools. It is the skill of the tester to conceive these scenarios. Once done, you would design the test cases and execute them in the same way as any other test. And do not get confused with the interrupt testing with the recovery testing. The recovery Test is to validate the restoration from a failure. Interrupt Testing is not necessarily a failure. It is a mere distraction.
The need for interrupt testing with various scenarios is very much necessary in this mobile app enriched world where competition between similar apps is at its peak. The best app with excellent usability is always talked about, referred to, and chosen by users.
Need help with your mobile application testing requirements? Trigent’s experienced quality assurance and testing team ensure your product is market-ready within stipulated timelines.
