Why Browser Engines ≠ Real Desktop Browsers ≠ Mobile Browsers
All of us have tested on either headless browsers, browser engines or responsive mode for mobile. However, there are a lot of differences between an actual browser, desktop and mobile, vs a simulated one.
In this talk I’ll walk you through real world examples that show you the gaps you can miss while testing:
-
In headless mode
-
Browser engines
-
Responsive mode for mobile browsers
I’ll also share the technicalities of why this happens and my learnings from having worked on a browser engine.
Outline/Structure of the Presentation
-
Levels of ‘real-user’ testing - 5 mins
-
Headless vs headful testing: Technicalities and examples - 10 mins
-
Browser engines vs real browsers: Technicalities and examples - 10 mins
-
Real mobile browsers vs simulated browsers: Technicalities and examples - 10 mins
-
Q&A - 10 mins
Learning Outcome
-
Different environments for testsing and their pros and cons
-
Choosing the ideal environment for your next project depending on the functionality
-
Differences between headless and headful testing, browser engines and real browsers, real mobile browsers and simulated browsers
Target Audience
QA, SDETs, Engineering Managers, QA Managers
Prerequisites for Attendees
None
Links
schedule Submitted 4 months ago
People who liked this proposal, also liked:
-
keyboard_arrow_down
Shi Ling Tai - UNTestable: It's Just Pressing a Button, How Hard Could it Be?
40 Mins
Deep Dive Session
Intermediate
Over the last 7 years, I've consulted several testing teams on test automation projects for their web applications, and the most frequent troubleshooting request I get is about clicking some button on some website.
It's just pressing a button... how hard could it be... right?
I came to discover there's many edge cases when it comes to simply executing a click on a button.
For example, how do you click a button that re-renders when the mouse hover over it? If you tried to click on the button that used to be there before, then you'll get a "stale element reference".
How about a button that moves when the mouse goes over it?
How about a button that is partially obscured by another element?
How about a button nested in several scrollable containers?
Unfortunately, these trick buttons are real scenarios I've seen in real business applications.
In this presentation / live coding session, I'll show you some trick buttons, and how to hit them on the bullseye. -
keyboard_arrow_down
Boni García - Selenium Manager: Automated Driver & Browser Management for Selenium WebDriver
40 Mins
Presentation
Beginner
Selenium WebDriver is an open source library that allows controlling web browsers (e.g., Chrome, Firefox, Edge, etc.) programmatically using different languages (such as Java, JavaScript, Python, Ruby, or C#). Internally, Selenium WebDriver uses the native support implemented by each browser to carry out the automation process. For this reason, we need to place a component called driver (e.g., chromedriver, geckodriver, msedgedriver, etc.) between the script using the Selenium WebDriver API and the browser.
Historically, the Selenium project did not cover the automated management (understood as the process of download, setup, and maintenance) of drivers. For this reason, different projects in the Selenium ecosystem emerged to do this task (such as WebDriverManager in Java or webdriver-manager in Python, among others). As of Selenium 4.6.0, automated driver management is shipped in Selenium WebDriver out of the box. This way, the driver management is done automatically and transparently for all Selenium WebDriver binding languages. This process is done through a new official tool of the Selenium portfolio called Selenium Manager.
Selenium Manager is a CLI tool developed in Rust. It provides a robust mechanism to detect the version of the local browser to be controlled with Selenium WebDriver, download the proper driver, and make it available for Selenium WebDriver. Moreover, Selenium Manager has another relevant feature in its roadmap: the automatic management (i.e., download and installation) of browsers (such as Chrome, Firefox, or Edge).
Selenium Manager has been built with the lessons learned from the development of WebDriverManager (first released in 2015). This way, the history of Selenium Manager is the history of how an independent third-party project has become part of the Selenium code development.
-
keyboard_arrow_down
Liza Ivanova - Declarative UTAM Page Objects
40 Mins
Deep Dive Session
Intermediate
Page Objects design pattern is commonly used by most automation developers because it provides encapsulation and ensures maintainability of UI tests. The larger and more complex is application, the more UI tests teams have to write and maintain, and the more important it is to maintain 1:1 relations between UI component and a Page Object. But design pattern on its own does not ensure good quality of the page object code, that's why we created UTAM.
UTAM provides declarative JSON based language to create page objects and compilers to transform declarative code to Java, JavaScript or TypeScript. Generated code is based on Selenium library (for Java) or WebdriverIO (for Javascript), but UTAM allows to build custom integration layer to use any framework for UI interactions. Generated code is high quality and uses all best practices like explicit waits and CSS selectors only (XPATH not supported). It's very easy to write UTAM JSON and even easier to generate it automatically from any HTML source.
UTAM declarative language has support for mobile automation as well (both IOS and Android) and Shadow DOM.
We provide extensive documentation and online interactive tutorials on UTAM web portal https://utam.dev/tutorial/introduction for better learning experience. We also created browser extension to partially generate UI tests https://chrome.google.com/webstore/detail/utam/llgodnekeleaidcljgfljjechnjdgnli
Our goal with UTAM is to increase maintainability of the page objects and development productivity to produce overall better experience.
-
keyboard_arrow_down
David Burns - Our experience of pushing Selenium to the limit with Nightwatch
40 Mins
Presentation
Beginner
A few months back, we charted the path of thinking about the future of testing. A future where testing happens earlier and doesn’t stop after deployment. A state where testing happens across multiple platforms simultaneously in environments which are exactly like the ones end users have.
And we evaluated all the frameworks, again, from Playwright to Cypress and everything else. We still chose Selenium as the core framework to build on top of.
In this talk, I’ll talk about our evaluation of:
-
The future of testing
-
The role of test automation frameworks
-
Evaluating Selenium against other frameworks
-
Our experience of extending Selenium to do completely new things
-
-
keyboard_arrow_down
David Burns - 5 habits to treat your test code like production
40 Mins
Presentation
Intermediate
When teams start their journey of test automation, they usually go from no tests to different types of tests in a very short span. These tests do not through the same rigour as the production code and aren’t maintained as well. Over time, this leads to flakiness, unnecessary spending on tooling and a bloated test suite.
In this talk, David will talk about 5 habits that you can follow to ensure the same quality as your production code and build test suites that are robust, and consistent and help you debug the issues quickly.
-
Typical journey for teams adopting test automation
-
5 habits to follow while building your test suite
-
Our learnings from a recent refactoring activity
-
-
keyboard_arrow_down
Shi Ling Tai - Write robust XPATHs like a Pro
40 Mins
Deep Dive Session
Intermediate
XPATH expressions get a bad reputation among developers because it more verbose than CSS selectors and seem to be more fragile as well.
But XPATH expressions are very powerful and can do more than CSS selectors, it's just many people don't know how to use it well.
In this presentation / live coding session, we'll learn how to write robust XPATH expressions with exercises on real world applications. We'll start from examples of bad fragile XPATH expressions and iterate on these examples to make the XPATH expressions more robust.