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.

We all love coding. Don't we?

Give us a new challenge & we will spend nights looking for a solution & automating the same.

We are so occupied with coding, exploring new technologies & tools that sometimes we forget to make the best use of our automation. ‘

How consistently do we run our existing code on the under development builds? What is the impact of app code changes on our existing tests? How can we make sure that the app we are getting for QA is of high quality?

In this talk we will discuss about above mentioned points & more!!.

The end result of the talk will hopefully help drive better quality apps & a fully contented YOU!

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.