Selenium has done a pretty good job in keeping the API surface friendly and usable, but what actually happens when you call some of the commands? In this talk, David will walk you through what happens when you make a call in your test, how it gets to the browser, what happens in the browser, and how it returns all the way back to your test.

Selenium is designed so that each of the commands works synchronously, so you know that a command has finished before it moves onto the next. This creates some interesting problems in browsers since they are mostly designed around asynchronicity.

We will start with how each of the bindings communicates with the browser and then move on to how navigation works. David will show all the different aspects that we need to figure out to tell if a page is “loaded”. He will also show where it goes horribly wrong and how you can write code in your tests to stabilise around these “anomalies”.

From there we will have a look at how clicks work from making sure they are trusted to what if they cause a navigation.

Problem Statement

Though Selenium taking most of the stake in the UI test automation tool market comfortably, there were always challenges that were for selenium test automation engineers are handicapped with especially when dealing with modern JS technologies. For example,

• dealing with DOM elements to solve the stale / loading / non-interactable elements,
• handling full screenshots to know how the elements at the left, bottom, etc,
• measuring the performance of request and response resources at different speeds,
• monitoring the memory of the pages, controls, etc,
• attaching to an existing browser for debugging the failed scripts and many more.

These problems were largely resolved with the integration of selenium with devtool protocols. And that makes the selenium engineer's life merrier than before.

Why this proposal can be different from others?

1. Our solution can be executed as independent with chrome dev tools or with selenium. That gives the power back to the automation engineer to choose what and how to debug/run their tests.
2. We used this solution for one of our largest enterprise customers and moved this solution to public repository this week (for this conference and beyond). With that said, we tested reasonably with more than 10,000+ test scripts and more than 1M tests.
3. The present solution is completely (100%) packed with all Chrome Dev Tools API in Java and with that said, any Java Selenium automation engineer can bind in minutes for their existing code base with no additional dependencies.
4. Finally, we love to present at the local home to start our selenium conference campaign. Where else?

Solution:

The present proposal largely connected with Chrome and Selenium in Java language. However, there is no limitation to expand the boundaries for other language bindings and browsers.

Google Chrome, the most picked browser for browsing, which makes it the primary concentration for developers and testers. DevTools is one such boon for developers, testers especially the new aged test automation engineers. With that said, we built the following design pattern to allow chrome dev tools API to marry Selenium using debugger address / remote targets.

Selenium Devtools

"This world is such a beautiful place to live in." If you can read the first sentence without any screen readers or assistance, you're privileged. As technologists, shouldn’t we be more empathetic towards differently-abled people and make all parts of our website accessible to them? In my humble opinion, the true power of technology can be identified when it reaches out to people of all kinds having different physical or psychological challenges. We not only legally bound to provide Accessibility but also it should be considered as our moral responsibility.

As testers, we have a wonderful opportunity to contribute to Accessibility by ensuring that the site is accessible in many different ways. Although it is impossible to identify all the issues that exist around Accessibility in the world, we are lucky enough to still understand a majority of them. With this understanding, there have been many measures taken in order to make your site accessible. But, don’t forget - we are QA engineers. We got to ensure that the site is accessible as per the standards set by WCAG 2.0 (AA) by testing for accessibility using various tools and techniques.

With an ever increasing no of businesses being conducted on web the testing need to write automated tests for the app's UI is something that can never be ignored. As you all know Selenium provides an API that enables us to do this quite effectively.

However, when tasked with setting up the automation framework, there are a lot of questions that arise in the minds of aspiring test developers regardless of what level they are in their career.

Some of such questions are:

1. How does one actually go about the business of building a robust and effective automation framework on top of selenium?
2. What are the elementary building blocks to include in the framework that an aspiring automation developer should know of?
3. How should we model our tests? XUnit style vs BDD?
4. Are there good practices, sensible design patterns and abstractions that we can follow in our code?
5. What are some of the anti patterns/common mistakes we should avoid

A lot of literature, documentation and blogs exists on these topics on the web already.

However In this talk,

I would combine this existing knowledge and my years of experience in building automation frameworks and breakdown these elements and walk you through exactly the sort of decisions/considerations and practices that you can take while starting to implement or improve the UI automation for your team.

