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

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.

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!

Having been a hobbyist magician for 34 years, I started noticing that some close-up and stage magic principles and theories don't only apply to magic tricks but also to software testing.

An example of this is the application of the KISS principle (Keep It Simple, Stupid) in software development. This helps to avoid unnecessary code complexity and make it easy to understandable and follow. In magic, this applies as well. Magicians strive for clarity and simplicity by creating effects that are easy to follow for spectators.

In this sessions, I will try to connect those two worlds and thus combine two of my passions. Also, I will try my best to illustrate the magic side of things with demonstrations. This is a challenge I set for myself - let’s see how it goes.

If you are tired of waiting for your selenium tests status and old fasioned ways of reporting tests status, you are in a good place.

We will show you our test environment setup and how we run over 2500 tests in about an hour. Not cool enough? Take a look how we make reports via slack.

Do you want to check if we can be even more faster?

Have you ever heard "you are just a tester"? Have you ever felt being a tester is just a stop for "better" position? Are you afraid someday test automation will take your job? Do you feel you could bring more value for your team but don't know how?

Hi, I'm BeardedQA and I have some answers.

During this talk, I'll share my experience about moving from Manual Tester to Quality Assurance Engineer position, what quality assurance really is and how to give more value for your team.