Cross-Browser and Cross-Device Testing

Why it matters

Browsers implement the same web standards with different code, at different speeds and with different defaults. A CSS rule, a form control or a JavaScript API that works in one engine can be missing or behave differently in another, and the failure reaches only that browser’s users: a whole group of customers who cannot finish a task while every browser in the office shows nothing wrong.

Testing too little leaves the most-used phone browser unchecked; testing everything everywhere multiplies the effort for little gain. A documented, data-based choice lets the tester say exactly what was tested, where, and which risk remains.

What changes between browsers and devices

The lesson on responsive testing asked whether a layout adapts to the viewport size. Here the question is different: does the same page behave correctly in another engine, on another operating system, with another input method? You run the existing critical journeys, such as sign-in, search and checkout, in each environment and watch for these differences:

• Engine and version: how HTML and CSS are rendered, and which CSS features and JavaScript APIs exist.
• Operating system: installed fonts (important for Arabic and Devanagari), native date pickers and select lists, file and permission dialogs.
• Input: touch, mouse or keyboard. A menu that opens only on hover has no reliable trigger on a touch screen.
• Device and settings: an on-screen keyboard covering half the page, toolbars that appear and disappear, a slow budget phone, zoom, dark mode and blocked third-party cookies.

Try it: Test Scenario Generator

Browser engines: count engines, not browser names

A browser engine is the part of a browser that turns HTML, CSS and JavaScript into the page you see. Three engine families cover the browsers most users have: Blink, in Chrome, Microsoft Edge, Opera, Samsung Internet and other browsers built on Chromium, the open-source code base behind Chrome; Gecko, in Firefox; and WebKit, in Safari. Each family also has its own JavaScript engine: V8, SpiderMonkey and JavaScriptCore.

This changes how you count coverage. Chrome and Edge on Windows share Blink, so a rendering defect usually appears in both; the second browser adds little engine coverage, although it has its own autofill and privacy settings. On iPhone and iPad, Apple has long required browsers to use WebKit and allows other engines only in some regions, so Chrome on an iPhone normally behaves like Safari, not like Chrome on Android.

Versions matter too: Safari on an iPhone is updated only with iOS, so an iPhone that cannot install the latest iOS keeps an older Safari. Before the team relies on a newer CSS or JavaScript feature, check the browser compatibility table on the feature’s MDN page.

A bug reporter’s browser can be read from the User-Agent request header, with care: Chrome on iOS, for example, identifies itself with CriOS but renders with WebKit.

Try it: User-Agent Parser Try it: Request Header Inspector

The support matrix: from usage data to tiers

A support matrix is the agreed list of browser, operating system and device combinations the product supports, with the depth of testing each one receives. It belongs in the test plan and is agreed by product, development and QA together, because it is also a promise to users.

Build it from evidence, not from the devices the team happens to own: analytics that count completed tasks such as orders as well as sessions, browsers named in the contract, and combinations that caused incidents. Then sort the rows into tiers:

• Tier 1: most of the traffic or revenue. Every release runs the critical journeys and the regression set, on real devices.
• Tier 2: smaller but meaningful. Every release runs a smoke set of critical journeys.
• Tier 3: best effort. Checked before major releases or when a user reports a problem.
• Engine rule: every engine your users have gets at least one combination in Tier 2 or higher, however small its share, because it can show defects no other browser in the matrix can.
• Pairwise rule: language, account state, zoom and dark mode interact with the engine too. Keep a tier’s platforms fixed and combine the other parameters by pairwise selection, as in the lesson on pairwise testing.
• Agree what users of an unsupported browser see, such as a clear message instead of a broken page, and review the matrix regularly, for example every quarter.

Try it: Pairwise Testing Generator

Where to run: local browsers, emulators and cloud device labs

Desktop browsers can be installed locally, with limits: Safari runs only on Apple computers, and the iOS Simulator needs a Mac with Xcode. The DevTools device toolbar changes the viewport, not the engine. Android emulators and the iOS Simulator run mobile browsers without the real hardware, so touch, the on-screen keyboard, the camera and the speed of a budget phone need real devices.

Cloud device labs, also called device farms, rent real phones, tablets and desktop browsers hosted by a provider. You open them in your own browser for manual sessions or run automated suites on them, with screenshots, videos and logs recorded. They give breadth without buying devices, but plan for their limits:

• A test environment that is not public needs the lab’s secure tunnel, a connection that lets the lab’s devices reach your private network, or an allow-list of the lab’s addresses, agreed with the team that owns the environment.
• Devices are shared and reset between sessions: use test accounts and synthetic data, never real customer data or personal accounts.
• Network, location and speed are the lab’s, not your users’, so do not judge performance there.
• Plans limit minutes and parallel sessions: run full suites on Tier 1 and smoke sets on Tier 2.

Worked example: a support matrix for an online shop

An online shop serves customers in Saudi Arabia in Arabic and English. The team exports 90 days of analytics, adds the engine to each row and applies its tier rule: 10% or more of sessions or orders is Tier 1, 2% up to 10% is Tier 2, under 2% is Tier 3. The numbers are illustrative.

Safari on iOS, Chrome on Android and Chrome on Windows become Tier 1. Chrome on iOS stays in Tier 2 although it shares WebKit with Safari, because its toolbar and autofill differ. Firefox is the only Gecko browser and has at most 1% anywhere, so the engine rule raises its largest combination, Firefox on Windows, to Tier 2. For Tier 1, pairwise selection combines the three platforms with language (Arabic, English) and account (guest, signed in): every pair of values in 6 runs instead of 12.

• WebKit only: on iPhones that cannot update past an older iOS, the order summary loses its layout because it uses a CSS feature older Safari versions lack. Chrome on the same iPhone fails too: one engine defect, not two browser defects.
• Edge only: autofill puts the district into the street field because the address fields lack autocomplete attributes. Chrome guesses correctly; the cause is the form, exposed by one browser’s feature.
• Every touch device: the delivery-fee explanation opens only on mouse hover, so phone users cannot open it. No desktop run could have found it.

Online shop — last 90 days (illustrative numbers)

Browser · OS                  Engine   Sessions  Orders  Tier
Safari · iOS                  WebKit      38%      41%   1
Chrome · Android              Blink       27%      22%   1
Chrome · Windows              Blink       12%      14%   1
Samsung Internet · Android    Blink        7%       5%   2
Edge · Windows                Blink        5%       7%   2
Chrome · iOS                  WebKit       4%       4%   2
Safari · macOS                WebKit       3%       4%   2
Firefox · Windows             Gecko        1%       1%   2 (engine rule)
Other, each below 1%          mixed        3%       2%   3
  Chrome · macOS, Edge · macOS / Android / iOS,
  Firefox · macOS / Android / iOS

Tier rule: 10% or more of sessions or orders → 1; 2% up to 10% → 2; under 2% → 3

Try it: Pairwise Testing Generator

Frequently asked questions

References

• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023The product quality model: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability and flexibility.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• User-Agent header — MDNMDN Web Docs (Mozilla)The User-Agent header format and the strings sent by the major browsers and crawlers.
• Playwright DocumentationMicrosoft (Playwright)Official documentation for Playwright, an end-to-end test framework that drives Chromium, WebKit and Firefox.