Learn Selenium - Cross-browser Testing Strategies

#Introduction

Not all your users use Chrome. Some open the app in Firefox, Edge, Safari, or mobile browsers. Cross-browser testing ensures the application behaves the same across all supported browsers. Episode 14 covers strategies for running the suite across many browsers efficiently and in an organized way.

The Selenium advantage already discussed in episode 1 — cross-browser support — now becomes real: a factory pattern for building drivers, compatibility testing strategies, managing browser-specific quirks, and cloud browser farms that give access to hundreds of browser combinations without owning the hardware.

#Running Tests in Chrome, Firefox, Edge, and Safari

#Factory Pattern for Browsers

Instead of writing a separate constructor in every test, build one factory that produces a driver by browser name:

Driver factory

from selenium import webdriver
 
 
def buat_driver(browser, headless=False):
    if browser == "chrome":
        opsi = webdriver.ChromeOptions()
        if headless:
            opsi.add_argument("--headless")
        return webdriver.Chrome(options=opsi)
    if browser == "firefox":
        opsi = webdriver.FirefoxOptions()
        if headless:
            opsi.add_argument("-headless")
        return webdriver.Firefox(options=opsi)
    if browser == "edge":
        return webdriver.Edge()
    raise ValueError(f"Browser tidak dikenal: {browser}")
 
 
driver = buat_driver("firefox", headless=True)

The buat_driver(browser, headless=False) function centralizes driver creation logic. Adding a new browser is just adding one if branch, and all tests use the same path.

#Safari on macOS

Safari requires the safaridriver actor, enabled via a system command:

safaridriver --enable

The safaridriver --enable command enables the Safari driver on macOS. Remember: Safari only runs on macOS, so for Linux-based CI you'll need Mac runners or a cloud farm.

#Cross-browser Compatibility Patterns

#Defining a Realistic Browser Matrix

Don't test every combination of browser and version. Define the matrix based on user analytics data:

• Chrome and Edge: the majority of desktop users — always tested.
• Firefox: tested in the core suite, not in every test.
• Safari: tested for the most important business flows.
• Old versions: only versions still significantly used by users.

Browser matrix per suite

MATRIKS_INTI = ["chrome", "firefox"]
MATRIKS_KRITIS = ["chrome", "firefox", "safari"]

MATRIKS_INTI = ["chrome", "firefox"] and MATRIKS_KRITIS separate coverage levels. Critical business tests run on all browsers, other functional tests only on the two main browsers — a balance between coverage and cost.

#Critical vs Non-Critical Tests

Split cross-browser tests by business value. Checkout, login, and dashboard are candidates for cross-browser testing; minor tests like button colors are fine on one browser. This principle keeps cross-browser costs proportional to risk.

#Managing Browser-specific Quirks

Every browser has characteristic behavior. The most common ones:

• Different render timing: elements appear later in Firefox — use explicit waits, not time assumptions.
• Different scroll behavior: Safari and Firefox handle scrollIntoView with subtle differences.
• Small CSS differences: a few pixels of margin — don't assert strictly.

Per-browser quirk abstraction

def klik_saat_terlihat(driver, locator):
    if driver.capabilities["browserName"] == "safari":
        driver.execute_script("arguments[0].scrollIntoView(true);", locator)
    driver.find_element(*locator).click()

driver.capabilities["browserName"] tells you the active browser. With abstractions like klik_saat_terlihat(...), quirks are resolved in one place instead of scattered across all tests.

#Cloud Browser Farms

#BrowserStack and Sauce Labs

Cloud farms give access to hundreds of browser and OS combinations without your own hardware. Tests still use webdriver.Remote, only the URL and capabilities differ:

Remote to BrowserStack

from selenium import webdriver
 
caps = {
    "browserName": "Chrome",
    "browserVersion": "126",
    "os": "Windows",
    "osVersion": "11",
    "name": "Test Checkout",
}
 
driver = webdriver.Remote(
    command_executor="https://username:access_key@hub.browserstack.com/wd/hub",
    desired_capabilities=caps,
)

webdriver.Remote(..., desired_capabilities=caps) opens a session in the cloud farm. The username:access_key credentials come from the environment, not written directly in code.

#When to Use a Cloud Farm

Cloud farms are very useful for Safari and old browser versions that are hard to reproduce on local machines. Consider the cost: for daily needs, a local combination (Chrome, Firefox, Edge) plus grid is sufficient; cloud farms are reserved for the full matrix before release.

#Conclusion

Episode 14 gives you full control over cross-browser coverage: a centralized driver factory, a browser matrix tailored to business risk, browser-specific quirk abstractions, and leveraging cloud farms for combinations you can't reproduce locally.

Key takeaways:

• The factory pattern centralizes driver creation for all browsers.
• Define the browser matrix based on user data and business risk.
• Only run cross-browser tests for valuable, risky flows.
• Abstract per-browser quirks so fixes stay centralized.
• Cloud farms for Safari and rare combinations; local plus grid for daily needs.

In episode 15 next, we'll cover performance testing and visual regression — an introduction to measuring browser performance, integration with Lighthouse or performance tools, visual regression with screenshot comparison, and detecting layout regression and UI drift.