We all know that mobile apps can never be fully tested. There are too many devices, too many OS versions, and too many different types of apps. Testers continue to struggle with developing test plans and test cases the same way they did with traditional applications. How do testers determine the correct scope of testing for an app to minimize quality and security risks for users and the organization?
First, look at organizational expectations. Does your organization expect its software to work almost perfectly? And does it fund and support development and testing to make that a realistic expectation?
If the answer to the first question is yes, but the second one is no, then the best you can do is set realistic expectations that may not be in line with what the organization wants. If quality isn’t a high priority, then testing can be focused on high-priority areas only.
Second, is the app business-critical? Does the organization depend on it to make money, service customers, or be more agile? Or is it a marketing or public relations tool? Does it provide valuable information to users, or is it simply nice to have? If it is business-critical, then flaws could hurt the bottom line and quality become a higher priority. And that’s true in all parts of the app, not just it’s operational aspects. If users find poor quality in any part, they are unlikely to trust it to do business.
Third, consider the implications of a flaw to both use users and the organization. A game or other entertainment app often has a high threshold of failures before most users think it’s not worth the effort. Likewise a free app with limited extrinsic value.
But if the app performs an important function, or one that is counted on my users, a major flaw can have serious or even disastrous effects. One example is the infamous iPhone time change bug in 2010, which failed to move from Daylight Savings Time on the appointed day. Thousands of people were reportedly late for work or appointments as their alarm failed to go off on time. It was an iOS flaw fixed by Apple a few weeks later.
Fourth, does the app use external services? Many apps make use of other services within the enterprise, or commercial services for information such as weather or sports scores. While testers don’t have to test the services, testers should read and understand what the service level agreements (SLAs) say about performance and capacity, and periodically test to make sure those are being fulfilled.
Now About Security
It goes without saying that security flaws are also quality flaws. But many security flaws may have significant consequences to both user and organization. If there is no data, or trivial data, to protect, security testing may not be important. If it includes names, email addresses, or financial data, or any other identification information, that data needs to be protected at all cost.
In particular, testers have to know what data is being collected, and where data is stored. On mobile devices, that can sometimes be a challenge, because it can be in internal storage or on a SIM, and it may not be readily apparent that data is being stored, and in any case often can’t easily be accessed.
In the era of hundreds of different devices and OS versions, as well as BYOD, it’s unrealistic to limit the kinds of devices that an app can be used on, even for internal users. Testers have no control over the device or OS for testing or deployment purposes, and testers simply can’t test all combinations.
But teams likely have control over how and where the device stores data locally. And they have control over how data is transferred to and from the device, and how it’s stored on the back end. That’s what testers have to focus on. Is any personal or identification data encrypted on the device, and is it encrypted during transmission?
Testing on mobile devices requires a combination of techniques, from traditional test cases to risk-based testing to device farm testing and if appropriate, crowdsourcing. The test plan should be designed to use these techniques to test different aspects of the application. Test cases, for example, can test traditional quality measures as well as security. Device farms can be used for in-depth testing of popular devices.
Overall, test results should provide a clear picture of the quality of important aspects of the app given its purpose, and an overview of quality in general.