Skip to content

Compatibility Testing

Compatibility testing checks that the software behaves correctly across the environments users actually have: operating systems, browsers, devices, screen sizes, locales and versions. The matrix is the whole game.

browser
Chrome Firefox Safari WebView
Windows ─── ✓ ✓ – –
macOS ─── ✓ ✓ ✓ –
iOS ─── – – ✓ ✓
Android ─── ✓ ✓ – ✓
Plus: screen sizes, input methods, locales, app versions.

Combinatorial growth is real, so you pick a covering set of combinations rather than every cell.

Use it for

  • Public web apps where any browser or device may arrive
  • Native and mobile apps that target several OS versions
  • Regulated or enterprise products with a fixed, documented support matrix
  • CSS, fonts, video, WebRTC, file handling — the areas browsers disagree on most

Avoid or reduce it when

  • You control the runtime (a kiosk, an embedded device) — test only that target
  • You test every cell manually instead of pairing a matrix with automation
  • The matrix is undocumented, so nobody knows what “supported” means
  • You chase the newest browser while ignoring a large share of real traffic
Tool Ecosystem Notes
BrowserStack Cloud devices Real browsers and devices on demand
Sauce Labs Cloud devices Cross-browser and mobile testing cloud
Playwright JS/TS, Python, Java, .NET Chromium, Firefox and WebKit engines locally
Selenium Grid Multi Run tests across remote browsers and nodes
LambdaTest Cloud devices Selenium/Playwright grid in the cloud
Appium Mobile Native, hybrid and web apps on iOS/Android
responsive design mode Browsers Quick viewport and touch emulation
Appium Inspector Mobile Inspect and drive native mobile app elements
Terminal window
npm install -D @playwright/test
npx playwright install --with-deps
npx playwright test --project=chromium --project=firefox --project=webkit
import { defineConfig, devices } from '@playwright/test';
export default defineConfig({
projects: [
{ name: 'chromium', use: { ...devices['Desktop Chrome'] } },
{ name: 'firefox', use: { ...devices['Desktop Firefox'] } },
{ name: 'webkit', use: { ...devices['Desktop Safari'] } },
{ name: 'pixel', use: { ...devices['Pixel 7'] } },
{ name: 'iphone', use: { ...devices['iPhone 15'] } },
],
});
  • Define the support matrix explicitly. Publish which OS/browser/device versions you actually support, then test those.
  • Automate the matrix, manual-test the edges. Playwright and a cloud grid cover breadth; humans check visual and input nuances.
  • Weight by real analytics. Fix the browsers your users have, not the one you use.
  • Cover input and locale, not just rendering. Touch, keyboard, RTL and translated strings break differently.
  • Test older versions deliberately. The failure is often on the oldest supported version, not the newest.
  • Keep device lab images fresh. Stale emulators lie about modern behaviour.

Self-assessment quiz

Pick one answer per question, then press Check answers.

  1. What drives a compatibility testing effort?
  2. Which library runs Chromium, Firefox and WebKit from one test suite?
  3. Which is a cloud device farm for real browsers and phones?
  4. Why test keyboard, touch and locale behaviour, not only rendering?
  5. Full combinatorial testing of every OS, browser and version is unrealistic. What is the practical approach?