Dan was selected to speak at Selenium Conference 2012 in London about an entirely different topic. As part of his presentation, he showed off iOS Automation using Selenium syntax to demonstrate writing platform-agnostic tests that use separate platform-specific page objects with a common interface. To his surprise, the cool test architecture would take a backseat to the spectacle of iOS tests running like WebDriver tests. Several people suggested that he give a lightning talk later in the conference to explain exactly how it worked.

On the second day of the conference, Dan stepped up on stage to give the lightning talk. Jason Huggins, co-creator of Selenium, moderated the lightning talks. Dan experienced technical difficulties getting his presentation to load, and Jason nearly had to move on to the next lightning talk. At the last moment, the screen turned on and Dan jumped into his presentation. He explained the details of his implementation and how it worked, begged for contributors, and in five minutes it was over. The crowd applauded politely, and he left the stage.

If we look at how Appium came into existence, lightning talks are a very important part of this journey. Hence at Appium Conf, we would like to dedicate a full session with all attendees on Lightning talk.

Appium hit the open source stage almost 7 years ago and has gone through many iterations of development since then. In this talk, we'll look at how Appium continues to grow, and how the Appium devs are working to ensure Appium's relevance for the future.

The world of testing is rapidly changing. It's not just about functional correctness anymore: UX testing, performance testing, visual testing, and no doubt several other kinds of testing have descended upon us. Tools and methodologies have also proliferated—image analysis, AI, and other new terms give us pause. What will testing even be like in 5 years?

I don't know the future, but I know that Appium's philosophy and development methodology are well-suited to ensuring Appium adapts to whatever the testing ecosystem becomes, and I'll give examples both of how Appium itself is evolving to take advantage of new technologies, as well as how Appium's own ecosystem is growing (through a proliferation of Appium-related vendors and products). And of course, we'll save a bit of time for something … interesting.

Don’t worry, the Terminator is not coming for you or your job. But you might need a Terminator someday to test your mobile app. Desktop and web development happen in a relatively constrained environment: keyboard and mouse for input, video for output — easy to virtualize and test anywhere, locally, or in the cloud. However, with mobile apps, running tests in a simulator can sometimes be hard or impossible. There are more parts involved (e.g. touchscreen, physical buttons, camera, Bluetooth, WiFi, etc.) and the possible interactions can complicate a team’s ability to automate end-to-end test scenarios (e.g. receiving a call or text, taking a photo, controlling a Bluetooth device, making an NFC payment, etc.). In those hard-to-automate situations, a robotic device that can emulate human interaction can be a good option.

In this talk, we’ll go into more detail on why teams might want to make their own robotic mechanisms, and how they can do it without “terminating” their budget or schedule.

Using Javascript, Ruby, Appium, and some off-the-shelf hardware, we have built our own credit card swiping robot; it has opened up a plethora of testing possibilities for our Register app.

Shopkeep is a point of sale software company. We use Appium for testing our iOS and Android apps. One of the biggest limitations of our automation suite was that we were unable to test our hardware, including the credit card readers our mobile app interfaces with.

To overcome this limitation, we came up with a solution to create a simple robot and attach it to a web endpoint. Making simple HTTP post requests, our credit card swiping robot can now swipe cards on the credit card reader. After going through certain iterations in the development of this prototype, we are now creating robots for testing chip card insertion, as well as contactless/NFC based transactions.

This talk will cover the different components that this robot is made up of. We will also look at the challenges we faced and how we integrated this solution to our Appium automation suite. Our talk aims to inspire you to think of what real, physical objects you can test using a similar solution.

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.

Nowadays, more and more companies are building test automation frameworks based on WebDriver and Appium for testing their web and mobile projects. A big part of why there are so many flaky tests is that we don't treat our tests as production code. Moreover, we don't treat our framework as a product. In the talk, you will see examples of how you can automate the testing of your test automation framework and be sure that it is highly reliable. You can get lots of ideas for various types of tests such as learning tests verifying that 3rd party dependencies are not breaking the code, compatibility tests checking that the UI components are working for each mobile control on each OS, cross-platform verifications for testing whether everything is working on multiple OS. Sample test environments for storing different distributions of the framework packages will be presented.

