Interruption|Interference Testing helps mobile testers identify potential risks associated with the system or user behavior, which might yield unexpected|undesirable results in the event of a flow interference.

Lana Begunova

·

Follow

11 min read

·

Apr 7, 2024

--

Listen

Share

Let’s explore the particulars of Interrupt Testing and ways to implement it either manually or programmatically. This post also features the use of mobile tools, i.e. Appium WebDriver, that help us automate the process, execute tests faster, and deliver a quality app to our users.

What is Interruption Testing & Why Do It?

Why Conduct the Interrupt Testing?

The term interruption is not really comforting to anyone, unless its consequences offer better prospects for the work being interrupted. Any form of interruption in any work is usually deemed unacceptable, as it not only hampers progress but also disrupts the continuity and cadence associated with the task. Although humans can often recall and resume their tasks after an interruption, they do so with a loss of focus and rhythm. However, when it comes to machines or systems, the question arises: can they regain their suspended processes and continue seamlessly?

This capability of a system or software product to recover from interruptions and proceed with its tasks is ensured by interrupt(ion) testing.

• Interrupt testing is a testing methodology employed to observe and evaluate the behavior and response of a software product or system during and after an interruption. This process helps identify potential hazards and issues associated with the system that may lead to undesirable and unexpected circumstances in the event of an interruption.

Interrupt testing is generally categorized as one of the types of mobile testing and is commonly used for testing mobile applications. It can be viewed as a mobile testing type specifically designed to assess the performance of mobile application functions after experiencing an interrupted state. This sort of testing involves intentionally creating disturbances in the functioning of mobile applications and then observing and evaluating their responses.

Types of Interruption Testing

Interruption Testing is a kind of testing that involves simulating various types of interruptions or distractions that a user may experience while using a mobile app. Some common types of such interruptions that might be tested include the following:

Phone Calls

If an app is being used and an incoming phone call is received, it’s important to test how the app handles the interruption. Does it pause or stop functioning? Does it allow the user to continue using the app while the call is being taken?

For example, simulate a call on an emulator with adb:

adb shell am start -a android.intent.action.CALL

Or, simulate a call on an emulator with Extended Controls:

Text Messages

Similar to phone calls, incoming texts can interrupt an app and cause it to pause or close. This type of interruption tests how the app handles an incoming text message while it’s being used and ensures it resumes correctly after the interruption ends.

For example, simulate an SMS on an emulator with adb:

Notifications or Alarms

Mobile apps often generate (push) notifications to alert the user of new events or updates. It’s important to test how the app handles notifications and whether the user is able to continue using the app while the notification is being displayed.

System Alerts

The OS may generate alerts or notifications that interrupt the app. It’s important to test how the app handles these interruptions and whether it allows the user to continue using the app while the alert is being displayed.

System Updates

The system can kill the app process. If the device’s operating system is updated while the app is being used, it can interrupt the app and cause it to close. It’s important to test how the app handles these interruptions and ensure that it can resume correctly after the update is complete.

Low Battery or Power Loss

If the device’s battery is running low or the device loses power, it can interrupt the app and cause it to close. It’s important to test how the app handles the interruption and whether it allows the user to continue and save all the important data while the device is being charged.

Multi-Tasking | App Switching | Multi-Window

Many mobile devices allow users to multitask and switch between multiple apps. It’s important to test how the app handles multitasking an whether it allows the user to continue using the app while other apps are being used. App switching tests how the app handles being switched out of the foreground and into the background.

Device Rotation

This type of interruption tests how the app handles the device being rotated from portrait to landscape and vice versa. We verify if the user progress remains intact during and after the screen rotation. I’ve recently discovered a bug in a mobile e-commerce app, where the E2E user flow could not be completed because the shopping cart element was invisible/inaccessible in the landscape view.

Network Conditions

If the device’s network connection changes while the app is being used (e.g. from WiFi to cellular data), it can interrupt the app and cause it to behave differently. Sometimes, a Wi-Fi signal is strong even if cellular reception is weak. If this is the case, a user may connect to a Wi-Fi network to seek an improvement. To test the quality of cell reception, consider moving to higher ground and trying different locations, as cell tower locations matter. Another good idea is to include various network speeds (4G, 5G, etc.) in the mobile app testing strategy. It’s important to test how the app handles these interruptions and ensure that it functions properly under different network conditions.

Furthermore, it’s wise to re-assess the app network requirements prior to large anticipated events, focusing on commitment to delivering a reliable network experience for customers. For example, the upcoming total solar eclipse on April 8, 2024, like any other celestial event, might interfere with network performance. Network resilience might be impacted in the North American regions depicted in the maps here.

The sites along the path of totality draw the largest crowds. And, while the wireless networks are not affected, the mere surge of network use by both locals and tourists might make a stable connection scarce.

It’s crucial to test these types of interruptions that may occur while the app is being used to ensure the app provides smooth, seamless, uninterrupted, stable and consistent user experience. Consider including load testing in the mobile performance strategy, along with the combinatorics of various network speeds/conditions and battery charge levels.

Language Input

