Cross-browser testing in Selenium is the practice of running the same automated WebDriver tests across multiple browsers, such as Chrome, Firefox, Edge, and Safari, to verify that a web application behaves consistently in each environment.

Chrome and Edge are based on Chromium and use the Blink rendering engine, Firefox uses Gecko, and Safari uses WebKit. Although these browsers support common web standards and implement the W3C WebDriver specification, differences in rendering, JavaScript behavior, browser features, and operating-system integration can still affect an application. A test that passes in Chrome can therefore fail in Safari or Firefox.

The browsers you prioritize should reflect your own traffic data, customer requirements, supported environments, and risk profile. Testing only in the browser your development team uses can leave compatibility problems undiscovered until users encounter them.

Automation makes broader browser coverage more practical. According to the Sembi Software Quality Pulse Report, 57% of QA tests are currently automated. However, expanding automation across browsers also introduces infrastructure, synchronization, test-data, and maintenance challenges that teams need to manage deliberately.

This guide covers:

• WebDriver setup for major browsers
• Browser options and capabilities
• Selenium Grid architecture
• Parallel execution with TestNG and JUnit
• Containerized Grid environments
• Common causes of flaky Selenium tests
• When teams may need more structure than Selenium provides on its own

Key takeaways

• Each browser uses a corresponding driver, such as ChromeDriver, GeckoDriver, Edge WebDriver, or SafariDriver. Selenium Manager can automatically discover, download, and cache required drivers when they are not otherwise available.
• Selenium Grid supports Standalone, Hub, Node, and fully distributed configurations. Standalone is usually the simplest way to begin parallel cross-browser execution.
• Reliable locators should use unique, stable properties whenever possible. A complex XPath expression is not automatically more stable than an ID or CSS selector.
• Parallel tests need isolated data, accounts, files, and application state. Increasing the thread count before addressing shared dependencies can make a suite less reliable.
• Selenium provides browser automation, Grid infrastructure, and language bindings, but teams still need to choose and maintain their test architecture, reporting, data management, and supporting workflows.
• Teams that need Windows desktop automation alongside web testing may use Ranorex Studio and Ranorex Driver to extend WebDriver-based workflows beyond the browser.

WebDriver setup by browser

Selenium WebDriver sends commands to a browser through a browser-specific driver. Current Selenium releases include Selenium Manager, which can handle driver discovery and downloads when a compatible driver is not already configured.

Chrome

Chrome uses ChromeDriver, which is maintained as part of the Chromium project. Chrome and ChromeDriver must use compatible major versions.

Selenium Manager, included with Selenium releases since version 4.6, can detect the installed Chrome version and obtain a compatible driver when one is not already available. Selenium Manager can also manage supported browser versions in certain configurations, but setting a capability alone does not install or pin a specific local browser build.

Review Selenium’s documentation for current Chrome-specific WebDriver options.

Firefox

Firefox uses GeckoDriver, which connects WebDriver clients to Firefox. It supports Windows, macOS, and Linux.

FirefoxOptions can be used to configure preferences, browser arguments, profiles, binary locations, and other Firefox-specific settings. Teams should avoid reusing a personal browser profile because profile state can make tests dependent on cached data, extensions, or previous sessions.

Edge

Microsoft Edge uses Edge WebDriver, also called msedgedriver. Because current Edge releases are Chromium-based, Chrome and Edge share some underlying behavior and configuration concepts. However, they use separate Options classes and can expose browser-specific capabilities, policies, and release behavior.

Do not assume that every Chrome-specific option will behave identically in Edge. Use EdgeOptions and the supported Edge capabilities when configuring Edge sessions.

Safari

Safari uses SafariDriver, which is installed with macOS rather than downloaded separately. Safari automation must be enabled before use. Selenium’s current documentation instructs users to run:

safaridriver --enable

SafariDriver runs on macOS, so teams that need Safari coverage must execute those sessions on a Mac or route them to a remote macOS environment. Review the SafariDriver configuration requirements before adding Safari to a pipeline.

