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.

With the advent and advancements in Web APIs, accurately displaying responsive web page content across fragmented mobile device browsers is merely just one of the checkboxes that Quality Assurance teams need to care about, albeit a very important one.

Similar to native / hybrid apps installed directly on Android and iOS, mobile web applications also implement advanced real world use cases that heavily leverage mobile device hardware such as processor, graphics, memory etc. and device sensors like camera, microphone, location, motion etc.

In addition, web apps can also access device OS level features for SMS/call integrations, notifications, payments, accessibility which further calls for testing such web apps on real mobile devices.

In our talk, we are going to cover -

1. Expansion of mobile web testing landscape with Web APIs

2. Why is mobile web testing important for businesses

3. Real-world mobile web testing customer use cases across Finance, Banking and E-commerce

4. Mimics for a real device : A risky business

5. Achieving versatility in meeting the dynamic infrastructure needs

How to fight with unstable tests

The talk is about flaky, or unstable tests – why it’s the biggest trouble in test automation and how to overcome it. I will show my collection of real-life examples of flaky tests from my experience. These are really tricky investigations that lasted many days, weeks and even years!
The talk will be interesting to both testers and developers – anyone who loves to solve unsolvable puzzles.

Over the recent years, agile teams have started practicing the shift left test approach to speed up their product deliveries and remove testing bottlenecks. Often teams tend to shift functional testing to the left of delivery cycle addressing the cross functional requirements(CFR) tests at the end.

The functional requirements of the product defines the behaviour of the system whereas the Cross-Functional Requirements(CFRs) define the operational attributes of the system like performance, availability, reliability, usability, accessibility, audit, logging, recoverability, user volume, security, localisation, etc.

Consider a case where an online retail application has launched its big sale days with exceptionally great deals, triggering the enthusiasm of millions of users to access the application at the same time. The moment the big sale started, the website received a peak load from its users. Unable to withstand the load, the application was inaccessible until a suitable fix was done by the engineering team. Would this make the customers happy with online shopping experience? How many people would stay in the application until it’s up again? Would they shop in the application if this repeats?  If CFRs had been tested effectively with proper focus, we could avoid facing this situation of losing hundreds of customers.

This session talks about the importance and need to shift CFR tests to the left of delivery cycle for high confident and quality releases. It gives step by step explanation of shift left process and practices that helps build CFRs into the product right from project kickoff till delivery along with an example case study.

In a fast growing environment where everything is moving first, it is a no brainer to test web and apps on mobile devices. To build it there are so many articles and blogs but none speaks about how to test the device grid meant for testing. We have a similar problem where we need to test mobile device grid consisting of a truly fragmented use case.

It is different from testing applications on different platforms/versions. Testing cloud services itself has many challenges like 

1. Are we presenting the same Experience as a real physical device held in their hands to grid users?

2. Testing Integrations with different components

3. Implement Automation for complex scenarios like users actions(scroll, click etc) with stability, fast pace, and less maintenance.

We have faced a lot of complex challenges in this endeavour, and our engineering team has tried to solve it with some amazing results. In this session, we will provide the gist on the below issues:

• How we simulate user actions in real devices using selenium?

• How to leverage available frameworks based on your usage

• Impact of automation on productivity and quality

“No man ever made a great discovery without the exercise of the imagination.”-George Henry Lewes

The unknowns can often cause more damage than the known. We often tend to overlook or underestimate the “What If” scenarios in our testing life cycle. This is often due to the time sensitive deadlines set to develop, test and deliver a product.  

Testing is an applied practice in industry but lacks research. It is imperative to incorporate all variations of testing not just as a practice but as a culture. In the end you wouldn’t want an average working product. This in turn requires a considerable amount of time, resources and effort. To establish what skipped your sanity and regression tests, it might be a plus for you to have a placeholder for research and intuitive validations. 

