In today’s agile world the time to market is becoming increasingly shorter. There is a constant desire to release ASAP to keep ahead of the competition and to please users with updated/new features. Because of this, we have less time to fully do manual and exploratory testing of our apps. Especially, when you consider all the combinations of OS's, Locales, Accessibility, Orientations & Resolutions apps support. Running anywhere from 1 to 100's of Appium crawler bots (covering all of those combinations) at once we can discover more issues quickly and efficiently without having to write a line of code.

UI Automation also has its limitations as it only tests for expected results. Crawler bots test the unexpected, by collecting metadata such as logs, app strings, screenshots, memory and reporting back it’s finding for review so we can test all these combinations quickly and more efficiently. In this talk, I will go over the current challenges we face in today's development world, why we need more tools to help us keep pace, and cover how you can build your own Appium crawler.

I've open sourced this tool and is available here for everyone to use: https://github.com/isonic1/Appium-Native-Crawler

Apple and Google’s test automation framework does not natively support W3C standards for few web driver spec implementations directly for e.g TouchActions interface in XCTest, etc. Although test automation frameworks support a rich set of those functions specific to platforms, Appium does provide ways to directly invoke these functions e.g gestures, biometric handling, etc.

Many special behaviors and workarounds are made available and achieved only through executing platform-specific native commands of Appium. For instance, there are 100+ issues been reported on date picker or handling picker wheel in the appium organization but it can be achieved quite easily by executing native mobile commands.

There are so many that testers might not get chance to go through each one of these and get acquainted with all of those. Native mobile commands help to handle much complex use cases like biometric handling, talking to Siri, performance profiling, etc quite easily.

Appium has so many desired capabilities! How many exactly? Let's count!

Join Appium contributor Jonah Stiennon as he iterates through every desired capability supported by Appium.

Many special behaviors and specific workarounds are made available only through desired capabilities. Often the key to selecting an element reliably, launching an app, or avoiding a timeout, is picking the right set of desired capabilities. There's so many that testers don't get the chance to sit down and become acquainted with them all.

There's too many to easily memorize and documentation can be sparse. Jonah will introduce novel ways to classify, visualize, and organize all of the desired capabilities, making it easier to find ones which can be useful.

Appium is a world's most popular open source mobile test automation framework developed using WebDriver protocol and I am fortunate enough to get a chance to contribute to appium-uiautomator2-server and appium-uiautomator2-driver modules.

The goal of the session is to help the Appium community to have a better understanding of Appium and how it works.

In this session, I will be discussing Appium architecture specifically towards its Android modules(UiAutomator2 and Espresso), how the communication happens between Appium modules and how to add new handler/API in appium

Every command you write using Appium Client Library will be converted to JSON Wire Protocol over HTTP which in turn will be passed to the drivers(AndroidDriver, IOSDriver). The respective driver doesn’t just send or execute the command directly on the device. Appium has a Lifecycle of modules which sends the command to the devices.

Abstract:

The goal of the session is to help the Appium community to have a better understanding of Appium and how it works internally.

Will discuss on following aspects:

• What happens under the hood when the session is created, mainly how appium connect to the corresponding device, installing the app, launching the app and the different steps involved in the process.

• Command life cycle - How client request converted into an HTTP request, how received request passes through appium drivers(ios-driver & AndroidDriver) and the respective driver don’t just send or execute the command directly on the device. Appium has a Lifecycle of modules which sends the command to the devices.

• How the final response passed to the client through different layers.

When we speak about Android automation, the first thing that comes to mind is Appium, however, what if Appium doesn't serve all your Android automation needs, at least not in the most efficient way?

When I was asked to create a test automation framework for our android service (no GUI), I needed to choose the right tool for the mission. After several weeks of researching many options (both commercial and open source). I realized that ADB is my best call because of the following reasons:
• ADB provides a faster to run solution for controlling an android device
• ADB is in a lower level of Android OS therefore it's more flexible
• ADB is going through less code components (like appium client, appium server etc..) and as a result is more reliable

