Cross-Browser, Responsive, Localization, and Compatibility Testing: Diagnostics, Failure Modes, and Production Practices

1. Compatibility diagnostic sequence

1. Preserve first-failure screenshot, page source, exception, URL, browser/session capabilities, requested matrix row, app locale, runtime browser language/timezone, and relevant Grid/CI evidence.
2. Confirm Selenium/binding/browser/driver/Grid versions and the actual platform.
3. Confirm target, controlled data, and matrix-row identity.
4. Inspect browsing context, locator, element, and synchronization state.
5. Inspect AUT behavior and network/browser evidence.
6. If remote, inspect Grid queue/node/slot or CI runner state.
7. Change one failing assumption at a time and rerun the smallest controlled row.

This is the same evidence discipline from Chapter 15, now extended with compatibility inputs.

2. Broken example: translated text used as identity

The following example makes the Broken example: translated text used as identity behavior concrete. Read it with the stated assumptions, then compare its observable output or state changes with the explanation that follows.

from selenium.webdriver.common.by import By
from selenium.common.exceptions import NoSuchElementException

# Works in English, fails when the same fixture is opened with ?locale=de.
try:
    driver.find_element(
        By.XPATH,
        "//button[normalize-space()='Start trial']"
    ).click()
except NoSuchElementException:
    driver.save_screenshot("evidence/translated-locator-failure.png")
    raise

The NoSuchElementException does not prove German rendering is broken. The locator contract is wrong: it couples element identity to one translation. The repair is a stable selector plus a separate copy assertion when translation correctness is the requirement.

action = driver.find_element(By.CSS_SELECTOR, '[data-testid="primary-action"]')
assert action.text == "Testphase starten"   # only when German copy is under test
action.click()

3. Broken claim: desktop resize equals mobile fidelity

The following example makes the Broken claim: desktop resize equals mobile fidelity behavior concrete. Read it with the stated assumptions, then compare its observable output or state changes with the explanation that follows.

# Useful responsive evidence:
driver.set_window_size(390, 844)

# Incorrect conclusion:
# assert "iPhone Safari is compatible"  # not supported by this observation

The correction is semantic, not technical: rename the row desktop-compact-390x844. If mobile Safari behavior is a release requirement, provision Apple-supported Safari/iOS infrastructure and run that actual row.

4. Broken assertion: runner/browser timezone leaks into expected text

The following example makes the Broken assertion: runner/browser timezone leaks into expected text behavior concrete. Read it with the stated assumptions, then compare its observable output or state changes with the explanation that follows.

# Brittle: expected text assumes the test runner/browser is in Europe/Berlin.
assert driver.find_element(By.CSS_SELECTOR, '[data-testid="date"]').text == "28.08.2026"

# Better: assert machine-readable business instant first.
date = driver.find_element(By.CSS_SELECTOR, '[data-testid="date"]')
assert date.get_attribute("data-iso") == "2026-08-28T00:00:00Z"

# Then record environment inputs for presentation diagnosis.
print(driver.execute_script("return navigator.language"))
print(driver.execute_script("return Intl.DateTimeFormat().resolvedOptions().timeZone"))

If localized date rendering itself is the requirement, control the locale/timezone input explicitly for that environment and assert the approved localized result. Do not let an unknown CI runner decide the oracle.

5. Browser-specific feature without a capability/support guard

Some product behavior legitimately differs by browser or platform: permission UI, media codecs, enterprise policy, WebAuthn integration, Safari-specific behavior, or feature rollout. Do not scatter if browser == ... branches merely to make failures disappear. First define whether the difference is supported product behavior.

browser = driver.capabilities.get("browserName")
version = driver.capabilities.get("browserVersion")

if browser == "safari":
    print(f"Safari-specific evidence path for version {version}")
    # Assert the documented Safari product behavior here.
else:
    # Assert the portable business contract here.
    pass

A browser branch is justified only when the product/support contract is intentionally browser-specific and the row is still observable.

6. Safari on non-macOS: infrastructure gap, not “driver flakiness”

SafariDriver is supplied with Safari by Apple and Safari automation must be enabled on Apple infrastructure. A Windows or Linux runner that lacks Safari cannot satisfy a Safari matrix row merely by setting browserName=safari. Treat the row as unavailable infrastructure and surface that gap in preflight.

import platform

if platform.system() != "Darwin":
    raise SystemExit(
        "Safari/macOS row unavailable on this host. "
        "Use an authorized Mac/Safari lane; do not substitute Chromium."
    )

7. “Chromium passed” is not “all browsers passed”

Chrome and Edge can reveal browser-product differences—policies, packaging, feature flags—but they share Chromium engine lineage. If a CSS/DOM/event compatibility risk needs engine diversity, schedule Firefox/Gecko and, when product support requires it, Safari/WebKit on Apple infrastructure.

8. Performance and capacity: diagnose where the time goes

The following table organizes the key choices and evidence for Performance and capacity: diagnose where the time goes. Use it together with the surrounding prose so the rows serve as a comparison aid rather than standalone rules.

9. Security-sensitive compatibility operations

Never solve cross-browser failures by disabling TLS validation globally, loading personal browser profiles, exporting enterprise cookies, exposing Grid publicly, or testing real production accounts. Use synthetic local targets. If corporate proxy, trust-store, identity, or browser policy differences are the real problem, reproduce them in an authorized disposable environment and document the boundary.

10. Controlled failure exercise

Run the Chapter 16 fixture in German and execute the translated-text locator from section 2. Preserve the exception and screenshot. Then change only the locator to the stable test hook; keep browser, viewport, locale, test data, and assertion meaning unchanged. The repaired row should pass without retry, sleep, JavaScript click, or locale rollback.

11. Summary and bridge

Compatibility triage depends on exact row identity and first-failure evidence. Lesson 5 packages the discipline into a small release-oriented checkpoint: execute a fast risk-based matrix twice, preserve capabilities/screenshots, explain one browser difference, and explicitly document what is excluded from fast CI.

Knowledge check

Official references and version notes

• Selenium 4.47 release notes — stable binding/Grid baseline pinned for this chapter.
• Selenium downloads and supported platforms — current stable releases and browser/platform support links.
• Supported Browsers — browser-specific capability boundaries.
• Working with windows and tabs — standard window-size APIs used for responsive desktop rows.
• Browser Options — standard and browser-specific option/capability model.
• Selenium Grid — remote, parallel, cross-machine and cross-platform execution boundary.
• Getting started with Selenium Grid — local Grid prerequisites and Selenium Manager driver setup.
• WebDriver BiDi — current cross-browser event-stream direction; not required by the mandatory Chapter 16 matrix.
• Docker Selenium Grid — official container/Helm distribution entry point; containerized Grid is optional here.
• Safari specific functionality — Selenium-side SafariDriver setup and options.
• Apple: Enable WebDriver on macOS — Safari remote automation must be enabled on macOS.
• Apple: Testing with WebDriver in Safari — Apple-provided SafariDriver and WebDriver execution model.