What is a support matrix in compatibility testing, and what does one cell of it commit you to?
answer
- A published promise, not an inventory
- Axes crossed into cells
- Tiers, not a single yes or no
- Every cell costs run time and hardware
- A defect's cell decides its handling
basics
~20 sA support matrix is the published grid of platform combinations — operating system, version, engine, device class — where a product promises to work. Each listed cell is a commitment: a defect that reproduces there is one you owe a fix.
solid answer
~50 sA support matrix crosses the axes a product can vary on — operating system family and version, browser engine generation, device or hardware class, form factor — and each cell is one combination. It is a **published promise**, not an inventory of everywhere it happens to start. Most matrices are tiered: fully supported cells are tested every release and block a release when they fail; best-effort cells get a fix if it is cheap; unsupported cells mean a report is closed as out of scope, not that the product is blocked from running there. That tiering is what makes the matrix a budget document — every supported cell costs run time, a device or image to run it on, and a share of the defect tail. When triaging, the first question about a platform-specific defect is which cell it lands in, because that decides whether it blocks the release or waits in the backlog.
go deeper
Be ready to define the matrix, name a few axes, and say plainly that a listed cell is a promise. Knowing that a defect's cell decides whether it blocks the release is enough at this level.
An interviewer expects the mechanics: how axes multiply into cells, why matrices are tiered rather than binary, and how you turn the tiers into a test plan with different depth per tier.
Show the judgement of running one: which cells you actually exercise every release, how you keep the promise affordable as axes grow, and how you triage a defect by the tier of the cell it lands in.
Own the matrix as a commercial commitment. Be ready to argue what it costs, who signs off on adding a cell, how promises made outside engineering get reconciled into it, and how the tiers map to customer segments.
### What the artefact is A support matrix is the explicit statement of **where a product is promised to work**. It is built from axes — the dimensions along which the running environment can vary — and the cells are the crossings of those axes that the team commits to. Typical axes: - **Operating system family and version** — desktop and mobile families, and the specific versions or version ranges of each. - **Rendering or runtime generation** — the browser engine family and version band for a web client, or the language runtime or virtual-machine version for an installed one. - **Device or hardware class** — not individual models but classes: low-memory handset, current-generation handset, tablet, desktop. - **Form factor and display** — viewport size bands, pixel density, orientation. - **Peripheral or environmental constraints** where they matter — network class, printer or scanner families, screen-reader-free assumptions, offline capability. The crossing is what matters. "Version 14 of that operating system family" is an axis value; "version 14 on a low-memory handset in portrait" is a cell. ### Why the matrix is a budget, not a checklist Axes multiply. Four operating system versions times three device classes times two form factors is twenty-four cells, and a matrix that grows by one axis value grows by a whole column. Each supported cell carries real recurring cost: an image or a physical device to run on, minutes of pipeline time, and a share of the defect tail — the bugs that only ever appear there and that someone must reproduce, triage and fix. That is why real matrices are **tiered** rather than binary: - **Fully supported** — exercised on an agreed cadence; a reproducible defect here blocks the release or gets a hotfix. - **Best-effort / compatible** — expected to work, not routinely exercised; defects are fixed when cheap and are not release blockers. - **Deprecated** — still supported this release, announced for removal, usually with a warning shown to the people still on it. - **Unsupported** — out of scope. A report is closed as such. Note that unsupported does not mean blocked: the product may well run, it simply carries no promise. A candidate who says "we support everything" has not understood that the promise is what costs money. ### How the matrix drives the work Three things flow directly out of it. **Test selection.** The matrix tells you which combinations must be exercised and at what depth. A common shape is: full functional pass on one or two reference cells, a smoke subset on the rest of the fully supported tier, and nothing scheduled below that. **Triage.** A platform-specific defect's cell decides its handling. The same visual glitch is a blocker in a fully supported cell, a backlog item in a best-effort cell, and a closure in an unsupported one. This is exactly why every platform-specific report must carry the full platform coordinates — without them nobody can locate the cell. **Change control.** Adding a cell is a decision with a cost, so it belongs to whoever owns the release budget, and removing one is a commitment being withdrawn from people who may be relying on it. ### A worked example A hotel booking channel manager ships two clients: a web console used by front-desk staff and an installed connector that pushes rate and availability updates, peaking around 1,200 requests per minute during a promotion window. The matrix has separate sections. The console lists three browser-engine generations crossed with desktop and tablet form factors — six cells, of which four are fully supported and two are best-effort. The connector lists two desktop operating system families at their current and previous major versions, four cells, all fully supported, because a connector failure stops inventory updates outright and every property runs one. Notice the asymmetry: the same product has two matrices with different tiers because the blast radius differs. That asymmetry is the point — tiers follow consequence, not tidiness. ### Keeping it honest A matrix is only useful while it reflects reality. It should name the source of each commitment (a contract, a customer segment, an observed usage share), carry a review date, and be visible to support and sales, not just to the test team — a promise made in a sales conversation and absent from the matrix is the most expensive kind of untested cell.
- A defect reproduces only on a platform your matrix lists as unsupported. What do you do with it?Record it with full platform coordinates, then close it as out of scope for this release rather than silently deleting it. Two things make that safe: the report stays searchable if the platform is ever promoted into the matrix, and the volume of such reports is itself evidence for the next matrix review. If the platform turns out to be widely used by real customers, that is a matrix decision to escalate, not a bug to sneak a fix for.
- How would you choose which cells get a full functional pass and which get only a smoke subset?Pick reference cells that maximise coverage of the underlying differences — typically the newest and oldest supported version of each engine or operating system family, plus the lowest-capability device class — and give those the full pass. Everything else gets a subset weighted to the areas that historically break on platform boundaries: layout and input, storage and permissions, and anything touching the network stack. Usage share breaks ties.
- Who should own the matrix, and how often should it be revisited?It belongs with whoever owns the release commitment — product, with test and support as required signatories — because adding or dropping a cell changes both what is promised and what it costs. A review each major release, plus a trigger review whenever an upstream vendor ends support for a version, keeps it from drifting into either an unaffordable spread or a promise the team quietly stopped honouring.
It is a warranty schedule rather than a list of places the machine can be plugged in: the machine may well run outside the schedule, but only inside it does anyone owe you a repair.
saying these in an interview costs you the question
- Treats the matrix as everything the product happens to run on
- Cannot say what an unsupported platform actually means
- Assumes every supported cell gets identical test depth
- Adds platforms without costing the extra runs and devices
- Confuses one axis value with a full matrix cell
- Says the matrix is a test-team artefact only