Looking back at test automation in a product development team for describing patterns of success for research purposes, we identified themes where the experienced success significantly differed from what the literature at large was describing. With those lessons, I moved to a new organization and took upon myself to facilitate a transformation to whole-team test automation over multiple teams, one at a time, one after the other. In this talk, we will revisit the research from one organization two years ago with lessons from another in the last two years. 

In this talk, I will introduce you to my core patterns to practice-based test automation transformation. I can't promise a recipe I would apply, as my recipe changes and adapts as I work through teams, but I can promise experiences of the same patterns working on multiple occasions as well as examples of how my go-to patterns turned out inapplicable. We'll discuss moving from specialist language to generalist language, visualizing testing debt and coverage, using visualization to showcase progress made of continuous flow of small changes, choosing to release based on automation no matter how little test automation there is, and growing individual competencies by sharing YOUR screen when working together. 

Prior to Selenium, engineering teams around the globe were struggling to build and maintain their own web testing solutions. Most frameworks at that time neither supported testing the front-end behavior of web applications, nor executing tests across different browsers and operating systems.  This forced teams to fill that gap with homegrown solutions and they were doing so in silos, without the support and backing of the open-source community or browser development companies. As we know, Selenium changed all of that and WebDriver has been a saving grace for development teams. However, the rise of Selenium unveiled a hidden set of web UI test automation challenges, many of which are still prevalent today.

Join Tariq King as he takes you on a journey to address those challenges through an evolutionary tale of test automation framework development. Based on a true story, the tale starts with replacing a rigid homegrown solution with a more flexible internal Selenium-Based Domain Specific Language (DSL), and then extending that into an external DSL with powerful test management and software process integrations. The next step in the evolution incorporates AI-based element selection and self-healing features into Selenium. Curious about where the story goes or how it ends? Tariq will share his thoughts on the future of web UI test automation with Selenium.

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!

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.

Automating interactions for tests is hard. For the past decade, the primary way to automate web UI interactions has been the Page Object Model. Unfortunately, page objects do not scale well because, by design, they bind interactions to page structure, which causes lots of code duplication and unsafe activity. The Screenplay Pattern is a much better pattern for handling interactions. In Screenplay, Actors use Abilities to perform Interactions.

In this talk, I’ll back up that claim in three parts:

1. I’ll cover problems with traditional ways of automating interactions.
2. I’ll explain why the Screenplay Pattern is a better way.
3. I’ll show how to use the Screenplay Pattern with a C# library named Boa Constrictor.

We will implement both a Web UI search engine test and a REST API web service test in C# with Boa Constrictor to demonstrate how to write readable, reliable tests using Screenplay calls. By the end of this talk, you’ll be able to start using the Screenplay Pattern for your own tests!

Automation for Salesforce is tough (no , seriously). And every platform release brings the lightning and thunder for UI Automation tests (Winter21 caused even our tests to shiver). So we present TestZeus to end this madness and create a simple (and robust) Open source framework for Salesforce Test Automation. And solve the problem of flaky tests, while accelerating the development of automation .

The Web Authentication API (a.k.a WebAuthn) is a specification written by the W3C and FIDO Alliance. The API allows servers to register and authenticate users using public-key cryptography instead of passwords. This helps to strengthen the security posture by going password-less and enabling phishing protection. We can automate WebAuthn-based sites using Virtual Authenticators, and being W3C compliant, Selenium 4 makes it really easy (The Virtual Authentication feature in Selenium 4 is currently available only in Java and in a patch release of Python).

During the talk, we will explain what WebAuthn is and what virtual authenticators are with some quick demonstrations. Then, we will showcase how using Selenium 4 we can easily automate such cases. We are also going to cover the implementation in Selenium 3 (in case someone is still stuck with the old version :)

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.

Functional programming(FP) exists from as long as object oriented programming. But most of the testing frameworks are written in OOPS style rather than FP. A typical automation tester knows little or nothing about it. Functional programming is a programming paradigm in which everything is written in terms of functions. This makes the code more modular, bug-free and parallelizable. Hence, it is important to first understand functional programming before avoiding it.

In this workshop, we will introduce functional programming in testing world. We will help you understand some of the hard concepts of FP, like Currying, Higher order functions, and demonstrate how they can be used in writing an automation framework which is scalable and easier to maintain.

We'll use Selenium 4.0 to automate a few UI scenarios, covering functional programming concepts and a code walkthrough to its object-oriented counterpart.  This will entice viewers to choose programming style based on its benefits rather than its simplicity.

Businesses are rapidly changing and in constant look out for various revenue streams. The fight against disruption has driven businesses to reconsider their priorities and value steam. Now more than ever the need for automation is in rise. However, digital transformation does not end at automating the application development, it spans much beyond the teams reach. 

To support this transformation curve, test engineers/automation engineers may have to do some heavy lifting and load sharing. What do I mean by this?, Let me ask you few questions

1. What is the scope of your automation?

2. What is your understanding of "Performance improvement"?

