Interrupt testing takes into account the disturbances caused of interruptions and suggests practical solutions to keep the user experience smooth throughout the use cycle of the application. Ideally, in case of an interruption the application that is interrupted should enter a suspended state and restart as soon as the interruption ends. But before we get into that lets start by understanding what goes wrong with an interruption.
What’s the problem with interruptions within a mobile application?
For the purpose of illustration let’s imagine that you are using your mobile phone to record your baby’s first steps and just when the baby was off his feet your mobile goes into automatic screen lock!
Ideally, the camera app should prevent the screen from going into lock when it is in use. But sadly, that is not the case. Similar irritating instances arise when you are recording a meeting in progress and then suddenly the screen locks off closing the voice recorder app along with it. Text messages or mails during a game spoils the fun of the game.
Here are a few very common interruptions that people deal with every day:
Incoming and outgoing SMS/MMS/calls
Battery/cable insertion and removal for better uses
Network outage and recovery
Switch off/switch on of the media player and other connecting devices
Low memory warning
Below Few expected behavior in case of interruptions occurred in mobile:
Run in background:
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.
Some specific scenarios for application using network :
1]Connect to network but remove LAN connection from router so device can sense wifi state on device but cannot connect to internet
2]Connection via VPN and VPN disconnected
Scenario for Application using services :
1]Kill service by clicking on recent button and swiping the application right to kill app and services
2]Kill app using third party App killer
3]Kill specific services from Settings->Manage Applications
Manual testers can simulate a lot of these situations and suggest how the app should behave and also the best ways to circumvent interruptions. While some events can be emulated, most need real device testing. Interrupt testing helps in understanding key external factors which causes disruptions and find great ways to keep user experience seamless.
Manual testers check for several usability, compatibility and performance issues. Unfortunately interrupt testing isn’t as common a procedure as it should be. Only the very best software development companies have this in their scheme of things. It is necessary that all interruption scenarios be tested during an application development lifetime on priority.