Parallel Testing using Appium with Devices connected via Wi-Fi

Appium is an open source tool for automating native, mobile web, and hybrid applications on iOS mobile, Android mobile and Windows desktop platforms. Appium is in fact, an HTTP Server that exposes a REST API which receives connections from a client, listens for commands, executes those commands on a mobile device, and responds with an HTTP response representing the result of the command execution.

One of the main advantages of Appium is that it is cross platform and same test script can be used for testing the application on multiple platforms or different versions of the same platform. Considering that a typical mobile test automation has to be performed in multiple platforms and devices, parallel test execution is an essential activity. The steps below describe how automated test execution can be performed in multiple Android devices in parallel.

Pre-requisites:

1. USB debugging should be enabled in the target devices.

2. Appium server, Android SDK etc should be installed in our PC

Let’s find out the steps for connecting multiple devices via Android Debug Bridge (ADB) over Wi-Fi

Step 1: Open the ADB command line Utility

ADB is a command-line utility included with Android SDK. ADB can control your device over USB from a computer, copy files back and forth, install and uninstall apps, run shell commands etc. It is a communication interface between the Android phones and computer. The ADB command line tool can be accessed from the Android SDK folder (E.g.: C:\ …\AppData\Local\Android\Sdk\platform-tools). You can navigate to the folder & open the command prompt from there.

Step 2: Connect your device using the USB cable.

Step 3: Run the adb devices command in the command prompt and the device gets connected.

Note down your device Id or UDID from the listed devices.

We have connected our device to the computer and now let’s move the mobile app apk (of the app to be tested) to the device using the below steps.

Step 4: To install apk:

adb -s install

E.g.: adb -s 71a19ad605 install C:\installs\app.apk

You will get a success message if the installation is successful.

Step 5: Configure ADB for Wi-Fi

Ensure that both the devices & host computer are in the same Wi-Fi network and the device is getting listed in the adb CLI tools (as shown below)



Now we need to connect the devices with TCP/IP port 5555(Since ADB is listening on TCP port 5555) using the command

adb -s tcpip 5555



Step 6: you can disconnect the device from the USB cable and using the IP address of the device we can configure the ADB via Wi-Fi using the following command

adb connect 192.168.1.2:5555

(To get the IP address of the phone, go to settings->Network&Internet->Select Wi-Fi->Settings->Advanced->IP Address)



Now you can execute ‘ adb devices’ command to see that your phone is connected via Wi-Fi. You can connect multiple devices for parallel execution like this.



Step 7: Let’s modify our Appium TestNG scripts for parallel execution

Assuming that you already have a TestNG maven project with the required dependencies for Appium. For executing the Appium tests, Appium servers needs to be up & running. Only one device can be connected to a single Appium server instance and hence multiple Appium servers connecting to different ports to be opened prior to the execution. This can be achieved via the below method which will open the Appium server at the starting of the execution.



IP & the port details are passed from the TestNG xml using the URL parameter. TestNG Xml is modified for the parallel execution as shown below, multiple device details & Appium server details are passed in the XML.



Inside the before method, desired capabilities are set by using the above set TestNG parameters. Using the startAppiumServer method, Appium server is started dynamically before the start of the execution.



You can have your device specific tests in the @Test method. Now we have connected multiple devices via Wi-Fi and configured our TestNG tests for parallel execution.

Quis custodiet Ipsos robots (Who watches the Robots)?

Quis custodiet Ipsos robots (Who watches the Robots)?

Each generation has its cult favorites in terms of Role Models, Superheroes and of course – Movies.

 

Growing up in the nineties, the Terminator Series featuring Arnold Schwarzenegger left an indelible impression on me. Apart from making me a huge sci-fi fan, it also left the lifelong conviction that robots are going to take over the world one day. Now two decades later, recent developments in the Artificial Intelligence space is adding more fuel to these thoughts and compelling me to ask the question: are we really taking extra care to ensure that these bots are performing only the intended tasks and nothing more?

 

Well, it may be decades before we the collective humanity have to worry about Artificial Super Intelligence inching towards world domination, but presently there are another set of software robots which are silently taking over the Business Process World by automating the manual, repetitive tasks that are typically done by humans. The domain and practice of Robotic Process Automation (RPA) may still be in its infancy, but it’s definitely considered a game changer when it comes to Software Automation.

 

