Mobile computing is omnipresent today. All organizations have a mobile face. In fact many, often times, have just a mobile face. Even leaders, such as Flipkart were contemplating on just a mobile rendering a few years ago, although the web element is still available.
This trend will only rise making mobile testing and associated mobile testing services, inevitable. While for the most part there is a lot of overlap between web app and mobile app testing, the latter brings in its own nuances making it necessary to have a solid mobile app testing strategy. For example, the kind of things to test from a UI angle, rendering angle, performance over networks, are all different in case of a mobile app. While functionality for the most part, especially in terms of workflows remain the same, whether it is a mobile app or rendering on laptops and desktops, specific parts are either more important or less important in a mobile rendering. For example, for the most part the core workflows remain the same; however let’s take the case of accessibility. As for compliance to standards, while the same for the most part, mobile testing brings in a lot more new elements such as mobile interaction options (this includes touch, gesture, speech etc.) and WCAG 2.1 covers for these extensively. Similarly even within the scope of functional mobile testing services, there are specific areas, which hold specific significance. Interrupt testing is one such area.
Back in the days, compatibility testing, mainly focusing on OS/browser testing was an important piece of an overall test effort. Then came in a phase where app testing strategy had to account for co-existence of applications as part of compatibility testing. For example, anti-virus software, any other software that was in an active mode on the desktop and whether they had any influence in the functionality of the app under test (AUT) was one area, testers included in their scope. However this was not that critical, until we entered the mobile app testing space. By the very nature of mobile computing, it is a given that several active applications co-exist. In the process, when one core application is being used, another may interrupt – this is a very common scenario. How should the AUT respond in such a scenario, what happens if multiple interrupts come in at the same time from functional and non-functional standpoints, are all ones that deserve an important seat in the overall app testing strategy. For example, I have faced this issue several times where when I am on a Zoom meeting/call, and get another phone call, I get faded out of my Zoom meeting and I will have to reinitiate the audio connection post responding to the phone call. This is especially inconvenient when you do not want to take the incoming phone call and instead continue on your Zoom meeting.
There are multiple ways, interrupts can be handled – these include, an interrupt in the background, in the foreground as an alert, something that requires a call to action or something that does not need any action at all. Also, the interrupt itself may be initiated by an external trigger such as an incoming phone call, SMS, notification on mail or social network; or it can be internal such as alarms, battery outage etc. Outside of the AUT, the interrupt may also be dependent on user settings – such as vibrate calls, call volumes, turn off notifications etc.
Type of interrupts, number of interrupts, response to interrupts, impact on functional and non-functional aspects of the AUT are all points to keep in mind as part of the mobile app testing scope for this space.