Internet Explorer and IE mode

Standalone Internet Explorer has not been officially supported by Selenium since June 2022. However, the Internet Explorer Driver can still support Microsoft Edge running in Internet Explorer compatibility mode for specific legacy scenarios.

Teams that still require this coverage should review Selenium’s Internet Explorer and Edge IE mode documentation because configuration requirements and limitations differ from standard Edge automation.

Configuring browser options and capabilities

Selenium 4 uses browser-specific Options classes, including ChromeOptions, FirefoxOptions, EdgeOptions, and SafariOptions. These classes support standard W3C capabilities and vendor-specific browser settings.

Common configuration needs include:

• Running a browser in headless mode
• Setting the browser window size
• Specifying the target platform
• Selecting a browser version on a Grid that offers multiple versions
• Configuring download behavior
• Adding browser arguments or preferences
• Setting page-load, script, or implicit timeouts
• Routing a session to an appropriate Grid node

The browserVersion and platformName capabilities describe the session a remote Grid should provide. They do not install a browser on the machine running the test. The Grid must already have a node capable of satisfying the requested configuration.

See Selenium’s browser options documentation for a list of supported shared capabilities.

Selenium Grid 4 architecture

Running a test suite sequentially across multiple browsers can significantly slow feedback. Selenium Grid routes WebDriver commands to browser instances on remote or local nodes, allowing teams to run tests across multiple browser and operating-system combinations.

Grid 4 is built from six main components:

• Router
• Distributor
• Session Map
• New Session Queue
• Event Bus
• Nodes

Most teams do not need to operate each component independently. The appropriate configuration depends on the size and complexity of the test environment.

Standalone

Standalone runs all Grid components in one process. It is usually the fastest way to begin local development or add a small Grid to a CI pipeline.

Start a Standalone Grid with:

java -jar selenium-server-<version>.jar standalone

By default, the Grid is available at:

http://localhost:4444

Hub and Node

In a Hub and Node configuration, the Hub combines several Grid components while browser nodes register separately. This arrangement allows teams to distribute browsers across multiple machines while managing requests through one Grid entry point.

Use Hub and Node when browser sessions need to run across different operating systems, physical machines, or controlled environments.

Fully distributed

In a fully distributed Grid, the Router, Distributor, Session Map, New Session Queue, Event Bus, and Nodes can run as separate processes.

This mode is designed for larger deployments that need to scale or operate components independently. It also introduces more configuration and infrastructure overhead, so it is generally unnecessary for a small test suite.

Selenium provides a Grid setup guide for all three configurations.

Sending a test to Grid

To execute a Java test through Grid, point RemoteWebDriver to the Grid URL:

ChromeOptions options = new ChromeOptions();

WebDriver driver = new RemoteWebDriver(

    new URL("http://localhost:4444"),

    options

);

The Grid uses the requested capabilities to route the session to an available node. If no node can satisfy the request, the session remains in the queue until a suitable slot becomes available or the request times out.

Parallel execution with TestNG and JUnit

Grid provides the browser capacity for parallel runs, but the test runner controls how tests execute concurrently.

Parallel execution with TestNG

In TestNG, parallelism can be configured in the suite XML. Setting parallel="tests" allows each <test> block to run in a separate thread.

<suite name="CrossBrowser" parallel="tests" thread-count="2">

<test name="Chrome">

    <parameter name="browser" value="chrome"/>

    <classes>

      <class name="tests.CheckoutTest"/>

    </classes>

  </test>

  <test name="Firefox">

    <parameter name="browser" value="firefox"/>

    <classes>

      <class name="tests.CheckoutTest"/>

    </classes>

  </test>

</suite>

The test code must use the browser parameter to create the corresponding Options object and RemoteWebDriver session.

Parallel execution with JUnit 5

JUnit 5 supports concurrent execution through its parallel-execution configuration and annotations such as:

@Execution(ExecutionMode.CONCURRENT)

Browser variation can be supplied through parameterized tests. Each test invocation can then request a different browser session from Grid.