In this tutorial I will share my journey towards deciding to use Android Debug Bridge when it comes to non-gui android application and how I have implemented my choice.
After this tutorial, you will have a better understanding of what is ADB, how it works, and how you can start and apply automation for the Low-Level layer of Android OS with ADB and Python.

How many of you have written a negative play store review? Did you get a response back? In how much time? Was your query resolved?

How would you like if you got a quick response to your comment (say within 15 mins). Your query is then tracked & you are provided a quick resolution. It would be fabulous. Right? Absolutely!

As user base of any Application increases customer satisfaction becomes a key factor in order to maintain an upper hand among your competitors.

Most companies have dedicated teams to reply to Play Store reviews but as the number of reviews increase there is no way to keep a track of it.

By using Google Play Store Reviews API's we have automated logging of these reviews into JIRA. For each negative review a JIRA ticket is created & assigned to the customer support team within a few minutes for their follow up. In case a Bug/Suggestion is valid the JIRA Ticket can then be assigned to the concerned department who can take action on them.

Using JIRA, the reviews can further be categorised to find out areas we can improve upon.

In this talk we will explain how we can build an ecosystem using some Google & JIRA APIs to enhance the overall app user experience.

What to do when your tests fail? Read on...

Retry your test case on Jenkins:

As much as we want to keep user interface tests free of failures, timing issues and page element errors pop up from time to time in automated UI checks. If not a test bug, these often reflect the nature of the app under test, its behavior under certain conditions like the internet connection or the machine slowing down suddenly or the page not loading properly. Such errors can be annoying in tests and if we ever want to continue using them, we’ll have to re-run them some of the time to make sure that errors do exist.

Send slack notifications

Using Slack for official communication? How about getting notified about execution details instantly through slack. Sounds interesting. Right?

Send SMS from Jenkin

Need a reminder for re-setting a soon to expire password in your automation code?

Using library you will be able to get updates of your test case execution instantly. You can receive error or failure reason on SMS so that action can be taken proactively.

Rebuild the job

We can define certain rules using jenkins so that in case our tests fail more than the allowed threshold, say X%, we can rerun the suite to rule out any environmental issues.

In this talk we will be discussing the implementation details of the above points so that you know what you can do when your tests fail!

We will be discussing about an automation framework that is designed to be configurable so that we can choose a subset of devices to run automation on. We can choose to run the tests simultaneously on all selected devices Or in distributed mode using selenium grid. Additionally all of this is integrated with our own device testing farm which we can use for manual testing as well as for executing Appium tests

We have used STF (https://openstf.io/) for setting up the device farm and have integrated it with our automation setup such that it is seamless to work on. Appium servers are started at runtime according to the requirement. Even the grid setup is dynamically done based on the selected mobile devices.

Port Independent execution

As we know, by default Appium server is running to port 4723 for your test application while creating driver. But what will happen if the port is not free or port 4723 is not open on localhost (127.0.0.1/0.0.0.0)?

For such problem, we will discuss how yo use java classes to fetch the free local ports and use them when the default port is not free.

Platform version independent framework

When we trying to run our android execution on old Appium version e.g. 1.5 or 1.4 for old Android platforms then the execution not works for the latest android versions. Then in such case we can install and switch between multiple versions of Appium without the hassle of regular install and uninstall of Appium versions.

Deep Links in execution

Today, one of the main concern in Appium is that execution of test cases is slow due to which the overall test execution takes too much time. To overcome this problem, we can implements the deep link or you can say shortcuts within the codes so that functional testing frameworks can execute faster.

In our daily test cases execution we have to perform login action in app step by step to test any functionality which took around 30sec to 1-2 minutes of time. We can reduce it by simply deeplink the login using login api and perform the further actions. This will help in overall test case execution time.