Interrupt Testing in Mobile Application

What is Interrupt Testing?

Interrupt Testing is a branch of Mobile Application Testing that deals with how an application reacts to an interruption and resumes to its previous state. The interruption comes from outside the application — the operating system, the hardware, or another app — and the test verifies that no data, screen state or in-progress transaction is lost when control returns.

Interrupt Testing applies to any application type — web, mobile, standalone, and so on. The variety of devices, networks and configurations makes it far more prominent for mobile applications than for the others.

Why you need Interrupt Testing?

What is the one thing that almost always happens when you are in a meeting? You get interrupted, right? When it happens some people do not 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 phrasing aside for a second and look at another real-world situation. 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.

The business case is straightforward. An interruption arrives at the worst possible moment — mid-payment, mid-upload, mid-form — and a user who loses that work rarely tries again. Crashes on resume, blank screens, duplicated transactions and lost form input are all defects that only an interruption exposes, which is why they survive a functional pass that never interrupts anything.

Type of Interruptions in Mobile Application

Interruptions fall into a handful of familiar groups, summarised in the illustration below.

We are all familiar with the common interruptions that normally occur. Here are a number of them:

• 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
• Alarm
• Network connection loss
• Network connection restoration

This list is not exhaustive but includes the most common scenarios. A practical way to organise it is by origin: device-dependent events such as battery and charging, user-initiated events such as answering a call or switching apps, and external events such as losing signal in a lift or a tunnel.

Resolution in case of Interrupt

The expected behavior in case of these interruptions is one of the following four:

1. 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 or FaceTime call that you attend while you are reading a digital book on iBooks (or a similar application). When the user answers the phone, iBooks waits until the call is done and then resumes when it ends.
2. Show alert: The alert disappears and you work as usual. A “SMS received” message appears 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 a 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 the alert is ignored, the state of the application is unchanged.
3. Call to Action: Alarms have to be turned off or snoozed before you continue working. The same applies to app update messages. You either have to cancel or accept the changes before you proceed. Another example is the low battery alert — you can choose to continue as usual or go into a low power mode, if the device allows it.
4. No impact: An example is a network connection becoming available and your device connecting 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 whether your application satisfies it. Also, the behavior described above need not be the same for all applications and devices. Be sure to find out the specific details for your mobile app.

Interrupt Testing Test Cases with Expected Results

Once the expected resolution is agreed, each interruption becomes an ordinary test case with a trigger, an action and a verifiable outcome. The table below shows how the four resolutions above translate into concrete scenarios.

Keep one row per interruption per critical screen rather than one row per interruption for the whole application. The payment screen, the login screen and a long form each fail differently, and a single generic case hides that.

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 do Interrupt Testing

Look at this statement: iBooks has to run in the background when the user receives an incoming phone call.

Would you not call this a functional requirement of the iBooks app? I know I would.

So, Interrupt Testing is a subset of Functional Testing for a mobile application. To conduct Interrupt Testing you follow the same mobile application test frameworks and tools. It is the skill of the testers to conceive these scenarios. Once that is done, you design the test cases and execute them in exactly the same way as any other test.

In practice the sequence is short and repeatable:

1. List the critical user journeys — login, payment, upload, long forms, media playback.
2. Map every plausible interruption from the list above onto each journey.
3. Agree the expected resolution for each pairing with the product owner, because there is no universal default.
4. Execute the interruption at the riskiest instant, not at an idle moment, and then resume.
5. Verify state, data, session and memory after resumption, not merely that the application is still open.

For more information on the wider discipline, see the Mobile Testing tutorial and the sample cases in Mobile App Testing.

Tools and Techniques to Simulate Interruptions

The scenarios above have to be produced on demand rather than waited for, and each platform provides a way to do that.

• Android Emulator extended controls: The emulator side panel simulates an incoming call, an SMS, battery level and charger state, and cellular signal strength, so most of the interruption list can be raised without a second handset.
• iOS Simulator and Xcode: Connectivity and hardware states can be varied from the simulator and from device settings, while a paired physical device covers the call scenarios that a simulator cannot raise.
• A second physical device: Calling or messaging the device under test from another handset remains the most faithful way to reproduce a real interruption, especially for timing-sensitive cases.
• Device settings: Airplane mode, Wi-Fi toggles, Do Not Disturb, battery saver and scheduled alarms cover connectivity and power interruptions on real hardware.
• Automation frameworks: The same automation stack used for the rest of your functional suite can drive the application before and after the interruption, so the resume check is asserted rather than eyeballed.
• Real-device clouds: A hosted device farm widens coverage across manufacturers and OS versions, which matters because interruption handling is one of the areas where vendor customisations diverge most.

Whatever the mechanism, record the exact moment of interruption in the test case. “Interrupt during upload” and “interrupt after upload” are different tests with different failure modes.

Best Practices for Interrupt Testing

A few habits separate a useful interrupt suite from a box-ticking exercise.

• Interrupt at the worst moment: Target the instant a transaction is committed or a file is being written, because that is where state is most fragile.
• Test the resume, not the interruption: The defect almost always appears after control returns, so assertions belong on the restored screen.
• Cover both directions of a network change: Losing a connection and regaining it are separate cases, and the second is skipped more often.
• Vary the duration: A two-second alert and a ten-minute call push the application through different lifecycle paths, including being evicted from memory.
• Spread across OS versions and low-end hardware: Background eviction is far more aggressive on constrained devices, which surfaces defects a flagship handset hides.
• Automate the repeatable ones: Connectivity and battery interruptions automate cleanly, freeing manual effort for call and alarm scenarios.
• Watch resource use as well as state: An interruption that leaks memory or drains battery on resume is a defect even when the screen looks correct, which links this work to mobile app performance testing.

Isn’t Interrupt Testing the same as Recovery Testing?

No, it is not. Recovery Testing validates restoration from a failure. An interruption is not necessarily a failure — it is a mere distraction.

It is like the difference between a comma and a period in English. The distinction is only technical, but the picture is clear. Recovery Testing asks whether the application can come back after something broke; Interrupt Testing asks whether anything breaks at all when something else takes the foreground.

That is what there is to know to get started with Interrupt Testing — an important and intuitive branch of Mobile Application Testing.

FAQs