Mobile App Testing Theory

Introduction:

Given the wide variety of conveniences and functionalities that mobile apps provide, they are now a crucial part of the mobile ecosystem. Unfortunately, most apps are buggy. The main reason is that they must be able to handle a wide variety of system configurations and user interactions. An application should switch to the background at any time while its state is being restored, and then continue as if an interruption had never occurred. The mobile operating system is enabled to kill apps in the background to save battery power, while apps should automatically save their current state.

Testing such actions takes time, and testing them on many device configurations takes even more time. Most bugs and vulnerabilities are attributed to mobile devices. But this may not be the case. Mobile apps can harbor bugs and vulnerabilities alike, and serve as prime attack vectors. Some of the factors for mobile app vulnerabilities are poor data storage practices, malware, lack of encryption, and sideloading.

During testing, errors found may seem small and insignificant, but further investigation may reveal larger inconsistencies. To find vulnerabilities and bugs in mobile apps, answering the following questions can help.

• Does the application work as specified in the requirements documents?
• Does the app work beyond specifications?
• How does the app perform when used for a long time under constant load? How is it supposed to work under such conditions? If its performance is not optimal, what are the reasons?
• Is the data secure?
• What are the app’s third-party integrations?
• How does application redirection occur? What is the data transmitted in this redirection.

Common testing activities:

• Check the crash reports.
• To test an application, all states of the application must be monitored. Collect all available actions in the app and perform the actions in the app.
• Generate a clean boot emulator snapshot repository per configuration. By checking to launch an application for the specific snapshot instead of starting an emulator from scratch. Test multiple executions of the application by reusing the same instance of the emulator. This approach reduces setup overhead and ensures more testing time.
• When executing possible executions of an application, it is more productive to decide the next action yourself. This gives you more control over the exploratory testing process and has the best chance of catching bugs.
• Often an input is required to move from one point to another. This can be achieved by leveraging an input generation component that generates inputs based on specified rules.
• The record and replay technique is a good way to trace a corresponding fault.
• A bug can manifest itself by causing many redundant bug reports. After collecting test reports from all servers, filter the redundant report based on failure type.
• Unzip the application and parse the .xml file to find the necessary information, identifiers, library dependencies, and startup activities. Use this information to start the application.
• Check what happens when the mobile device is full of data and devoid of all data.
• Uninstall the app and review the data. Reinstall and check again.
• Work in different time zones and at different times.
• Use invalid data.
• Use duplicate data.
• Effect of data update on other services
• Check if the errors conform to good practice. Checks the status of the user after an error is generated.
• Try on a new phone and on an old phone.
• Consider crowdsourcing testing.
• Always check that what users see is correct.
• Check application with variable connectivity, OS updates.

It is recommended to test the mobile app after each launch. A set of priority tests can be defined and should be covered under a variety of conditions.

Testing is primarily viewed as a completely logical process, test scripts and test plans, pass and fail, red and green indicators. A good test is about asking challenging and direct questions. Ideally, testers are supposed to have all the information about what and how an application is being developed. But in practice this is not the case and testers must do what is at hand. Information needed for testing can be obtained from many internal and external resources. Based on the information collected, a test approach can be planned.