Have you ever wondered how you can contribute to the Selenium project and become part of the team?

Do you wonder how the different Selenium projects work under the covers?

Selenium is a set of solutions that enables you to automate all major browsers with WebDriver, scale up and run tests in parallel through the Grid, record and play back user interactions with the IDE, and share all this knowledge though the Selenium website and documentation.

However, only a handful of volunteers work to maintain this gigantic effort. If you would like to enhance your own Selenium experience while contributing back to the software that has defined so many of our careers, come to this workshop. In it we'll dissect the different elements of Selenium, dive into its internals, learn how it was built and how to make changes to it, and even fix or improve something that you can contribute on the same day!

As Web Components gain more traction in the web to help websites become more performant it has created a bit of a blind spot on how to test these new features.

In this talk, David will walk you through what Web Components are and how they are benefiting the web as we move forward. He will then walk you through how we can go about testing these and how, while well-meaning, other frameworks are making things a little harder to test. He will also go through some of the performance aspects of the Web Components and how this translates to your tests.

As our systems and tests grow more and more complex we need to make sure that we have the tools to capture the root causes without spending hours or days chasing them down. This is where Observability becomes our best friend. Observability allows us to see what is going on inside a system based on what we think is crucial without trawling through logs! Just like any piece of software should be robust, scalable, maintainable, and reliable, it should also be observable. Observability makes the journey from identifying unexpected problems to identifying the root cause easier.

To do so, the code should record as much useful granular information as possible. Metrics, logs, and traces are three known ways of encapsulating granular information. They are the primary sources of information to help determine the state of the system at any given point in time. 

Selenium 4 introduced a fully distributed Grid with multiple components that communicate over the network. Troubleshooting and diagnosing problems in this setup is a challenge. To tackle this, Selenium integrated OpenTelemetry’s tracing and event logs.  This feature is now available out of the box by default when using Selenium.
The users now have more power in their hands!

I will dive into Selenium's observability journey by discussing: 

1. What is observability?

2. Need for observability

3. Understanding the three pillars of observability: Metrics, Logging, and Tracing

4. Generating telemetry data alone does not suffice. It is a process from design to deployment. 

5. Full-stack tracing in Selenium (Grid and Java client library)

6. Explain how we, at BrowserStack, are benefiting and exposing this information to our users.

As the cross-browser testing landscape evolves, there is a stabilization around 3 main leading frameworks that are used the most. Some are more adopted by frontend developers, while some are adopted by SDETs. To better make a selection or even choose more than a single framework you need to realize the core differences and use cases as well as benefits each framework provides to the practitioner.

In this session, Eran Kinsbruner, Chief DevOps evangelist, best-selling author from Perforce (Perfecto and Blazemeter specifically) will go through the core differences and advantages of all 3 frameworks with focus on Selenium 4 vs. the latest versions of Cypress and Playwright and provide a nice outline to better guide test automation engineers as they look for their next test framework.

This is a real story of how we implemented Shift Left by influencing, mindset change, creating champions and with the help of technology at Expedia Group.

In every software company in the world, at the nucleus of it, all we are trying to do is, take a code change and move it to production, faster with quality. There couldn't be any disagreement over this!

Sometimes when we repeatedly follow a practice, even when there are new better alternatives, it is difficult to change our mindset because we think "Why change? it is working".  Moving your pipelines to follow Shift Left is one of them.

In US alone, $113B is spent annually on identifying and fixing production defects!

Shift Left not only increases developer productivity, but allows you to go to production faster, more frequently and reduce production incidents. End of the day, it makes both developers and customers happy!

The biggest frustrations for developers in a team is, CI/CD pipeline being blocked and no one can merge their PR, everyone has to wait for it to be fixed and pipeline becomes green again. And as all the validation and verifications happening to the right side of the pipeline, it is going to take more time to fix issues as well, involving many engineers, because the failure could have been caused by any code change. This is true, especially when an issue happens in production, not only everyone has to be involved to figure out the problem, but there is going to be lot of unhappy customers and loss of revenue.

What if you have something where pipeline blockage is not possible. What if you can can run the same set of checks you run in main pipeline but you run them against your branch itself and when you merge your PR, it is already 'production ready', what if every PR can go to production directly? what if you have a mechanism where it actually reduces production incidents ?

Welcome to Shift Left!

Spreadsheets have a dominant way of managing multiple business processes.

Validating these spreadsheets data points manually is very hectic and automating them needs knowledge on scripting. Also automating spread sheet actions like handling excel popups ,clicking macro buttons etc., will require more efforts.

RPA Power Automate for desktop provides an extensive variety of Microsoft Excel Spreadsheet actions to help you read and manipulate Excel files. With this RPA ,we handled spreadsheet actions using simple flows with out complex scripts. Simple drag and drop flows changed our view from the usual mind juggling of code/scripting concepts to simple business actions. This indeed saved lot of time and efforts.

Problem Statement:

On usual procedure we need to write the step definition and data storage classes wrt PM model. For each of the feature steps we need to map that to relative stepdefinition i.e method which performs action.

This eventually manual and time consuming effort.

Solution is to automate cucumber test script generation using NLP technique. Tensor flow uses features files and converts the features files to required step definition methods(Java).Separate set of classes will be generated as per the application UI pages. Object repository will be created dynamically when user supplies the steps in feature file.

Tool scans the html page and retrieves all required locators using intelligent locators generating strategy(to achieve this we need to supply strong data as part of feature files)

This eventually leads to no code automation using cucumber with web driver.

AI can beat humans at Chess & Go, drive a car more safely than you, identify cat videos better than any human; soon AI will help test code better than humans too. Working at companies like test.ai & Google, Chris has explored the intricacies of building AI to help test dynamic websites and apps that are constantly changing. He will show how these lessons learned are now being brought to the larger community in a plug and play way.