Over a million developers have joined DZone.

Android Privacy Policy May Break Your Test Automation Scripts

DZone's Guide to

Android Privacy Policy May Break Your Test Automation Scripts

Google made an announcement last month that might affect your Android app's status in the Play Store as well as your test automation scripts.

· Mobile Zone
Free Resource

Download this comprehensive Mobile Testing Reference Guide to help prioritize which mobile devices and OSs to test against, brought to you in partnership with Sauce Labs.

Last month, Google announced its plans to purge play store apps that do not include a privacy policy and the app required security permissions upon app installation.

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).

Analysts agree that a mix of emulators/simulators and real devices are necessary to optimize your mobile app testing - learn more in this white paper, brought to you in partnership with Sauce Labs.

scripts ,android ,mobile ,application testing

Published at DZone with permission of Eran Kinsbruner, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}