The exact concurrency settings depend on how JUnit is configured in the project. Teams should confirm that WebDriver instances are correctly scoped and not shared across threads.

Isolate parallel tests

Parallel tests should not share mutable state unless that dependency is intentional and controlled.

Common collision points include:

• User accounts
• Shopping carts or transactions
• Database records
• Download directories
• Uploaded filenames
• Environment settings
• Temporary files
• Test reports
• Static WebDriver instances

Design tests to prepare and clean up their own data before increasing concurrency. A suite that passes sequentially can still fail in parallel if two tests update the same account or overwrite the same file.

Containerized Grid environments

A Grid installed directly on long-running machines can drift as browsers, drivers, operating systems, and dependencies change. Containers provide a repeatable way to define and recreate Grid environments.

The Selenium project publishes official Docker images, including:

• selenium/hub
• selenium/node-chrome
• selenium/node-firefox
• selenium/node-edge
• Standalone browser images

Use a current, explicitly selected image tag approved for your environment instead of relying on latest or copying an outdated version from an old example.

A basic Docker Compose configuration might look like this:

services:

selenium-hub:

    image: selenium/hub:<version>

    ports:

      - "4442:4442"

      - "4443:4443"

      - "4444:4444"

  chrome:

    image: selenium/node-chrome:<version>

    depends_on:

      - selenium-hub

    environment:

      - SE_EVENT_BUS_HOST=selenium-hub

      - SE_EVENT_BUS_PUBLISH_PORT=4442

      - SE_EVENT_BUS_SUBSCRIBE_PORT=4443

    shm_size: "2gb"

  firefox:

    image: selenium/node-firefox:<version>

    depends_on:

      - selenium-hub

    environment:

      - SE_EVENT_BUS_HOST=selenium-hub

      - SE_EVENT_BUS_PUBLISH_PORT=4442

      - SE_EVENT_BUS_SUBSCRIBE_PORT=4443

    shm_size: "2gb"

The Grid console at http://localhost:4444 shows registered nodes, browser slots, and active sessions.

Teams should review the current Docker-Selenium project documentation before deployment, as the available images, recommended tags, architecture support, and orchestration examples may change.

Containers improve repeatability, but they do not remove the need to manage:

• Image updates
• Browser-version coverage
• Resource limits
• Secrets and network access
• Test data
• Session capacity
• Logs and artifacts

Larger environments may use Kubernetes or another orchestration platform, but that additional infrastructure should solve a demonstrated scaling need rather than become the default starting point.

Cloud-hosted Grids

Some teams do not want to operate browser infrastructure internally. A cloud-hosted Selenium Grid can provide browser and operating-system combinations without requiring the team to maintain every node.

The tradeoff is direct: the team exchanges infrastructure work for recurring cost and an external dependency in the test pipeline. Security, privacy, test-data, network-access, and compliance requirements also need to be evaluated when the application under test contains sensitive information or is available only on an internal network.

For some regulated or restricted environments, on-premises execution remains necessary. The right choice depends on the application’s accessibility, required browser matrix, execution volume, and infrastructure capacity.

Why Selenium tests become flaky

A flaky Selenium test produces inconsistent results without a relevant application change. Flakiness weakens confidence in the suite because teams no longer know whether a failure represents a product defect, a test issue, or an environment problem.

Unstable locators

A locator tied to a dynamically generated ID can fail when that value changes. However, replacing every ID with contains() or starts-with() XPath expressions are not automatically safer.

Selenium recommends using IDs when they are unique and predictably stable. Otherwise, use another stable attribute or a concise CSS or XPath locator that reflects the application’s structure without depending on volatile values.

Keep locators separate from test logic through page objects or another consistent abstraction. This gives the team one place to update an element definition when the UI changes. See Selenium’s guidance on locator strategies and page object models.

Poor synchronization

Thread.sleep() pauses for a fixed amount of time regardless of the application’s state. If the delay is too short, the test fails. If it is too long, the suite wastes time.

