Compatibility testing

Compatibility testing is the checking of a website or application across the combinations of browser, operating system, device, screen size and network it will actually meet, to find behaviour that is correct in one combination and broken in another. It is non-functional testing: the feature works, and the question is whether it works everywhere the requirement says it must.

The longer version

The core artefact is the matrix: a table of the combinations the product commits to supporting, drawn from the audience's real analytics rather than from what the team happens to own. Each cell is a browser and version on an operating system on a device class at a viewport size. The test is to run the critical flows in each cell the plan marks as required and record which ones pass. A full matrix is unaffordable, so the plan names the cells that matter most and the ones tested only when something changes near them.

Cross-browser testing is the subset web teams usually mean when they say compatibility. Full compatibility testing also covers the operating system, the device hardware, the screen, the network, and backward compatibility with earlier versions of the product's own data and integrations. It is distinct from responsive testing, which checks layout at different widths on one browser; a layout can be perfectly responsive and still fail because one browser lacks an API the page assumes.

The hard part is naming the cell. A report that says the menu does not open, from a user somewhere in the matrix, is unactionable until someone learns which browser, which version, which device and which viewport, and by the time the reply comes back the reporter has moved on. Compatibility defects also hide behind the tester's own machine: a team whose members all use the same laptop and browser never sees the cell where the product fails.

Common questions

What is the difference between compatibility testing and cross-browser testing?

Cross-browser testing checks the same page across browsers and versions. Compatibility testing is the wider category: browsers, operating systems, device hardware, screen sizes, network conditions, and backward compatibility with older data and integrations. Cross-browser testing is where web teams usually start, and often where they stop.

How do you decide which browsers and devices to test?

From the audience's own analytics, not from the team's laptops. List the combinations that account for the bulk of real sessions, add the ones a contract or regulator requires, and mark each as required on every release or checked only when something nearby changes. The matrix is a commitment, so keep it short enough to honour.

Is compatibility testing functional or non-functional?

Compatibility testing is classed as non-functional testing. The feature is already known to work; the question is whether it works acceptably in every environment the requirement names. It is often run with functional test cases as the material, which is why the two are confused, but the pass criterion is environmental coverage rather than correctness.

Can compatibility testing be automated?

The execution can be: a functional suite run against a grid of real or emulated browsers and devices reports which cells passed, and screenshot comparison flags layout differences between them. What resists automation is judging the result, since a layout that differs is not always a layout that is wrong, and the long tail of real devices, extensions and network conditions that no grid contains. Teams automate the required cells and keep a manual pass for the rest.

What is backward compatibility testing?

Backward compatibility testing checks that a new version of the product still works with what the previous version left behind: data files and database records in the old format, integrations built against the old API, and clients that have not upgraded. Forward compatibility is the reverse question, whether the old version tolerates data the new one writes. Both belong in the compatibility plan for any product that keeps user data or exposes an API.

Bug reports that arrive ready to triage.

Collect replay, console, network and browser context with the Free plan.

<script src="…/widget.js" data-key="pb_pub_…">