Similarities between RPA and Test Automation

 

Having worked on the Test Automation field for quite a long time before progressing to RPA, one of the first things we have realized is the similarity between RPA and Test Automation tools. Even though both these categories of tools are built for different purposes, the underlying technologies and the way they interact with the business applications are very similar. Of course, the RPA tools are intended to be used in production where an entirely different set of capabilities and features are required (when compared to test automation tools which are primarily used in pre-production environments). However, when it comes to script/workflow development, the programming approach followed is similar.

  RPA vs Test Automation  

The RPA tools are marketed in such a way that there is zero or minimal programming involved and most processes can be automated just by using drag and drop features. Whilst it is true that these tools use a visual approach rather than writing plain code in an IDE (Integrated Development Environment), the business processes can get quite complicated with lots of complex logic and data. Therefore, the robustness of the solution largely depends on applying solid programming principles. Also, the process automation using RPA tools is not just the script development, but it also has the design phase, coding phase, testing phase and the maintenance phase or in other words, a typical Software Development Life Cycle (SDLC).

 

When it comes to software development, it doesn’t matter if the programming is done using visual tools or an IDE, the development standards and associated processes naturally come into place. It is also imperative that all the things we create, including the design and scripts are properly reviewed and well tested. Testing should not be an activity that is done as an afterthought, but it should be considered as an important step which helps in determining that the solution is working as expected and that there are no unintended consequences when unexpected scenarios occur.

 

Scalability and Sentience

 

It also helps to think about how these process automation can be scaled, what happens to the scripts when there is a major version change to the business application and how custom frameworks can reduce the maintenance overhead. This feedback control process is required for continuous improvement and scaling. Most importantly, we do need to safeguard the bots’ behavior or in other words have enough checks and balances built into the process to ensure that sufficient watchmen guard the robots so that we don’t get any surprises in the future when the machine attains sentience.

User Experience for Robots

User Experience for Robots

Let’s face it, Robots are here to stay, be it physical robots or software robots. Isaac Asimov saw this coming several decades ago (and hastily wrote down the three laws of robotics, hoping probably that the future generations will take a hint) and we are now just confirming that this is going to be the future.

Robotic Process Automation (RPA) is one area where software robots are adopted successfully and these bots are used to automate repetitive, high volume, rule-based tasks that are done manually now.  For example, if your workflow involves lots of incoming documents which have to be processed based on a set of rules (like invoices) and then keyed in to an enterprise system, RPA bots can do these tasks effectively and efficiently with minimal manual supervision.  This is just one example, there are n number of use cases where we can apply RPA technologies.  Automating such tasks are highly beneficial to the business in terms of effort saved and efficiency gained and the human resources allocated to these tasks could be used for more productive activities.

RPA is not really a new concept and the software test automation teams have been doing this for a long time, albeit for a different purpose. Technically, i.e., in terms of interactions with the application UI, both RPA and Test automation tools are very similar.   Even though features and capabilities of both categories of tools might differ, major challenges of automating applications will be same for these tools.  The success rate of automation generally depends on how easy the tool can interact with the target application (and of course, how robust the scripts are).  For example, if the application has a very rich UI with lots of custom controls and dynamically generated fields, it will be difficult to automate the pages.  At a very basic level, automation is just three steps, viz. identifying the screen, identifying a field or UI element in the screen and performing an action (click, type data etc.) on that field. The easier it is to perform the first two steps, easier becomes the automation.

Keeping this in mind, it is probably time we change the way user interfaces are designed for business systems.  For systems that are used internally and are possible candidates for automation, the UI can be built in such a way that the robots can interact with the pages very easily.  Admittedly legacy systems are not easy to change; however, most enterprises do routine updates to these applications and whenever there is a change made to the UI, it can be applied in the way that the screens and elements are easily identifiable by RPA tools.  For new enterprise level applications, the need of the hour is probably a UI bot or automation standard so that even robots have a wonderful user experience.

Automation World

About Blog Automation World is the leading publication for automation professionals working in discrete, batch and process manufacturing industries. Readers will discover the latest new products and technologies, articles on management issues, Industrial Ethernet, Packaging Automation, and other topics that matter now to automation professionals. Frequency about 4 posts per week.