Hope to see you there!

So you have got a few UI tests and they are running in parallel, great! However, life will not be so sweet once these 'a few' turns into 'a lot'. We grew from a few to 1500 UI tests (although not particularly proud of this number, there are situations and reasons)

We started with a simple parallel distribution of tests 3 years ago. As test count increased failure count run time increased along with increased flaky tests. Mobile tests had their own challenges (eg. device dropping-off, random wi-fi issues, etc) To keep up with this, we created a queue and workers based solution which could distribute the tests more efficiently (https://github.com/badoo/parallel_cucumber). Over time, we made more improvements, in particular:

• Segregation of failures based on infrastructure issues and re-queue the tests
• If a device/emulator malfunction, rescue the tests to another device
• Repeating a single test on 100s of the worker in parallel to detect flakiness
• Repeat a test if a known network issue
• Terminating the build early if more than a certain number of tests have failed
• Health check of each device, before each test to ensure reliability
• Muting a test if failure is known, and highlight outdated mutes if the related task is fixed

In this talk, I will talk about the initial challenges with running UI tests in parallel (Selenium and Appium), how we approached the queue based solution and continuous improvement of this solution; finally, how attendees can use it at their workplace or create their own solution based on our learnings.

Shadow DOM is kind of web standard that developers use to encapsulate their custom HTML code and style components so that no other global style components can override their code. It ensures that a component will work in any environment, even if other CSS or JavaScript is run on the page i.e. Shadow DOM hides away the complexity of the components from the rest of the page because it renders separately from main DOM.

Selenium legacy selectors are not able to interact these custom elements under the shadow DOM so we need java script to interact with shadow DOM elements and we also require JavascriptExecutor interface for their execution.

We will also talk about the WebdriverIO tool v5.5.0, which implicitly support Shadow DOM elements.

Browser tests are known to be the flakiest ones. This is partly because browser infrastructure is complicated to maintain. But the second reason is – mainstream browser automation tools such as Selenium server are far from being efficient.

During my previous talks I was speaking about Selenoid - a truly efficient replacement of the standard Selenium server. This year I would like to do a live demonstration how to organize a fault-tolerant and easily scalable Selenium cluster using virtual machines in the cloud. I will start by setting up Selenoid and show its powerful features like video recording, live tests debugging, manual testing and many more. Then I will configure Selenoid to send logs and recorded videos to S3-compatible storage. Finally we will run a Ggr load balancer instance allowing to use all running Selenoid nodes and organize a single entry point to the cluster.

Automated tests can provide results faster and it’s possible to execute them more frequently than manual ones. That allows to test earlier in the development process, decrease overall time needed for tests and what is probably the most important it’s possible to release and deliver business value faster and more frequently.

But what if we have more and more tests and even automated execution of them takes too much time - 10 minutes... 30 minutes... maybe even hours? Should we consider the ability to execute full tests set just a few times a day as something normal? Is adding more compute resources the only option to reduce the execution time? Or maybe there are too many high-level tests and some of them should be replaced by low-level ones according to tests pyramid? Is the tests pyramid still valid in the cloud world?

During the presentation you will see how the serverless cloud services like AWS Lambda may be used to run tests in the highly parallelized environment that can speed up execution even hundreds of times.

Selenium Grid can be a bit daunting to get up and running. Starting it is quite easy, but using it effectively can require pulling in third-party tools. In this workshop we’ll cover how to run your grid effectively, using best practices culled from several large grid installations.

Last year was dominated by the smart devices & voice based home assistants. These use the conversational interfaces unlike other applications to interact, built using advanced algorithms, ranging from natural language processing to AI/ML techniques. They are constantly learning by themselves improving the interactions with the user bringing up the challenge of non-deterministic output. To such interfaces, natural language is the input & we humans love having alternatives & love our synonyms, express using emojis gifs & pictures. Testing in this context moves to clouds of probabilities.

Unfortunately Selenium cannot be used to automate such systems and hence Botium was designed.
In this session I will cover the Selenium driver for Botium to automate E2E tests on Web UI and mobile along with testing strategy, testing NLP models & automating these tests to the CI/CD build pipelines with a DialogFlow based 'Coffee-Shop bot' as an example during my demo.

We learn more from our failures than our successes. I want to share one of my failure stories, where I learned that coding is not the most important task in Test Automation.

A failure taught me that coding is not the most important task in Test Automation. I fixed a bug, added tests, and shipped it to production. After that, a bug report came in showing that the fix created a new bug. I felt bad, I did not understand how that happened. A hotfix solved the issue, but the root cause was not addressed: what did I miss?

By taking a step back, I understood the situation, it all happened by overseeing basic concepts in testing (like understanding how the system works). The problem was that coding had more priority than creating a test plan. After this, I prioritized tasks better to avoid this situation to happen again.

This talk shows that testing concepts are more important than ever, in a time where tools promise to do everything, we focus less on what and how to test, and more in using tools to test. It outlines how a test strategy can leverage a continuous testing setup. Finally, it shows that failing is ok, but failing again for the same reasons is not.

There are thousands ways if not more to setup your automation testing environment. It is often crucial when it comes to stability and maintainability. While you can build a custom framework that fits your needs there are often already sophisticated setups or frameworks available that get you up and running very quickly.

WebdriverIO is one of these frameworks that is written in Node.js. It gets you up and running within minutes and allows you to scale up your test suite while maintaining your execution time by running tests in parallel. With its huge project community it is an ideal choice for small as well as big projects that use modern frameworks such as React, Angular or Vue.js.

In this workshop you will learn everything you need to know to run a successful, stable and maintainable WebdriverIO framework. It starts with an introduction to the project and the basic concepts and will end with a sophisticated framework that includes testing strategies like Frontend Performance Testing as well as complex browser interaction with Puppeteer.

• Don't get tripped up by thinking of the wrong kind of artificial intelligence (AI) when it comes to testing scenarios.
• To ensure the creation of a successful speech recognition engine, using enough high-quality data to train machine learning algorithms is paramount.
• Even where an algorithm has been built correctly, its performance still very much depends on the accuracy of the datasets it was trained with.
• In always striving for accuracy with our services while serving a number of different industries, we are able to continuously train our automatic speech recognition technology with incredibly precise data sets.
• AI/ML can be leveraged in the number of areas and scenarios to solve and help in our day to day testing activities.
• This talk would discuss about AI/ML, its impact, some existing solutions available to deal with it.
• This session will prove to you that, anyone just interested to learn about AI can get started on this journey.

Use Case:

In this prototype we are using speech to text recognition which will inturns
help to perform respective actions on particular web element.

1. Speech based automation framework
2. Framework written in java
3. Use of weak AI for speech to text conversion
4. Use of grammatical files for training data set

We all have read or heard about test automation pyramid .But is it really supposed to be a pyramid ? or it's just a metaphor? lets find out

At this talk we will share our learnings from implementing test automation pyramid for years and its variations finally arriving to test automation cup modal focusing on

1.Need for growing up from automation testing pyramid

2.How the modern testing stack has evolved

3.How to choose and design your automation testing stack

4.Real World examples from testing to validate our test cup model

5.How to move from Pyramid to test cup and Our lessons learned

6.Sharing Best practices ,limitations and patterns for success

Artificial neural networks are one of the many approaches to Machine Learning (ML). It is based on the neural network of the human body where each neuron keeps learning and interconnects with other neurons to perform different actions based on different responses. We are currently surrounded by several neural networks used in various fields to solve different kinds of problems. This being the case, for most of us building and training a neural network still remains a mystery.

Come attend this session, where I demystify neural networks and show how easy it is to build your own neural network in under 5 minutes using Brain.js. I will first cover the basics of AI, ML and Deep learning. Then, I will walk you through a step by step process of building a neural network in a live demo session. Discuss how this is applied to the field of software development and testing. This session will prove to you that, there is no need to be a data scientist to train your own models. Anyone just interested to learn about AI can get started on this journey. Both technical and non-technical people will be able to build their own models after this session.

This session will prove to you that, there is no need to be a data scientist to train your own models. Anyone just interested to learn about AI can get started on this journey using the power of open source frameworks. In this case it is Brain.js.