Recent years have moved teams away from having testers to having developers who test. When we accept we can’t automate without exploring and we can’t explore without automating, the split to manual and automation makes little sense. We need to discover new ways of decomposing the testing work to share that in the team. 

In this effort, we’ve discovered that what we used to expect from one tester, is now split to four developers each with a different emphasis for the team to be successful together. In this talk, we look at how our virtual testing team - a whole team responsible for both developing and testing an application, has split the many hats of testing identifying 15 hats for us to distribute the best way the team sees fit. 

Who carries the hats of a product historian, on-caller, parafunctionalist or feature shaper in your team, and which of the hats are hard to keep up in your current team composition?

In our mission to build scalable and reliable test automation frameworks, we need to find a way to reduce test flakiness and the time spent on maintenance to a minimum. In this talk, we will explore the usage of TestProject's free AI tools for native mobile & web scriptless test automation, while reducing test flakiness. We will be able to build stable test cases without any programming skills, all while utilizing the best-in-class open-source frameworks Selenium and Appium.

Writing code is easy, but writing good code takes a lot of practice and hard work.

Automating tests is easy, but identifying and automating the "right scenarios" takes experience, understanding of the big picture and then automating the same. Similarly, in many products, there are multiple "user-personas / roles" involved in completing a scenario. However, we end up automating only the single-user scenarios, as that is easy. But this approach does not provide enough ROI from your automation perspective.

In this session, we will share the approach taken to automate tests simulating the real-world, multi-user scenarios, where each user could be on a different platform (Android, iOS, Windows Desktop, Web) and the test orchestrates the interaction between these personas.

This approach is based on open-source tools and frameworks - Selenium WebDriver, Appium, AppiumTestDistribution and teswiz.

Most of us use Appium Inspector as a pre-requisite to automating our tests. As app testing becomes more and more advanced, so does Appium Inspector. In this talk, we’ll explore new and different modes in Inspector, recording with Inspector, and the web version of inspector.

Appium proves to hold a lot of value in the effort of achieving mobile application automation. Appium allows more granular control in automation efforts compared to scriptless automation. Though, to programmatically code text and visual assertions in appium scripts can be tedious and time-consuming, along with yielding not-so-ideal script bloat that can be difficult to maintain as an application changes from release to release. By applying an AI-driven engine on top of appium automation and providing a baseline session, AI can return text and visual discrepancies far faster than the original, programmatic attempt with less effort and maintenance. This allows quality engineers to not only catch more defects within their automation, but also allow them to automate additional tests quicker while still gaining the advantages of appium automation.

In this session, we will get under the hood of WebDriverAgent. We'll discuss the importance of accessibility, and show how WebDriverAgent works with a deep dive on WebDriverAgent and Appium.

Traditional testing is a waste of our time and money. At the same time, the demand for higher quality products is constantly increasing and our businesses are constantly transforming to digitally empower their consumers. Consumers are engaging with our applications in many different ways than they did just a few years ago. This has forced us to reevaluate the way we release our software.

In today’s age of digital transformation, it is important to understand the critical role of test automation in software product development and release.

With the Continuous Testing approach, test automation is carried out along with product development to support Continuous Integration. In this session, we will try to look at an overview of test automation and the impact it will have on your business.

Fireside Chat between Jonathan Lipps, Appium project lead and Ayan Khan, youngest active committer to Appium project.

Appium released its first major version almost 7 years ago. Since then, Appium has rolled out a lot of new features and its automation backend architecture has evolved quite a lot. 

Appium 2.0, the next major release, is almost here! It is currently available for testing in beta (v12).

Attend this this workshop if the answer to any of the below questions is "YES":

• Do you want to start Mobile app Automation using Appium but do not know where and what to start with?
• Did you start with Mobile app Automation using Appium, but got stuck among understanding capabilities, locating elements, finding whats wrong?
• Are you curious to know the changes in Appium 2.0 and want to try it out?

If you have answered Yes to one or more of the above questions, then this workshop, precisely designed for beginners to quickly get started with Appium 2.0, is for you!

At this workshop, you will learn everything from scratch, step by step. We will together understand the key concepts, apply them right there and write our “first test” in appium before we learn more nitty-gritties as takeaway for you to go and implement at your actual work directly.

This is a one-day crash course in Appium. The course will be prepared in Java.

Appium 2.0 allows its users to create their own drivers and plugins for their special needs. At this workshop, you’ll learn Appium 2.0 architecture, how to create your own custom drivers and plugins and what other breaking changes we brought in Appium 2.0. This workshop also helps you to understand several appium internals to contribute back to the Appium codebase