Explicit waits poll for a specific condition until it succeeds or times out. For example, a test can wait for an element to become visible, enabled, or clickable rather than guessing how long the page will take to respond.

Animations and overlays

An element may be present in the document but not yet ready for interaction. Transitions, loading overlays, sticky headers, and client-side rendering can intercept clicks or move elements after Selenium locates them.

Wait for the state the test actually needs, such as clickability or the disappearance of an overlay, rather than checking only for presence.

Browser and driver drift

Automatic browser updates can change behavior or create incompatibility with an existing driver. Selenium Manager reduces manual driver management, but teams still need to decide which browser versions they support and when to update them.

Containers, managed images, or controlled test machines can help teams deliberately update browser environments.

Viewport differences

Responsive layouts can move, collapse, or hide elements at different viewport sizes. A headless browser may also use a default window size that does not match the team’s intended test scenario.

Set the viewport deliberately and treat responsive breakpoints as part of the browser test matrix rather than assuming that every node will render the same layout.

Shared state

Tests that reuse the same accounts, records, files, or browser state can fail based on execution order. Selenium’s testing guidance recommends avoiding shared state and keeping tests independent whenever practical.

When teams need more structure than Selenium provides

Selenium is an open-source browser automation project with broad language, browser, and CI/CD support. It gives teams substantial control over how their automation is designed.

However, Selenium is not a complete, prescribed test framework. Teams still need to choose or build supporting components for:

• Test architecture
• Page objects or another locator abstraction
• Reporting
• Test-data management
• Parallel-execution configuration
• Failure evidence
• CI/CD integration
• Maintenance standards

Selenium’s own documentation notes that it provides browser automation tools but does not determine how teams should architect their test suites. For teams with strong development resources and web-only applications, that flexibility can be a major advantage.

Two requirements commonly lead teams to evaluate a more structured platform.

Web and desktop coverage

Selenium automates browsers; it does not natively automate Windows desktop application interfaces. Teams with workflows that cross a web application and a Windows client, therefore, need another automation layer.

Ranorex Driver exposes a W3C WebDriver interface over the Ranorex runtime for Windows desktop automation. This allows Selenium-based frameworks to interact with supported Windows desktop applications through familiar WebDriver-based workflows.

Locator and framework maintenance

In a code-first Selenium framework, the team is responsible for designing and maintaining its locator abstraction. Page objects can effectively centralize locators, but the architecture and governance remain the team’s responsibility.

Ranorex Studio provides Ranorex Spy, RanoreXPath, and a central object repository. Teams can inspect UI elements with Ranorex Spy and maintain shared object definitions separately from test logic.

This does not eliminate test maintenance, but it gives teams a built-in structure for object identification and reuse.

A decision framework for cross-browser testing

The right choice depends on browser coverage, application types, team skills, infrastructure capacity, and maintenance cost.

A small development-led team testing one web application across several browsers may be well served by Selenium and a Standalone Grid. A mixed-skill QA team maintaining web and desktop applications may benefit from a platform with built-in recording, object recognition, reporting, and reusable modules.

Ranorex Studio’s Selenium WebDriver integration supports web tests across different browsers, operating systems, and machines. Ranorex Studio also supports low-code recording, C# and VB.NET customization, and BDD-oriented workflows within the same environment.

For a broader comparison of categories, review this guide to cross-browser testing tools.

Try Ranorex Studio with your application stack

Cross-browser testing with Selenium provides teams with flexible, standards-based browser automation. Selenium Grid extends that coverage across browser and operating-system combinations, while test runners and containerized environments help teams execute tests in parallel.

The challenge is not simply getting a test to run in several browsers. Teams also need reliable locators, controlled data, repeatable environments, useful reporting, and a maintenance process that keeps the suite trustworthy.

Ranorex Studio provides UI test automation across web, Windows desktop, and mobile applications, with Selenium WebDriver integration, a central object repository, low-code authoring, and C# or VB.NET customization.

Start your free 14-day Ranorex Studio trial to evaluate it against your own application and cross-browser requirements.