Our developers might operate on a narrow set of specs and make assumptions about the types of user input. In the Think Like a Tester section in my prior post, I’ve covered user empathy as a part of a tester’s mindset in the context of Internationalization/Globalization and Localization Testing. Users from various regions around the world may require Unicode support to accurately complete forms in their native language. The aspects we test are the support for multiple languages, different time zones, various numerical formats, differently formatted text (left→right vs right→left), etc.

Back Button

The default behavior in Android Activities assumes the user taps Back with no expectation of returning to the same instance of the activity. Mobile developers can customize this scenario in accordance with their particular app requirements and specifications. Whichever way we choose to design/develop our app, make sure to test that the system Back behavior is not jarring to the user.

Android Lifecycle Interruptions

A poorly implemented Android Activity Lifecycle can lead to the following results:

• Crashing if the user receives a phone call or switches to another app while using our app.
• Consuming valuable system resources when the user is not actively using it.
• Losing the user’s progress if they leave our app and return to it at a later time.
• Crashing or losing the user’s progress when the screen rotates between landscape and portrait orientation.

It might be useful to combine battery testing with lifecycle interruption testing to observe how the battery is used when lots of interrupts and user inputs are triggered throughout the app.

Test Android App Activities

Android Activities serve as containers for every user interaction within our app, so it’s important to test how our app’s activities behave during device-level events, such as the following:

• Another app, such as the device’s phone app, interrupts our app’s activity.
• The system destroys and recreates our activity.
• The user places our activity in a new windowing environment, such as picture-in-picture (PIP) or multi-window.

In particular, it’s important to ensure that our activity behaves correctly in response to the events described in Understanding the Activity Lifecycle.

Different events, some user-triggered and some system-triggered, can cause an Activity to transition from one state to another. The Activity State Changes document describes common cases in which such transitions happen, and how to handle those transitions.

Manual and Programmatic Interrupt Testing on Android

Performance, Stability, User Scenarios

Stress and interrupt testing is an important part of the mobile testing process. With the aid of tools, mobile testers are able to determine any potential performance or stability issues exhibited by an app. To test our app against interrupts, we can manually trigger lots of notifications to the device while using the app. Notifications can be incoming messages, calls, app updates, or push notifications (software interrupts). Furthermore, pressing the volume up and down buttons or any other kind of hardware button is also an interrupt (hardware interrupt) that can also have an impact on our app.

Alleviate the Burden of Manual Testing

Doing all of these tasks manually is a lot of work and very time consuming. In most cases, these test scenarios can’t be done manually because it is very hard to simulate fast and multiple user inputs with one or two hands. But it can be done with the aid of tools, and it is really easy to integrate them into the development and testing process.

Programmatic Monkey Testing with ADB

For Android apps, a tool called Monkey can be used which is part of the Android SDK (Software Development Kit). Monkey can run on either a physical device or an emulator. While running, it generates pseudo-random user events such as a touch, click, rotate, swipe, mute, Internet connection shutdown, and much more to stress-test the app and see how it handles all those inputs and interrupts.

The package name of the Android .apk file is needed to be able to run Monkey; otherwise it will execute its random commands to the entire phone. When the package name (in this case com.appiumpro.the_app) is available, execute Monkey with adb (Android Debug Bridge):

adb shell monkey -p com.appiumpro.the_app -v 2000

The number 2000 indicates the number of random commands that Monkey will perform. With an additional parameter -s for seed, Monkey will generate the same sequence of events again. This is really important for reproducing a bug that may occur when running Monkey.

The Monkey tool makes it simple to stress- and interrupt-test a mobile application. It benefits the mobile testers, as it helps the team build a reliable and robust mobile app.

Automate Android Interactions with Appium

Performance Metrics

• Appium’s Execute Script Overloading feature allows us to automate practically any kind of Android Debug Bridge command. In the Shell Interactions section of my prior post, I covered automation of ADB shell commands, such as dumpsys battery, cpuinfo and meminfo.

Network Conditions

With the driver.execute_script() function, we can further utilize the Android shell to conduct network testing. For example, we can pass in ADB commands as parameters into the execute_script WebDriver function. The following commands will turn the mobile and WiFi service networks on and off:

adb shell svc data enable
adb shell svc data disable
adb shell svc wifi enable
adb shell svc wifi disable

Device Management

In another post on Appium Device Management, I covered automation of WebDriver Commands, such as:

• Locking and unlocking a device.
• Changing the device orientation — landscape or portrait.
• Testing a hardware keyboard interrupt, i.e. to simulate a gaming scenario.
• Increasing and decreasing the device volume.

Activity Management

Lastly, yet another post of mine goes into the specifics of how to automate Android Activities with Appium. Android apps are not just one monolithic thing. They are collections of smaller divisions known as Activities, as I’ve mentioned earlier. An app might consist of only one Activity, but more commonly there will be more than one. Below captioned are various views of the Android Settings app. Each of these different views is actually a separate Activity which has its own unique name.

That’s a wrap on the Android know-hows and how-tos applicable to mobile Interruption/Interference Testing.

Happy testing and debugging!

I welcome any comments and contributions to the subject. Connect with me on LinkedIn, X , GitHub, or Insta.

If you find this post useful, consider buying me a coffee.