Mobile applications are undoubtedly the most frequently used software nowadays. According to an article in Tamoco, in 2020, mobile app downloads exceeded 175 billion. They exist for all kinds of needs, such as recreation, productivity, and more.
As QA professionals, we must take this reality into account in a quasi-mandatory way. Knowing how the product behaves in the face of certain daily interruptions will determine its usability. Omitting these tests could pose great risks related to the user experience.
What are software interrupts?
Various variables and events can happen while a user is using a product, and software interruption tests aim to simulate these situations in mobile applications.
Some examples include incoming calls, unforeseen shutdowns due to battery failure or issues with the device's hardware, and pop-up notifications.
How should we create the strategy?
When considering the best strategy for conducting functional interruption tests, it is important to prioritize certain interruptions that are considered "standard" or of high severity. This involves simulating scenarios as realistically as possible, such as incoming calls and messages, incoming messages via push notifications, pop-up messages that appear on the screen, and observing how the app is expected to respond.
If you want to make sure you have done good test coverage, we recommend considering the following scenarios and the expected results:
If the user closes an application without "killing" it, the application will continue running in the background. If auto logout is not enabled, the app will reopen where it was last closed, working with the same behavior until the user closes the app. However, if auto logout is enabled, the user will be redirected to sign in upon the first service call.
Receive push notifications and ignore them. The application receives a notification at the top of the screen and then disappears. The app should continue to work as it was.
Receive push notifications, open them, and return to the device. The application is paused, and when you return to it, it restarts in the place where it was left.
Incoming calls. The application is paused, and after the call is answered or rejected, it resumes its previous behavior.
The cell phone is turned off due to low battery in the middle of using the application. The application must work as if it were closed completely, not remaining in the background. The specific response of the application will depend on its type. For example, in applications that have events in progress or are in real-time, if the user's battery dies, the event should resume with the corresponding progress when the user reopens the app. This applies to applications such as those for ordering food or taxis. If the app hasn’t events in progress, the app should show the main screen or login screen (depending on the feature definition).
User connects to a network. Apps should continue to function as they did before connection or when connected.
Connect the data cable to a PC when using the application. Apps should continue to function as they did before being connected.
Conclusion
If there are still doubts about whether Interruption Tests improve software quality or not, the answer is YES. Whenever we carry out tests to prepare feedback on the developed product based on results, we are preventing certain risks before putting it into production and use by end users, which can generate great consequences. It is recommended that these tests be included in the QA test plan that is presented to the client, in addition to being analyzed and validated with the rest of the team.
The speed with which technology and software development have advanced in recent times is very fast, so we must constantly be analyzing our set of interruption test cases to keep them updated.
At Rootstrap, we are clear that these types of tests are always a must to have, and we are open to suggestions and comments to continue improving and contributing to the QA community!
