Whether talking about native, mobile web, or hybrid applications and regardless if your project is iOS or Android, Appium is the most popular open-source framework for mobile application testing – and it’s easy to see why. And because of that, we’re going to talk about something else.
Everyone knows that Appium is great, but what I’ve noticed is this common knowledge has resulted in more and more people turning to it in blind faith, without fully understanding how to get the results that made it so appealing in the first place.
I want to fix that with these:
- Test using a Cloud Platform
- Device Selection & Fragmentation
- Using one script for both OSs Android and iOS
If you are looking for efficient and cost-effective mobile automation, these not always followed best practices are critical.
Those three best practices are what you have to do. Now, I’ll take you through how and why you should.
Test Using a Cloud Platform – A Change in Mindset
Most mobile application automation is done using a local setup where you have a mobile device connected to a laptop executing the tests, typically in an office where single or, multiple stations are set up as illustrated below.
- Setting up Appium can be tedious and time-consuming, especially for iOS.
- Devices cannot be maintained in a lab-style environment from home as devices need to be periodically reset.
- Loss of network connectivity or downtime within the office cause additional delay and hassle.
- Reliance on remote viewing of the devices can be slow and inefficient.
- The limited breadth of testing and coverage due to not being able to test on many different devices using the local machine.
- Testing bottlenecks – because you can’t execute everything on your laptop.
- Setting up parallel execution requires effort.
And this was just off the top of my head! These challenges aren’t feasible given our current remote work environment. So what do you do?
You write your scripts on your laptop and execute them without worrying about setup, bottlenecks, or limited breadth of testing. And to do that, you need cloud-hosted environments like Saucelabs, Experitest, Perfecto and others.
Personally, I prefer Saucelabs and Exepritest. Here are a few reasons why:
- They offer a large cloud for continuous testing with the industry’s most comprehensive coverage for mobile devices.
- Highly scalable platform for increased parallel execution, decreased execution time, and elimination of bottlenecks.
- Provides complete transparency on your testing efficiency using videos, screenshots, logs and full analytics to determine where gaps may exist.
- Using an integrated development platform makes Appium automation even easier by directly executing Appium tests from Eclipse & IntelliJ, using embedded simple editors and detailed views.
- Offers hybrid support that connects to a local or remote device and uses the device’s reflection for instant visual feedback on device behaviour.
- Use Object Spy, object repository and XPath identifiers to automate complex scenarios. Modify tests and create a complete, robust automated mobile testing project (Experitest).
- Advanced automation capabilities to increase coverage. Test advanced use case scenarios such as barcode and check scanning, audio features, GPS simulation, 3rd party applications (Facebook, maps, e-commerce, etc.) TouchID, or customized elements such as sliders, pickers, tables, gestures, and more.
While I am not a salesperson, this is usually the part of the conversion where the cost comes up for this setup.
You can see that the cost for doing six months of testing on 12 real devices using a local setup is double the cloud’s cost. Why would you pay more to make your life more difficult?
It’s clear that Appium automation on cloud platforms is the way as we advance.
Choosing your devices for testing effectively
While the abundance of device options is great for consumers, this fragmentation is a major headache for developers and testers.
Currently, we have two main OSs for mobile phones, Android and iOS, which seems simple enough until you account for the different models, makes, and versions – especially for Android. It’s not feasible from a time and resource perspective to test all the combinations.
This is why device selection is so critical, and here are some steps to help you narrow down your choices:
1. Visit the following https://gs.statcounter.com/ to get the latest mobile phone stats.
2. Get the mobile device market share, e.g for Canada:
It means that in Canada 50% of people use Apple and the rest use Android devices. It also tells you which devices are mostly used. From the list, select the top 4 devices.
3. Android OS share.
4. IOS share
5. Resolution Share
Based on the information that is available, you can narrow down your list and create the best feasible combination of make, OS, and version.
One Script / 2 OSs
There are many ways to write efficient test scripts. Most engineers follow page models by default which is a good thing. But how do you create one automation script that will work on both Android and IOS?
A properly developed application’s behaviour and logic are usually the same on both Android and IOS. There is no point in doubling the work by duplicating the business logic and developing two scripts, one for Android and one for iOS.
Here is how you can tackle the problem at hand. The following screenshot shows an example of a unified Appium test to calculate restaurant bill.
For a unified test to work on both Android and iOS, the following must be done.
1. The Appium tests need to instantiate the appropriate driver based on the configuration.
2. Use page factory methods to define elements for both OSs and for each page of the application. The annotations AndroidFindBy and iOSFIndBy will help pick the right element based on what OS the test is running automatically.
3. Create methods to implement the test steps. The following method will click on the button to calculate the tip.
4. Call the page methods from the test class to complete the test case.
Take Away
The world we live in has changed and the way we work and the way we test has to adapt. The key is to develop and perform testing with efficiency in the forefront, trying to avoid duplicate efforts and unnecessary costs – that is exactly what the above was intended to do. Hopefully, after this, you be more efficient, more effective, and better equipped to perform automated testing of mobile applications in whatever your new setting is and with the highest ROI possible.
