Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Mobile Test Automation Using Common Denominators

DZone's Guide to

Mobile Test Automation Using Common Denominators

Automating tests for mobile apps is complex due to device fragmentation and other factors. Here's a method using common denominators that will allow you to save time.

· Mobile Zone ·
Free Resource

It's no secret that the complexity of automating tests for mobile apps across the growing number of devices is one of the biggest challenges and a blocker for faster release cadence.

The mobile space is constantly split between 4-5 Android operating system families (4.x - 8.x) and 3 iOS operating system families (9.3.5, 10.3.3, 11.x). Each OS family has its unique APIs and capabilities, and same goes for the newer vs. older smartphones/tablets.

The outcome of the above fragmentation is a disjointed test automation suite where for some devices/OS combination the app behave in a certain way, while for other devices the behavior is different.

To make the point clearer, let us examine what a typical login into an app looks like across common iOS smartphones and tablets:

Image title

Looking at the above table, we can see a variety of options to login into an app - either through the old-fashioned user/password, or through Fingerprint, or with the latest devices - using Face-ID.

Automating a single Login to an app that covers all of the above will be a challenge to do especially using today's open-source frameworks, and also keeping up and maintaining these scripts as new devices are launched will also be an issue.

In the past, I offered a way of scanning property files like Info.Plist for iOS and Manifest.MF Android to understand the device/OS supported features and APIs and based on the scan to determine which test runs against which device.

I believe that there is a much more simple approach, and this is by using a common denominator to automate the Login function (or any other complex scenario - e.g. using Force-Touch).

If we look at the table, the only method that is common across all platform is the login using a user and password. That should be the de-facto option to test the majority of the test cases for the entire app. The remaining options to Login that uses Fingerprint and Face-ID, should be tested in a very dedicated way just to assure that such option works only on the target devices in your device lab.

Bottom Line

In an agile workflow, where time and resources are limited, having an optimized approach to testing can be a great way to keep up with the release cadence, without compromising on quality. As proven above - using the simple common-denominator approach, we keep the test coverage high by testing on all the iOS device generations, using all supported methods, but we use a common Login method for the large regression suite. This approach can and should be applied to the set of unique features that are available in today's mobile space such as Login methods, Force-Touch, Battery Doze, Split Window, and more. 

Topics:
mobile ,test automation ,ios ,android ,mobile testing ,device fragmentation

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}