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.

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.