Cross-browser testing: which browsers are worth covering?
Cross-browser testing verifies that a website works in the browsers and on the devices your customers use. The goal is not to run every test in every version that exists. You need a sensible matrix that covers important combinations without disproportionate time and cost.
Why testing in one browser is not enough
Modern browsers use different rendering engines and handle some web features differently. A problem can appear in a form, page layout, file handling, or payment. If the team develops primarily in Chrome, a defect visible only to Safari or Firefox users may go unnoticed.
The opposite extreme is trying to cover every combination of browser, version, operating system, and screen size. The test matrix grows quickly, results arrive late, and the team maintains configurations that almost nobody uses.
How to choose appropriate coverage
1. Combine data and commitments
Start with traffic analytics, customer-support reports, and the browsers the product officially supports. For a public service, also consider users whom analytics may not capture accurately. If you have contractually agreed to support a specific platform, it belongs in the matrix even if it represents a smaller share of traffic.
2. Divide tests by risk
- Primary configuration: a broader suite can run in it on every change.
- Other important browsers: regularly verify critical journeys in them, such as sign-in, ordering, and payment.
- Targeted combinations: add them for features where you already know about differences or that use sensitive web APIs.
This division gives important journeys broader coverage without multiplying every edge-case test by the number of browsers.
3. Distinguish a browser from its engine
Playwright can run the same test in the Chromium, Firefox, and WebKit engines and also supports the branded Chrome and Edge browsers. WebKit is useful for finding some issues relevant to Safari, but it is not the branded Safari browser itself. If you need confidence in a specific version of Safari and its operating system, add a test in a real, compatible environment.
4. Update the matrix regularly
Browser shares and versions change. At least after a significant change in the product or user base, review your analytics, supported platforms, and test-tool version. Deliberately remove a configuration that is no longer needed and document the reason.
What to watch out for
An emulated screen size is not a complete substitute for a real mobile device. It does not verify every difference in touch interaction, the system keyboard, or performance. Depending on the risk, supplement critical mobile journeys with a check on a physical device.
What you gain
- Coverage reflects your customers and declared support.
- You detect critical defects in another browser sooner.
- The test suite does not grow merely because another combination exists.
- You can explain why each configuration remains in the matrix.
Next step
Review browser shares over the past few months and identify the three most important user journeys. If you would like to turn this data into a practical test matrix, contact us. We will propose the coverage and run frequency according to your product’s risk.