The last few years have been huge for the world of automation, and they only serve to underscore the importance of Appium's mission: one automation API for every platform. With Appium 2.0 we bring that vision much closer to reality. In my State of the Union this year, I want to focus on what Appium 2.0 means, what's special about it, what's new, and most importantly, how you can get involved in building on top of the Appium platform moving forward.

What if you had to support a custom locator in your project and with Appium 1.0 it was not possible. This would lead us to maintain a fork and make our required changes. Which in turn is an overkill as we have to always keep up with upstream. 

With Appium 2.0 architecture we can create plugins for our special needs. At this talk, we are going to talk about Appium 2.0 architecture, how to create custom plugins and what other breaking changes we brought in Appium 2.0. 

Despite all the available blogs, tons of tutorials and resources out there

Getting started with Appium is still really hard. Where should you start when you want to take your first baby steps towards Appium?

Well, this talk is for the beginners in the crowd, the noobs if you will. However, even if you are an intermediate appium user, a refresher does not really hurt, does it?

In this tutorial, I’ll help you get setup quickly and efficiently and give you the quick launchpad to get your hands dirty with Appium on both Android and iOS

We’ll cover:

• Mind map of the different areas/components to consider when first learning and getting started with Appium
• All the steps that you need to follow to set up Appium (Current and 2.0 version) efficiently on your machine and run your first Hello world like Appium test on android and iOS.
  • Setup:
    • Setup emulators and real devices
    • Install and setup Appium server
    • Set up your IntelliJ project and Gradle dependencies
    • Setup project structure with page object pattern
  • Setting up driver
    • Setting up desired capabilities and boilerplates to setup driver instance
  • Finding elements
    • How to use Appium Desktop for object identification
  • Writing your first tests
    • Writing your first test on Android
    • Writing your first test on iOS
  • ADB/IDB
    • Understand basics of ADB/IDB
  • Setup reporting
    • Get quick reporting out of the box
• What could be next logical steps to take

This entire starter kit code repository (both android and iOS) would be uploaded to GitHub so that you can take this ready made sample and be on your way. 

I hope you don your Beginner’s hat and join me for this exciting talk and Let’s make Getting started with Appium super easy.

Problem Statement

Our recent customer mobile apps were demanding for increased number of device testing to enable better test coverage. Considering, the availability and cost of real devices, the simulators and emulators were found to be alternates. However, the simulator infrastructures were difficult to build, scale, manage and/or expensive when it is rented on cloud specially while executing in parallel.

Our Solution

The initial purpose is to build a manageable appium test environments that can offer multiple device simulators with parallel test options at a minimum affordable cost and with simpler configurations. When minimal viable solution is built, we improved the scalability, performance and made it cloud agnostic.  

In this talk and demonstration, Gajendran and myself will demonstrate scaled Appium Pods designed using Terraform and K8S Cluster and run several parallel tests in AWS Cloud on 10+ different simulator combinations.

Appium 2.0 manages driver/plugin dependencies in .appium directory. The path can be customized by --appium-home argument. This talk will show the usage of --appium-home so that you can manage your local environment for particular usage.

This talk will also show --drivers and --plugins arguments to load necessary modules to improve the initial starting time.

In this session, I will share the mistakes which We made in the initial phase while creating automated tests using Appium, the reasons behind those mistakes, and the solutions which helped us to reduce Appium tests execution time.

This session is inspired by an activity which we did last year in Financial to improve mobile tests execution time, details can also be found here- Blog Link

We will discuss many of the most modern solutions for visualizing test results and executing tests in Docker containers. Also, we will review many framework integrations with cloud cognitive services which use machine learning ML and artificial intelligence AI. Finally, we will review how to use them for testing hard otherwise functionalities such as PDFs or videos. The demos will include testing of voice, optical character recognition OCR, and others.

Flutter community already has great package flutter_driver, yet in some scenarios using flutter_driver could be limiting, there comes flutter_appiun_driver with all power of appium along with support for flutter. I will demonstrate a simple use case with modified counter app (the modification is to accommodate use case). The session will be mostly centred around demonstration of use-case, code, when to use it with the help of a small, compact and full-fledged automation suit. 

Github Repo Link

Selenium 4 brings a brand new Grid, full of features and great things! Grid 4 has a new flexible architecture, allowing you to run it in a fully distributed mode, in the traditional Hub/Node mode, or in the simple Standalone more. It has built in observability and GraphQL endpoints, and even a good looking UI!