3. What is the reach of your Test strategy or in specific automation test strategy?

If the answer for all the above 3 questions starts and ends with "Application"/"solution offering" you are assigned to work on, then it's a good time to take a step back and visualise . Restricting yourself to partial play does not help business drive this transformation at its best. 

In this talk, I would like you to walk through with me to understand how automation can rise above and beyond a limited scope  enabling  the businesses for success and imprinting oneself with greater learning opportunities. Its a Win-Win

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.

Selenium is an amazing library for UI Automation. However, using it in a project needs a proper test design, a good approach and the best framework. I have listed some of the challenges that most people face during automation and will also brief on how we can solve those problems with effective design and approach.

Key Challenges :

1. Field level validations on a form containing several fields. (Many people will ignore these tests in automation as it may increase the number of lines of code and number of tests. Maintaining them is a difficult task)

2. Verifying the state of the web element before operating on it. (It is imperative to check whether a web element is present or visible or clickable or needs a scroll to operate. Also, different elements need different explicit wait times. Most probably we will have number of methods like waitForElementToBeClickable, waitForElementToBeVisible. This again results in increased lines of code. )

3. Assertion of multiple components on a page. (Sometimes we want to validate several items on a page and writing methods like getTitle, isCompanyLogoPresent, isFooterMenuPresent either results in multiple tests or poor test code spoiling the readability.)

4. CI/CD integration. ( Most of the companies were using Jenkins as their CI/CD tool to schedule tests and this is most probably maintained by Devops team. To set up Jenkins job we need a lot of permission. At the worst we need a machine/infra to run and schedule our tests)

How we can solve these commonly occurring problems?

1. With the advent of functional programming, we can pass different behaviours to the test methods. In the demo, I will use BiPredicate Interface implementations to solve this problem with clean design.

2. Annotations in Java is very powerful but hardly used in Test Automation Frameworks. I will use reflections and annotation to solve this problem with a much cleaner design.

3. We can leverage Custom Validator classes and AssertJ to write some effective readable tests.

4. We can leverage Github Actions and the Github runner to set up Selenium Grid Infrastructure and run our tests without any additional infra.

Tech Stack : Java, Functional Interfaces, Selenium, AssertJ, Github Actions

Continuous testing is the process of executing automated test cases as part of the software delivery pipeline to obtain immediate feedback on the business risks and add deployment blocker in Pipelines in case of any Error during test suite execution. “Continuous Testing allows any change made in the code to be tested immediately. This avoids the problems created by having “bigbang” testing left to the end of the cycle such as release delays and quality issues.

Continuous testing is decisive for Full CI-CD in the project and to achieve it, we need to make our Automation very robust and impeccable.To implement continuous testing, we have to automate tests and create test suites(e.g. Regression, Smoke, Sanity, BVT, End to End, Functional). To design the automation suite, we will use the most stable automation framework (SELENIUM). Selenium allows the tests to be automated quickly, and execution is done as soon as a piece of code is ready at their respective stages of the release pipeline. So we will show in this topic that how quickly we can automate using selenium and it can be integrated into our our existing pipeline with ease. One point is preeminent to note that "Automation is the most integral part of continuous testing", and Selenium is the framework which helps us to achieve it.

Continuous testing can be achieved using any CI-CD like Bamboo, CircleCI, Amazon CDK pipeline, and the best part is that Selenium can be integrated with all the CI-CD easily and efficiently. So just to give the audience a proper visualization of Continuous testing, we will use Jenkins as our CI-CD tool.

Target Plan of Action :

==> Define Scope and Estimation.

==> Identify important features and scenarios, which will be part of Smoke/Sanity/BVT suite.

==> Develop Automation Framework with Selenium

==> Design test suite.

==> Automate Deployment process for both DEV/QA/UAT environment.

==> Create Jenkins job for automation suite by integrating pom.xml with Jenkins.

==> Create pipeline with deployment and automation jobs.

==> Integrate Email notification for Jenkins job execution status.

==> Add GIT web hook to auto trigger jobs with code push.

Benefit Of Continous Testing:

==> We can add Deployment blocker in Pipelines in case of any Error during suite execution

==> More Test Reliability

==> Faster Release Rate

==> Reduce Costs

==> Easy Maintenance and Updates

==> Auto triggered jobs

==> Testing with more accuracy

==> Automated Email Notification for deployment and automation suite execution

==> Flawless and quick deployment

Advance Plan of Action:

==> Automation regression suite with maximum coverage

==> Use script for job creation in Jenkins

==> Code quality with sonarqube integration

==> Slack notification for jenkins job execution report

==> Coverage report

==> Stabilize automation test scripts

UiPath Test Suite is not just the solution for Software testing team to test their software applications but its also a solution for RPA team to help them to test their robotic Process Automation more effectively and efficiently. RPA developers can now create tests straight from their workflows, data-drive those tests and execute them leveraging UiPath Orchestrator. Test Suite help RPA teams reduce robot maintenance allowing them to focus on building new robots.

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.