Test matrix
A test matrix is a table that lists the combinations of conditions a test set will be run under, most often browsers on one axis and devices or operating systems on the other, with each cell marked as covered, sampled or out of scope. It turns the vague aim of testing everywhere into a finite, agreed list that can be run and reported against.
The longer version
Each axis is a variable that changes how the software behaves: browser and version, operating system, device class, screen size, language, sometimes user role or network condition. The cells are the combinations. A team fills the cells from analytics and support obligations, then marks the ones it will test fully, the ones it will spot-check with a smoke pass, and the ones it declares unsupported. The matrix is then the definition of supported, and a bug reported from an unsupported cell is a request to change the matrix rather than a defect.
The term is sometimes used for a requirements traceability matrix, which maps requirements to the test cases that cover them and answers a different question: not where a test runs but whether every requirement has one. The browser and device matrix answers the first question. A related confusion is with the test plan; the matrix is one artefact inside a plan, the part that sets the environments, and it says nothing about approach, schedule or ownership.
The matrix fails by being complete. Multiplying six browsers by five operating systems by four device classes by three viewports gives a number of cells nobody will run, so the team runs the cells that are convenient and the matrix stops describing what was tested. A pruned matrix that names twelve combinations and is actually executed is worth more than an exhaustive one that is aspirational. The other failure is never updating it: a browser version nobody uses is still being tested while the phone that carries most sessions is not on the grid.
In a release cycle the matrix is agreed before test execution begins, appears in the test plan, and is the frame the test report is written against. Automated suites cover the cells they can, typically several browsers at a few viewports through a headless runner, and the remaining cells are assigned to people with the physical devices.
Common questions
What is the difference between a test matrix and a traceability matrix?
A test matrix, in its common browser-and-device sense, lists the environment combinations a test set runs under. A requirements traceability matrix maps each requirement to the test cases that cover it. The first answers where testing happens; the second answers whether every requirement is tested at all.
How do you decide which browsers and devices go in a test matrix?
Start from analytics: the browsers, operating systems and device classes that carry most real sessions, plus any combination a contract or accessibility obligation requires. Mark the top combinations for full runs, the next tier for a smoke pass, and declare the rest unsupported so a report from one of them is handled as a scope decision.
Who maintains the test matrix?
QA usually owns the matrix, with product signing off on which cells count as supported, since that is a commitment to customers. The matrix is reviewed when traffic shifts or a new platform launches, not every sprint, and any change to the supported set is recorded so old test reports still read correctly.
When is the test matrix agreed?
During test planning, before execution starts, so that everyone knows which combinations count as supported before the first bug is filed. The matrix is written into the test plan and referenced by the test report. Agreeing it late means results arrive from whichever browsers the testers happened to have open, and the report cannot say what was and was not covered.
Does a test matrix have to cover every combination?
A test matrix is useful because it does not. Multiplying every browser by every operating system, device class and viewport produces a grid nobody will run, and an unrun grid describes nothing. The working matrix names the combinations that will actually be executed, marks a second tier for a quick smoke pass, and declares the rest unsupported in writing.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.