But wait... If Grid 4 is so great, why can't I use Appium with it? I want to scale up my tests!

The wait is over! This presentation will demonstrate how Appium can be used with Selenium Grid 4. More in detail, it will:

• Give an overview of how Grid 4 works
• Show how to configure Grid 4 to make it work with Appium
• Share tips to migrate from Grid 3 to Grid 4

Join this presentation, we will take Grid 4 for a ride and you will learn how to use it to scale up your mobile testing!

It is common yet quite new to hear the term ‘Observability’. But what does that mean?

Is it just another new acronym for monitoring? 

In the current era, organizations are building applications with more complex architectures such as - blockchain, distributed systems, and microservices. The job of maintaining these systems and ensuring it is working as expected has become a challenging task. Gone are the days where testers have to rely on the UI’s to validate an application. Now it is all about what happens underneath the hood. I worked on a distributed system where no one had any idea of what was going on and why there were production issues. We had some monitoring and logging in place, but we had no clue where, how, and what to look out for whenever there was a problem.

Join this session, where I discuss my journey with Observability. I will share how I discovered various insights about my system by using this approach. How I learned this technique and implemented it within my engineering team.

Setting up Mac OS X for remote use or as a CI pipeline is never a great experience. Usually we all love using Linux for these purposes, sadly iOS devices don't work on Linux.. or do they? Wouldn't it be cool to just execute Appium servers for iOS devices on Linux machines in Docker containers?  Turns out you can absolutely do that and this talk explains how.

