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.
Join the DZone community and get the full member experience.
Join For FreeLast 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.
- Revise and continuously maintain your test code
- 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.
- Coverage matrix implications: Existing test suites should cover the above new scenario’s on the supported platforms – Device/OS combinations.
- Varying permissions across platforms
- Most apps will require unique permissions that are (hopefully!) being used and required by the app to function (see below visual from iUbenda).
- 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.).
- Compatibility of device/OS features and permissions
- 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).
Published at DZone with permission of Eran Kinsbruner, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
How To Use Pandas and Matplotlib To Perform EDA In Python
-
Operator Overloading in Java
-
Mastering Time Series Analysis: Techniques, Models, and Strategies
-
Exploratory Testing Tutorial: A Comprehensive Guide With Examples and Best Practices
Comments