At this workshop, you'll learn about advanced concepts in Appium. We will learn how to write a single script for Android, iOS, and mobile web apps. Once our tests are established, we will work on the framework design and report. We will also have a detailed look at how can we automate various mobile gestures using Actions API and mobile endpoints in Appium. The workshop will be based on the latest Appium's Java Client.

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!

What if you had to create a custom driver for your use case in your project and with Appium 1.0 it was not possible without making any code changes to the actual appium code base. This would lead us to maintain a fork and make our required changes. Which in turn is overkill as we have to always keep up with upstream. 

With Appium 2.0 architecture we can create drivers and plugins for our unique needs. At this talk, we will talk about Appium 2.0 architecture, how to make custom Appium drivers and what other breaking changes we brought in Appium 2.0.

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.

TL;DR Summary

• Espresso is a powerful UI automation framework for the Android platform that offers gray box automation capabilities and has a simple, concise, and rich API. 
• Onboarding to use espresso can however sometimes take time. In this talk, I will explain how to get started with Espresso in the shortest time possible and we’ll look at some recipes on how to automate common app scenarios with espresso API.

Abstract

• It’s 2022 and most businesses these days are mobile-first with a presence on major platforms. UI automation is a critical part of the testing strategy of businesses looking to release high-quality apps with confidence. While unit testing is a much wider adopted practice, writing scalable UI automation is often a challenge due to its higher fidelity.

• Espresso is the dominant UI automation library for android from Google that provides a rich and concise API to test your android app's UI with confidence without sacrificing reliability and with minimal flakiness due to amazing integration with underlying instrumentation.
• For an n00b engineer approaching their first Espresso test, it could be especially tough to wrap your head around its idioms and android context and get set up quickly. 
• Well, In this talk:
  • we’ll solve for that exact persona and provide a quick understanding of an espresso test structure
  • Follow up by diving deeper into its API
  • Discuss different ready to use recipes that developers could use to solve some common use cases with mobile UI automation
  • Provide a boilerplate framework
  • I'll share Github repo links that have app source code along with their Espresso UI tests to follow along or revisit later.

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.

Continuous Security testing is becoming more and more a key factor for success. Especially if we consider that the development and release process is speeding up enormously. Just imagine that your potential shippable product is going to production with a huge vulnerability or a back door open. The damage to your company and bad reputation would be even not measurable.

So how can we avoid this? How can we build- security -in? Let's leave the stone age behind, break down the security silo and implement DevSecOps.

During my talk, I will tell you where you can implement and improve security testing. What different kinds of functional and non-function security testing methods are available and what are the low-hanging fruits.
On a high level, I will explain SAST / DAST / IAST / RASP and how your team could implement these methods with examples. I present how you can use your existing selenium scripts to drive OWASP ZAP and get more out of it!
Then I will lift it to the next level and show how you can add security testing to your pipeline to get fast feedback to fix the vulnerabilities at a very early stage (shift left). By showing where to implement security tests in your software development lifecycle, I will explain where it makes sense to have security as a deep skill part of your team and go for DevSecOps!

After I increased our transparency of security and showed you how to deal with "the four fists", I will close my talk by presenting the 10 successful steps to DevSecOps.

Multiple web frameworks have been invented to simplify the web development process, increase flexibility and reduce time to market. React js is one among them which has a significant growth in recent times. As these web frameworks are being evolved rapidly, we should also adopt tools that provide sophisticated functionality to test them. Even though Selenium is a dominator in the web automation space, it also has some downsides when automating some of the complex web apps that are built using styled-components which results in generating dynamic CSS classes that keep on changing for every UI build.

Automating such scenarios becomes problematic when the CSS classes are ever-changing. Under such circumstances, ReactWebdriver provides a out of box locators that can be used to locate web elements using React js component name, props and state.

You use lots of open-source libraries, but do you know how to customize every single piece of their behaviour? 

How to make every piece of your software customizable?

When I had to implement plugins in Selenide, I didn't find any good materials on this topic, and started investigating how other popular libraries do. In this presentation, I will show the results of my research. 

Anton Angelov will explain in many details and code examples how to automate hard-to-test web app functionalities using Selenium 4 BiDirectional and Chrome DevTools APIs. We will discuss test automation of progressive web applications, web sockets, memory leak checks. In addition, you will learn how to perform internationalization, localization, and network performance testing. Finally, we will investigate how you can use the protocols to speed up your tests using the black hole proxy pattern.

Cross-functional requirements (CFRs), predominantly referred to as Non-functional Requirements (NFRs), form an integral part of software quality and testing for them continuously is an absolute necessity for any team that promises to deliver high-quality software to their customers and end-users. Often, the emphasis that is placed on continuous testing (CT) the functional requirements are not equally placed on continuous testing the cross functional requirements in software delivery teams and by the business stakeholders. There could be multiple reasons catering to this phenomenon but one we believe could be a prominent reason is the lack of awareness on how to approach CFRs testing as they come across really vague, say, reliability or maintainability, for example. 

