What is the one thing that almost always happens when you are in a meeting? You get interrupted, right? When it happens some don't even blink, some need a minute to get back, and some lose their train of thought completely. In simple words, Interrupt Testing tries to find out which behavior your application exhibits.
Keep all terminology aside for a second and look at another real-world situation. Let's say you own a flashlight and turn it ON. The battery runs out, which is an interruption to its current state of being active. Replace the batteries and restore it. The flashlight should come back ON as normal. This is the use case. A discipline of testing that focuses on whether this happens or not is Interrupt Testing.
Interrupt Testing applies to any application type- Web, Mobile, Stand Alone, etc. The variety of devices, networks, configurations, etc. makes it more prominent for Mobile applications than the others.
To define Interrupt Testing formally
It is a branch of Mobile Application Testing that deals with --how an application reacts to an interruption and resumes to its previous state.
We are all familiar with the common interruptions that normally occurs.
Here are couple of interruptions:
- Battery low
- Battery full- when charging
- Incoming phone call
- Incoming SMS
- Incoming Alert from another mobile application
- Plugged in for charging
- Plugged out from charging
- Device shut off
- Application Update reminders
- Network connection loss
- Network connection restoration
This list is not exhaustive but includes the most common scenarios.
The expected behavior in case of these interruptions is one of the following:
- Run in background: The interruption takes over while the application takes a back seat. It gains control after the interruption ends. For example: A phone call/Facetime that you attend while you are reading a digital book on iBooks(or similar application). When the user answers a phone, iBooks waits until it is done and then resumes when the call ends.
- Show alert. Alert disappears, and you work as usual. 'SMS received'- messages appear in the header. The user don't bother about it and continue working with the application as normal. Other mobile app alerts, such as a new friend request on Facebook or WhatsApp message, 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. Same thing with App update messages. You either have to Cancel or Accept the changes before your 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 behavior described above need not be the same for all applications and devices. Be sure to find out specific details about your 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 is Interrupt Testing conducted?
Look at this statement: iBooks has to run in the background when the user receives an incoming phone call.
Would you not call this as a functional requirement of the iBooks app? I know, I would.
So, Interrupt Testing is a subset of Functional Mobile Application 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 in the exact same way as any other test.
For more information on Mobile Application Testing, check out:
Finally, I want to address one more question before we end this article:
Isn't Interrupt Testing the same as Recovery Testing?
Nope, it isn't. Recovery Test is to validate the restoration from a failure. Interrupt Testing is not necessarily a failure. It is a mere distraction.
It is like the difference between a comma and a period in English. But, only technical; I am sure you get the picture.
That's right, all is to know and get started with Interrupt Testing - An important and intuitive branch of Mobile Application Testing.
This article is contributed by Swati Seela