Begin with audience and business risk
Review operating system, browser and screen data, then add target devices a new product may not have observed yet. Sign-in, checkout, booking and upload flows deserve higher priority even when they affect a smaller audience.
A low browser share is not an automatic reason to remove coverage; consider failure cost, customer commitments and accessibility needs.
Represent the major rendering engines
Desktop Chrome and Edge both use Chromium, so treating them as two independent engines while omitting Safari or Firefox creates a blind spot. A baseline normally includes Chromium, WebKit and Gecko representatives.
- Safari and WebKit on iPhone or iPad
- Chrome and Chromium on Android
- Firefox and Gecko on desktop
- Edge in managed Windows environments
Let features determine test depth
Content pages can receive a fast smoke test. Camera access, uploads, paste, drag and drop, payment, passkeys, media and advanced CSS need real browsers and devices. A viewport preview can find spatial defects but cannot validate an engine.
Create three execution layers
Run a small set per change, the core matrix daily or on release candidates, and full device and assistive-technology acceptance before major releases. Layering balances feedback speed with coverage.
- Change layer: critical page in one primary browser
- Candidate layer: three engines and representative viewports
- Release layer: high-risk devices, keyboard and screen reader
Refresh the matrix with evidence
Review traffic, support requests, error monitoring and browser versions each quarter. Record why a combination is added or removed so the matrix remains executable instead of expanding forever.