I have created go-ios (https://github.com/danielpaulus/go-ios) an open source library that allows you to access iOS device functions like:

• launch XCTests (like WebDriverAgent, an Appium requirement for iOS testing)
• start and stop apps
• and many more

from the command line on both, Mac OS X and Linux. 

Because we are using unstable, private Apple APIs, I included my reverse engineering tool "dproxy" that you can use to debug future iOS updates or add missing features to go-ios. 

Mobile applications are becoming more and more important in our daily lives. From ordering clothes to grocery shopping, the services available via an app are increasing rapidly and users expect a seamless experience. This means that the automation focus is shifting more towards mobile devices. 

But did you know that there is a huge difference between interacting with a desktop browser and a mobile app? And that difference is just a few tiny hand motions! Because with desktop browser automation we mainly focus on using our mouse, but on devices, we use our fingers to execute all different kinds of gestures, like swipe, scroll, pinch/zoom, and many more. Did you also know that automating mobile gestures is one of the most overlooked features in mobile automation?The most common reason for this could be that we don’t know how to do it, or because it might just be too difficult. 

During this presentation, we will focus on how to mimic mobile gestures with Appium for Android and iOS. With a sample app we will explore and understand different gestures including how to scroll, swipe, and pinch/zoom and then create cross-platform and cross-device gestures. By the end of this presentation, you’ll learn how to improve the user experience of your mobile applications by adding gestures to your automation scripts.

Goal:

Problem Statement:

Expensive parallel connection limit:

Shift Left and Scalability:

Restricted Real Device Usage:

Data Center vs Cloud:

Desktop is still king of conversion:

In App Browser Testing:

Emerging Country Specific Browser:

New Opportunities - Evolution of Technologies

Solution:

From August 2021, new apps will be required to publish with Android App Bundle on Google Play, according to Google. What is Android App Bundle (.aab)? What is it different from Android Package file (.apk)? Does it matter when we test it on Appium? Yes, it matters. In short, we need to update our toolchain.

In this session, firstly I'll explain what is Android App Bundle. Then, I'm going through how to automate it with Appium. Finally, I'll cover how we test Android App Bundle with different languages.

------------------------------------------

[Update] QA during my session.

## Doesn't it affect the quality of android application by compressing android app bundle?
I'm not sure if I understand the question correctly, but bundletool is a google official tool and it just generate an APK set archive file from Android App Bundle.  I think Google also uses the bundletool in Google Play. So I think it is safe to use the bundletool.

## What version of appium did start supporting Android App Bundle?
Accoding to CHANGELOG, Appium supports Android App Bundle since version 1.10.0. https://github.com/appium/appium/blob/master/CHANGELOG.md#changes-in-version-1100-from-191

Keeping control over how your app looks like in a hight variety of devices and screen resolution is a hard quest.
Gonna introduce to you open source, self-hosted solution for visual testing, and managing results of visual testing that I'm personally using and developing.
https://github.com/Visual-Regression-Tracker/Visual-Regression-Tracker

With version 2.0 appium aims to transition from being a server which bundles many drivers to one which by default doesn't bundle any drivers, and instead provides an interface for retrieving and using drivers. 

The main goal being: a more accessible and easy way to write new custom drivers.

But how useful would a custom appium driver really be? What are its possible use cases? And is it worth the development effort?

During the talk I want to highlight the capabilities and possible use cases of appium 2.0 by giving a walkthrough of how we at headspin satisfied a business requirement by creating a custom appium driver for a custom piece of hardware.

Software development can be a real grind, but one thing that makes it more bearable is the joy of a passing build. Not only is that green bar important when you're iterating on a feature, but it's normally a vital part of determining whether or not your software can be released. Getting to a green build as quickly as possible allows you to experience the joy of a passing build more frequently, and allows you to verify that the next release is good more quickly than your competitors. It's a vital building block as we move towards Continuous Deployment. Given how important fast builds are in your software development, how can you make the most of Selenium 4 to help get you there? In this Keynote, Simon Stewart, Selenium Project Lead & Creator of WebDriver, covers how automation frameworks can make your life easier and your builds faster and shows how you can best use them to help reduce your build times.

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.

Have you ever wondered what it takes to build a device farm from scratch? Wonder no more. All the details can be yours. Beyond the basics of building a complex system from the ground up, the exciting and painful experience of treading into the unknown of undocumented Apple libraries will be covered.

The story includes the technical side of how to tread into the unknown, as well as the sociopolitical side of bringing an open source project into being. Open source can be intimidating, and this is a success story of the value in openly embracing the community, even when it seems impossible due to business requirements.

Technical topics that will be discussed:

• Acquiring video from Apple devices
  The different methods to do so will be explained, along with their pros and cons.
• Remotely controlling Apple devices
  Behind the scenes of how this is done with Appium, which in turn uses WebDriverAgent, which in turn calls XCUITest functions.
• The internal guts of Apple/Host communication ( "lockdown" protocol )
  All about libimobiledevice, reverse engineering, and proprietary Apple formats.
• Working with a legacy NodeJS project, and the challenge of maintenance

Regardless of your experience level or technical knowledge, you'll get a glimpse into what it takes to bring a device farm into existence from nothing.

Mobile application automation is a formidable approach to decreasing testing time and cost while increasing confidence in testing coverage. However, mobile application automation is complicated given the lack of open source tools, device fragmentation, complicated native application development, and loss of time-to-develop compared to web-based automation. However, we are fortunate to bridge the years of mobile application automation from its current infancy to further maturity via AI & machine learning assistance; thus, creating codeless (scriptless automation). AI assistance can put forth even further value to mobile application automation by also offering a solution to assist script-based automation in finding and generating correct technical identifiers. This helps alleviate the major pain point of flaky & unreliable test scripts, so that testers may focus more time on the important things, like the never-ending checklist of testing, and less time on maintaining & tweaking unreliable scripts, all while keeping the traditional, programmatic approach to automation.

Mobile test automation has come a long way in the past several years. Both Apple and Google have matured their respective frameworks. We have set industry standards in mobile development now that didn't exist just a few years ago. So do we really need to still scale our test execution across many devices/simulators/emulators, OS's, and resolutions our application supports? Doing so also raises the possibility for more points of failure across devices, cloud services, or internal grids.

For example, devices may lose internet connectivity, connection to the host machine/grid, lose power, reboot randomly, connectivity to cloud service may be interrupted, or our machine resources may not be ideal, thus all leading to flakey test behavior. Also, not to name all the possible conditionals we may need to add (and maintain) in our test code to handle these different devices. At the end of the day, all we really want is to know our application and its various UI views function and visually look accurate across the devices, OS's, and resolutions we support.

In this talk, I'll go over where we've come from and the pain points of mobile UI automation, and where we're heading. I will demo some of the new tools available on the market to help us get there.

Appium 2.0 allows you to create custom drivers and plugins. User-defined custom commands are available on them. It means you can add new routes in drivers/plugins as you like and can handle it as Appium commands. Some Appium clients provide a feature to define such custom commands as part of them.

I will explain how to add a custom route as a plugin in Appium. I'll also show the way to add a new command in an Appium client to call the custom route. This talk will show the trick so that you can add it by yourself if needed, in case your client does not have such adding a custom command feature.

For a developer, every second spent tab-switching from program A to program B is an insult. It's another opportunity to lose focus, get sidetracked, or to jolt out of flow--it's a gear-grinding interruption. Yuck!

Appium 2.0 introduces concept of plugins, to enhance appium without adding additional overhead for the users who dont need the feature. To take advantage of this, we have developed a opentelemetry plugin for appium which helps integrate opentelemetry with appium and can expose debug info and traces configurable via an API. The talk will provide brief overview on what opentelemtry is and how is it important, as well as give a basic demo of the appium opentelemetry v1 plugin.

What really is the role of a tester? What activities can we perform on a daily basis, to help the company we work for achieve its goals? Should we focus only on finding and logging bugs? Or can we contribute with much, much more? Do we, as testers, see the whole picture, and are we as involved in the software development process as we could be? Do we shine and put in our best effort at work? 

In this talk I will highlight how many activities we, as testers, can contribute and provide valuable input to. Our product experience, talent and our analytical thinking can help shape requirements, speed up delivery, improve customer experience or improve faulty processes. We can make a difference in how we achieve quality in an organization by getting more involved. And in turn, all of this will help in our personal development and in us being recognized as highly skilled, amazing professionals.

During this talk we will see how you could take record and playback tools to the next level, in order to create maintainable code in an effortless and speedy way. We will visit airtest project for this purpose, and we will explore some cool features such as finding objects by a screenshot or in XR (cross reality)

Have you heard of “flaky tests”?

There are a lot of articles, blog posts, podcasts, conference talks about what are “Flaky tests” and how to avoid them.

Some of the ideas proposed are:

• Automatically rerun failed tests a couple of times, and hope they pass
• Automatically retry certain operations in the test (ex: retry click / checking for visibility of elements, etc.) and hope the test can proceed

Unfortunately, I do not agree with the above ideas, and I would term these as anti-patterns for fixing flaky / intermittent tests.

We need to understand the reasons for flaky / intermittent tests. Some of these reasons could be because of issues like: 

• timing issues (i.e. page loading taking time)
• network issues
• browser-timing issues (different for different browsers / devices)
• data related (dynamic, changing, validity, etc.)
• poor locator strategy (ex: weird & hard-wired xpaths / locators)
• environment issue
• actual issue in the product-under-test

In this session, with the help of demos, we will look at the following techniques you can use to reduce / eliminate the flakiness of your test execution:

• Reduce number of UI tests
• Use Visual Assertions instead of Functional Assertions
• Remove external dependencies via Intelligent Virtualization

Demo will be done using the following and sample code will be shared with the participants

• Specmatic
• teswiz
• Applitools Eyes

Empathy gives you the ability to understand your users and their context and also makes you more in-tune towards their needs and wants. For a person working in a product team, understanding users is an important part of their job and if you are a software tester, product designer, or product manager, this becomes the most significant part of your day-to-day duties.

In this talk, we will discuss how empathy can help you understand your users better and create products that stick and delight their users. It helps in improving your underlying KPIs, like new users and user retention.

Overview:

Automation Testing on iOS applications has been highly standardized by Apple. Apps undergo rigorous checks before they receive approval to appear on the App Store. 

It is imperative that iOS developers/testers build and maintain automation test cases to test apps that align with Apple’s regulations. They ensure that successive deployments of an app are working fine. For this, testers can use the XCUITest to ensure the quality more.

This session will discuss the role of automation, XCUITest itself, and how to get started with it.

                 Appium has came long way with the evaluation of different drivers. The journey of providing support for blackbox testing to graybox is just phenomenal. We face many real time issues while testing our apps right from flaky tests to areas which cannot be tested with blackbox testing approach. In android platform, UI automator driver has matured level but we cannot still test areas which needs access to the application code. Luckily we have a bridge now which can help us to use both black box and graybox testing in the same time, yes we are taking about Espresso driver. In this session we will be covering some of the interesting aspects of both the drivers (UIAutomartor2 and Espresso) and explore in detail the pros and cons of both via a demonstration.

Problem Statement: While testing a native IOT application, we could figure it out the following issues using blackbox automation approach.

• The validation of the style attributes (for example the change in colour of an element based on event)
• Testing notifications
• Synchronization of the script due frequent UI element update via async API calls
• Testing two applications together one release app and another debug app
• Need of accessing of native components of  Android

Solution: After doing a close review and analysis we could realise that using just one appium driver will not be enough to overcome all the issues listed above. Carefully selecting the best of UIAutomator2 and Espresso driver we could get the desired output and found the perfect duo for our use case. In this presentation we will be demonstrating the same how we have done the end to end testing of an IOT application (M2M communication) using appium UIAutomator2 and Espresso drivers.

Have you noticed how many new streaming services have popped up over the last few years? Not only Netflix and HBO, but also Disney+, Apple TV and many more global and regional brands. The streaming / entertainment industry is booming, which means someone has to develop, test and deliver all those streaming applications for every device that is capable of video playback – from your mobile phone and desktop browser to Smart TVs, streaming sticks and set-top boxes. But how do you automate tests on all these exotic platforms?

In this talk you will learn which tools are currently there, what their strong and weak sides are, and how Appium 2.0 and its upcoming driver's ecosystem can change the rules for test automation on living room devices.

A common root cause of failures in end-2-end (e2e) automated tests is unpredictable backend API behaviour. This results in the test executions being flaky. But if you think about this, you also should be testing the impact of such unpredictable backend API behaviour on the app under test.

The question then remains — how do you implement a deterministic e2e test that validates how the app handles such unpredictable situations.

In this talk, we will take you on the journey in which a team at Jio created a testing ecosystem for running e2e tests against our mobile app using Appium and at relevant points in the flow, we set dynamic contextual expectations on the Specmatic stub to simulate the desired behaviours.

How do we know we're doing a good job when we develop, release and run the software?  Software analytics can provide data and evidence to help us know how we've been performing and help us improve our practices for future releases so we also improve our software. Using analytics well can increase our leverage and make both us and our users more satisfied. We will cover usage analytics and how it can help us find problems that escaped our development and testing and how it can provide insights into how our users use our software.

Many Apps rely on Mobile Number based OTP Authentication, we came across a similar use case on one of the projects, to keep our testing closer to reality we started using Twilio and the ability to read inbound SMS's on the numbers we use to authenticate users. We prepared a small helper for Codeceptjs, to demonstrate how this could be useful for many other companies who have a similar use case. The Twilio Helper https://www.npmjs.com/package/codeceptjs-twiliohelper is just a way to show how Twilio SDK could be used to leverage the use case of Authentication with OTP's, the idea could be used for any framework and in any supported Language. 

Many modern mobile applications are facing the same challenges when it comes to automated continuous integration UI tests. Tests are often running in parallel, logging in the same user. It makes tests unstable and unpredictable because one test can conflict with another. There are also event-based test cases where certain things expect to appear when other users interact. Social network applications are full of that scenarios. For example, it expects to see an unread messages badge when other users are sending messages. Social networks are often very crowded. It is important to test UI in case of very intense communication between server and client. For example, receiving thousands of messages at a special event. It is a very common solution to register with an associated account like Facebook or Google, however, it is challenging to write automated tests, because it requires creating new associated accounts.  We will show how we have addressed those challenges at The World's Online Festival. We believe other organizations can find our solutions useful.

Google is moving quite fast with the Flutter technology and more and more organizations are switching their apps from native implementation to Flutter. Understanding what Flutter is, what are the challenges and limitation of the technology as well as the benefits is key for a good test engineer in that space.

In this session, Eran Kinsbruner, Senior Director and Author from Perfecto at Perforce and Sreevatsa Sreerangaraju, Senior solution engineer at Perfecto, will provide insights into Flutter technology, flutter testing framework and the differences between Flutter with Dart and Appium Flutter driver. 
specifically focus on the google based Flutter driver and the appium driven community implementation.

Webdriver is primarily used for automating applications for testing purposes, it’s actually intended for browser/mobile automation more generally. It's up to users to come up with creative applications of the automation framework.

As mentioned, most of the users use webdriver just for testing purposes and fail to utilize the full potential the tool has to offer. As a result, all innovations and supporting libraries are purely focused on just testing aspects.

The primary motive of this session is to express my thoughts on how innovation can be applied along with webdriver to create wonders in the automation world.

Parallel test execution is crucial for when we want to scale our testing efforts and reach a faster time to market.
When testing dual-way communication apps, such as Whatsapp or Telegram, sender and receiver tests needs to be synchronized.

In this short session, we will see how such tests can be created and executed in parallel on two iOS devices, in parallel.
One test will be running the "sender" part sending a message, and another will be the "receiver" end, awaiting it.

The tests will run on iOS 15 physical devices, using Appium and Windows operating system.

Q & A with the Appium Core Committers:

• Jonathan Lipps
• Kazuakai Matsuo
• Sai Krishna
• Srinivasan Sekar
• Ayan Khan
• Christopher Hiller
• Mykola Mokhnach

Naresh Jain would moderate this panel.