It is predicted that till 2025 there will be over 75 billion devices spewing 180 zettabytes of data and generating up to 6 trillion dollars. That enormous increase force companies to introduce a continuous approach to deliver the product as fast as possible and be able to compete on the market.

The main question is how to test application for end user among so much hardware equipment and ecosystems combining HW, FW, mobile devices and complex backend architecture? Considering all factors and possible obstacles is it for companies a real “A New Hope” for companies or just simply “Mission Impossible”?

I will take the participants on a journey to the IoT world. It will be a talk about the challenges that any tester will face at some point. I will present the dangers, risks and snares but also good practices and practical approach to mobile E2E test automation for the IoT solutions in CI approach.

Technical examples will be presented using Python languages and supported by physical devices (mobile phones and IoT equipment).

GUI and functional tests determine if the product is working correctly from an end user perspective. With increasing number of automated GUI tests we would want to automate when and where they are executed. Continuous Integration helps in merging code to a centralised repository frequently and find out issues early in development cycle in order to help push quality upstream.

In the talk, you will see examples of how you can setup CI system for Android and IOS native/hybrid apps and how to plugin your Appium tests in the pipeline using Jenkins. We will also talk about the challenges we face while setting it up for Android and IOS applications. We will also talk about how to strengthen your CI pipeline via integrating various tests and Static code analysis tools.

We all know that Appium can do (almost) everything what you tell it to do, but in the end we always ask it to do the same thing. We ask Appium to automate our happy and or our error flow. The result can give us the confirmation that the user can still buy a product, or verify if his bank account still has a positive balance.

But what if we need to know more than that - what if we also need to verify the layout of our app? The answer would be easy, as there are plenty of open-source or paid solutions that can help you with that. However, almost all of these solutions focus on web/hybrid apps, not on native iOS and or Android apps.

I faced this challenge when I was automating a React Native app for my customer. There was no image comparison tool that could do what I wanted it to do, so I rolled up my sleeves and started building my own. In this talk we’ll be walking down the path I’ve been taking and I’ll explain:

• Why I used ResembleJS as my core visual comparison solution
• The things I’ve learned about Appium in the process (pro tips!)
• The differences between iOS and Android and how I managed to solve this in one cross-platform solution
• The pros and cons of my solution

Every second, a million minutes (17,000 hours) of video content will cross global IP networks by 2021, according to Cisco (via Forbes). As it stands today, over ⅓ of online activity is spent watching video. However, there is a unique challenge testing video applications because they tend to run on a wide range of platforms - mobile and tablet, streaming devices, consoles, and Smart TVs. Today, it also demands on individually testing the app on each and every device - highly inefficient and a real pain.

At You.i TV we have developed an Appium Driver that allows us to use the power of Appium to test C++ and React Native video applications built with our You.i Engine One SDK on a wide range of platforms including iOS, Android, tvOS, Android TV, PS4, XBox One, Samsung Tizen, LG WebOS, macOS, Linux, Windows simultaneously - an industry first.

This talk will focus on the journey and learnings we discovered along the way - including writing a custom Appium Driver and automation layer, the unique needs of 10-foot devices (remote controlled), and the power we see in combining Appium with React Native.

Experimentation and quick feedback is the key to success of any product, while of course ensuring a good quality product with new and better features is being shipped out at a decent / regular frequency to the users.

In this session, we will discuss how to enable experimentation, get quick feedback and reduce risk for the product by using a case study of a media / entertainment domain product, used by millions of users across 10+ countries - i.e. - we will discuss Testing Strategy and the Release process an Android & iOS Native app - that will help enable CI & CD.

To understand these techniques, we will quickly recap the challenges and quirks of testing Native Apps and how that is different than Web / Mobile Web Apps.

