Test matrix
A grid of browser, environment, configuration, and input combinations showing exactly which setups must be checked.
See it
What it is
A test matrix lays out the dimensions that can change and the combinations that need evidence: browser by operating system, plan by permission, database version by deployment mode, or input class by expected outcome. It makes coverage and deliberate omissions visible instead of leaving them scattered across test names and people's memory.
Reach for one when compatibility or configuration creates more than a few meaningful combinations. Mark each cell automated, manual, not applicable, or intentionally uncovered, and attach the risk or usage data behind that choice. GitHub Actions strategy.matrix can turn the selected CI rows into parallel jobs.
Gotcha: the full Cartesian product grows absurdly fast. A matrix with five dimensions of five values has 3,125 cells before a single input case appears. Cover high-risk combinations fully, use all-pairs coverage for lower-risk interactions, which a generator like Microsoft's PICT can compute for you, and do not count two Chromium-based browsers as independent engine coverage.
Ask AI for it
Build a risk-based test matrix for <feature> covering browser engine, operating system, viewport, account plan, permission role, and feature flag state. Mark each chosen combination with risk, owner, test type, and Automated, Manual, or Not Applicable status. Reduce low-risk rows with an all-pairs set generated by Microsoft's PICT, preserve every named production-critical combination, then emit the automated subset as a GitHub Actions strategy.matrix with explicit include and exclude entries and fail-fast: false.