In this talk, I, author of O'Reilly's Full Stack Testing book, and my colleague from Thoughtworks, Pallavi Vadlamani, would like to elaborate why it is essential to do continuous testing for cross-functional requirements and introduce a holistic approach to continuous testing of all the cross-functional requirements (the approach is carved as part of Gayathri's book). We will cover how different testing techniques such as static code analysis, architecture tests, visual tests, infrastructure tests, load tests, etc., cater to automating a variety of CFRs, including those really vague ones, and therefore, aid in continuous testing and building quality into the software. 

We would continue the talk with applying the approach to a couple of CFRs specifically, say, security and accessibility, to give the audience a solid grasp on the approach. By the end of the talk, the audience should get a clear idea of how to approach continuous testing of any given CFR that is necessary for them to deliver a high-quality software.

This talk will dive into the importance of building a robust automation framework architecture that leverages Object Orientated Design Principles. 

Why does automation architecture matter? Clean code, Flexible, Easy to read, interpret, maintain and build upon.

Come and see how this automation framework approach has enabled multiple companies, projects and team members (across a variety of skill levels) to become truly efficient automation engineers.

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.

Cloud has changed the way the software world works. Companies have accelerated their development and deployment cycles with 3x or more speed by adopting the cloud. But Testing in most organizations either is running locally or not taking advantage of the full potential of cloud infrastructure. Testing is the home-alone kid, left to spend the Christmas weekend without the bells the whistles that cloud has to offer.

Digital transformation in IT and Agile delivery model are pushing the testing teams to complete their testing in shorter testing windows. 26 % of the organization are moving to daily releases. 70% of the organization have adopted Agile in delivery. Even after having a high amount of automation coverage teams are struggling to keep up with the pace of testing asked by the business teams.

This talk is about how you can change the story and accelerate cloud adoption in your testing organization with Selenium-based frameworks. Through cloud adoption you benefit from box features of the cloud: On-demand scaling, Cost optimation, Security, Reliability, Geo -routing of your test infrastructure. Cloud adoption doesn’t need to limit to the execution of selenium tests but can help you in test management of automated selenium tests, test data generation, test reporting, test artifact store, and many more. It is not enough to have an Automation First Approach these days, you also need to have Cloud-First Approach for test infrastructure to get the best value from automation.

The talk elaborates on factors to consider while building up the cloud-based testing pipeline and how they will benefit your organization in terms of time to market, cost optimization, and raising the bar of quality.

Finally talks about the moonshot of having a Testing Cloud – AWS of Testing and what will it take to reach there as a testing community.

Take your testing to the cloud, and fly your flag high in quality!

I'm a creator of Atata Framework and want to share information about it. Atata Framework - C#/.NET web test automation full-featured framework based on Selenium WebDriver. It uses a fluent page object pattern; has a built-in logging system; contains a unique triggers functionality; has a set of ready-to-use components. One of the key ideas of the framework is to provide a simple and intuitive syntax for defining and using page objects. A page object implementation requires as less code as possible. You can describe a page object class without any methods and only have a set of properties marked with attributes representing page components.

Atata is a quite mature framework that is being developed by me since 2016. It is used in a variety of projects and has positive community feedback. I would like to tell about the framework and approaches implemented in it. Attendees may find Atata interesting to try in practice, as well as get familiar with specific Atata concepts that can be used separately from Atata.

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

We have seen a lot of times testing teams complaining that they have been waiting days and months to get a test environment, and this becomes a pain when they have to test something to meet deadlines. Depending on external teams for the testing environment is pain, we transitioned and built a testing team that was capable Of building their own infrastructure, environments for all testing activities, and how the entire process was automated based on test team requirements

Assertions for traditional functional testing for web apps can be complicated and fragile. Think about all the things on a page that should be checked. Pages can have dozens of elements, and testers frequently make tradeoffs between things to check and time spent automating the selectors and assertion conditions. Visual testing simplifies that by eliminating all those assertions with single-line snapshot calls. Plus, those snapshot comparisons capture all meaningful things on the page. If a picture is worth a thousand words, then a snapshot is worth a thousand assertions. This greatly simplifies test automation effort while providing greater protection.

Testing is interaction plus verification. That’s it – you do something, and you make sure it works. You can perform those two parts manually or with automation. An automated test script still requires manual effort, though: someone needs to write code for those interactions and verifications. For web apps, verifications can be lengthy. Pages can have hundreds of elements, and teams constantly take risks when choosing which verifications to perform and which to ignore. Traditional assertions are also inadequate for testing visuals, like layout and colors. That’s lots of work for questionable protection.

There’s a better way: automated visual testing. Instead of writing several assertions explicitly, we can take visual snapshots of our pages and compare them over time to detect changes. If a picture is worth a thousand words, then a snapshot is worth a thousand assertions. In this talk, I’ll show you how to do this type of visual testing with Applitools. We’ll automate a basic web UI test together using traditional techniques with Selenium WebDriver and Java, and then we’ll supercharge it with visual snapshots. We’ll see how Visual AI can pinpoint meaningful differences instead of insignificant noise. We’ll also see how to render those snapshots on any browser configuration we want to test without needing to rerun our tests in full. By the end of this talk, you’ll see how automated visual testing will revolutionize functional test automation!

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

Selenium WebDriver is a great tool, but it's not a testing library. It's a browser manipulation tool. Still, many QA projects are built on pure Selenium. 

Selenide is a testing library based on Selenium for making stable and readable tests.

In this session, I will show how you can easily migrate your Java project from pure Selenium to Selenide. You will see how to deal with webdriver initialization, enable automated screenshots, simplify page objects and use additional Selenide features. 

And no, you don't ultimately need to refactor the entire project. You can leave old code as is, and use Selenide only in some critical parts and new code.