How do you design a cross-browser test strategy?

Cross-browser testing is a cost problem before it is a tooling problem. Every added browser multiplies runtime, infrastructure and triage effort. The matrix should reflect actual traffic, contractual requirements and known engine differences, not a wish list.

@Test
@Parameters("browser")
public void checkoutWorks(String browser) {
    WebDriver driver = BrowserFactory.create(browser, true);
    try {
        new CheckoutPage(driver).completeOrder();
        Assert.assertTrue(driver.getCurrentUrl().contains("/confirmation"));
    } finally {
        driver.quit();
    }
}

public static WebDriver create(String browser, boolean headless) {
    if ("firefox".equals(browser)) {
        FirefoxOptions options = new FirefoxOptions();
        if (headless) {
            options.addArguments("-headless");
        }
        return new FirefoxDriver(options);
    }
    ChromeOptions options = new ChromeOptions();
    if (headless) {
        options.addArguments("--headless=new");
    }
    return new ChromeDriver(options);
}

• Use analytics to prioritise Chrome, Safari, Firefox and Edge by real share
• Run the full suite once and a critical-path subset on the rest
• Keep browser-specific options in a factory, not in test bodies
• Test on the engines users actually have, including mobile Safari where relevant
• Cloud grids provide browser coverage but add cost and network variability
• Track failures by browser to distinguish product bugs from environment issues

Safari and WebKit often surface differences in date inputs, autoplay, storage and focus behaviour. Those are exactly the areas worth targeted tests. Running every test on every browser can double cost without finding a new class of defect.