Exploratory Testing [ET] is simultaneous learning, test design, and test execution. ET is not Ad-Hoc Testing. It demands time, discovery and imagination. A tester’s creativity and intuitiveness plays a big role in enabling ET across teams. ET can be incorporated in an organization's culture, only when you have reached a few initial milestones like substantial automation coverage, a considerable amount of continuous testing in place and a scalable solution that covers the essential parameters of cross-browser or multi-device testing.

In our talk , we will cover:

1. What is Exploratory Testing 

2. Steps and methodologies for ET

3. How can you make way for ET to be a part of your continuous testing processes

4. How Exploratory Testing Elevates Agile Practices

5. Who can be identified as an Exploratory Tester

Now that I have your attention, let me tell you why Selenium is bad. People throw the kitchen sink at their test suites and then never fully understand why their tests are
● Slow
● Brittle
● Take an age to run (Who has a test suite that takes a day to run?)
And this is likely just on one browser. If we add another browser? The complexity grows exponentially!!
The truth is, yes Selenium can be slow, it can be brittle, it make you do some of the set up yourself. However, Is the reality that Selenium is the problem in our lives?
The problem with browser automation is that it is overused. People don’t understand how the asynchronous nature of browsers really work. And let’s be honest, browsers are hard, they’re operating system level hard.
But for now, let’s blame Selenium for our woes. I mean, it is the most common denominator.
The reality is... Poor test architecture, poor setup and the general “selenium isn’t coding so why practise good development hygiene” are ruining your lives. Implicit knowledge is codified and then people forget that it exists
In this talk, I will talk about the things that I have learned in supporting BrowserStack customers, the common mistakes to make sure that you don’t have to. I will also talk about how Selenium is gives complete flexibility for you to choose -
● Test assertion library
● Test analytics or logging tool
● Test runner

 ● Test platform - Standalone or grid setup or headless And it has awesome features like
● Support all desktop and mobile platforms
● Scales better with solid community support
Note: We are a framework-agnostic organization. We have customers that use BrowserStack at scale with many frameworks including Nightwatch, WebdriverIO, Playwright, Puppeteer, Cypress and of course, Selenium. This talk is a result of my personal frustrations on why Selenium is hated on so much when the fault clearly aren’t Selenium’s.

The web development space has been growing exponentially over the past decade and the count of new frameworks and design patterns is at its all-time high. Historically there’s always been a gap between devs and QA and this talk is a step towards bridging that gap, enabling more collaboration and exposure to the other side. As a developer, you’d learn about the simple ways you can help test your product, and as a QA engineer you will get a peek into the development process and learn what you can ask from a developer that saves your time.

We would go through key changes the front-end can make that would help testing and we would have some time for open discussions where the audience can raise their pain points while testing. On a high level, this talk will cover - UI Development process, Web elements, Navigation, Dynamic components and Backdoor access.

With the increasing frequency of releases and an ever-increasing number of automation scenarios, our existing framework wasn't helping the case. We saw an increase in our time and efforts with little to no improvement in results. 

With a bloated testing framework, we have serious performance and stability issues. Considering that we started to look into the fundamentals and started exploring new testing frameworks. We identified a few candidates that matched our requirements and finally selected Nightwatch. It satisfied all the criteria and gave better results when compared to our already existing framework.

In this talk, we will cover

1. Challenges with existing Framework

2. Why Nightwatch?

3. Learnings and Outcome from migration

While End-End tests can be a great way to test out your applications but realistically, we need to follow the testing pyramid more. Moving more tests away from end-end to component testing will make your test suite faster. Addition of faster component tests while keeping end-to-end tests limited is a way out, especially when we start using reusable components in frontend frameworks.

In this session, I will present how adding smaller and faster component tests would be beneficial / We can use the same Nightwatch APIs to write them so there is no need to learn extra steps. While most of the test frameworks use JSDOM to render components, some of the load all the files on the test renderer page. Nightwatch aims to provide a combination of both approaches. By the end of the talk, you will know how to test React components on Real browsers with Nightwatch along with visual assertions.