Android Privacy Policy May Break Your Test Automation Scripts

Behind that requirement, Google is trying to provide its users maximum transparency on what the app is requiring, and what data it collects when users consume the apps.

An example for a native app that already implemented that requirement is StateFarm insurance, see below:

So, with that simple request to mobile Android app developers, there are few quality implications.

1. Revise and continuously maintain your test code
   1. The above screen obviously was not planned for in the latest test automation cycle, which means that a new cycle will get stuck and fail since this is a new screen with a request for a user action. Teams ought to develop new test steps that upon initial app installation would test the following: when the user Clicks Accept the app launches successfully, or that the app closes when users Click Decline.
   2. Coverage matrix implications: Existing test suites should cover the above new scenario’s on the supported platforms – Device/OS combinations.
2. Varying permissions across platforms
   1. Most apps will require unique permissions that are (hopefully!) being used and required by the app to function (see below visual from iUbenda).
   2. Different OS versions of iOS and Android might behave differently and support different security features like in Android 6.0 and above (Doze, Permission groups, etc.).
3. Compatibility of device/OS features and permissions
   1. What happens in regards to the above once an app supports even a normal related permission, e.g. USE_FINGERPRINT? This permission, since it resides in the normal group, will be automatically granted to the user.What if the DUT (device under test), however, does not support this feature? How are teams differentiating in an automated way the test execution with regards to the device capability? Matching the device features and the test case as part of a dynamic test execution can be a powerful Agile capability, especially in the growing, fragmented mobile market.

As seen in the above, from a testing perspective, Android apps that support “Dangerous Permissions” would require the Dev/Test teams to develop and validate a varying use case or device/OS behavior test case when tested on Android 6.0 and above compared to Android 5.1 and below (e.g Android API level < version 23).