The majority of the discussion will focus on different techniques / practices related to Testing & Releases that can be established to achieve our goals, some of which are listed below:

• Functional Automation approach - identify and automate user scenarios, across supported regions
• Testing approach - what to test, when to test, how to test!
• Manual Sanity before release - and why it was important!
• Staged roll-outs via Google’s Play Store and Apple’s App Store
• Extensive monitoring of the release as users come on board, and comparing the key metrics (ex: consumer engagement) with prior releases
• Understanding Consumer Sentiments (Google’s Play Store / Apple’s App Store review comments, Social Media scans, Issues reported to / by Support, etc.)

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.

This workshop will cover mobile application security testing techniques which comprises different security bypassing methods and automation of static and dynamic analysis of mobile apps.

Below are the some techniques and tools will be used for demonstrating mobile application security.

• Root detection bypass
• SSL Pinning bypass
• Static Security Analysis using MobSF and Burpsuite
• Miscellaneous vulnerabilities in Mobile applications

You'll find many written sources which assert that AccessibilityId is the preferred selector to use for finding elements, but why is this the case? What's wrong with XPath?

In this talk, we will discuss Accessibility Id's in depth. How Appium uses them to find elements on iOS, Android, and web, and how developers add these Id's to apps. We will specifically focus on the performance impact of using XPath selectors instead of Accessibility Id's.

We will demonstrate techniques we can use to improve the performance of XPath selectors if accessibility Id's are missing, and discuss strategies for convincing managers and app developers to add accessibility Id's to the apps we automate.

It is essential to track user logs correctly to improve and develop your own web/mobile services continuously. For instance, how users flow on your applications to evaluate if they work expectedly or not.

Meanwhile, mobile application trends have been changed quickly such as architectural things or UI related one. Developers continue to add, refactor or rewrite their applications frequently. They also need to release them frequently, 2-week release for instance. Their business also changes quickly. A number of developers working for one application also has been increasing.

As a result, it is quite difficult to catch up with everything. Developers know a part of them. They add, rewrite or refactor codebase they do not know well with exploratory it. Functionalities related to UI are easy to understand. But, it is difficult to uncover what happens in the backend such as what kind of logs the app sends to servers.

In Android case, if one application sends a log to a server on a fragment's onCreate. But the fragment can use in another view. If a developer does not know what the log means, he/she might re-use the fragment in another view if he/she think they can re-use it. It can break activity logs collecting on the server side. How to maintain logs is also an interesting topic though.

In general, we notice the breaking after releasing the app since we can easy to observe the number statistically. But, it means we can not use the data to evaluate our business correctly until we fix it and re-release it.

In this talk, I would like to show an example of how I had been implemented to uncover the above thing following some scenarios based on my experience. It might be an example what we already can automate in the mobile world.

This topic is similar to monitor CPU/Memory/network thing. This story is based on my experience I had been worked for a couple of years.

At this workshop, you'll learn about advanced concepts in Appium. We will learn how to write a single script for Android, iOS and mobile web apps. Once our tests are established, we will work on framework design and report. We will also have a detailed look at how can we automate various mobile gestures using TouchActions and mobile endpoints in Appium.

Automation has come a long way in assisting with regression testing efforts. Teams worldwide are successfully running hundreds of functional regression tests at every check-in. While this provides a great source of confidence, critical regression bugs are still missed using this approach. That’s because these tests can only assert on what their human programmer asks them to. Additional errors with functionality, UX, and usability often go uncaught using today’s most common test automation techniques.

For this reason, the top companies in all sectors of the industry are turning to visual validation. Visual validation is a relatively new concept that can be used to enhance existing automated tests and provide an easy way to perform those difficult checks for things like UX, localization, usability, responsive design, and cross-device testing.

In this talk, you’ll learn how visual validation works, see a live integration into an existing Appium test code base, and discuss the pros and cons of using various visual validation techniques.

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