QA Process
Test Coverage Matrix.
A coverage matrix maps every feature to the tests that cover it — manual, automated, and by risk — so gaps and redundant cases are visible at a glance instead of hiding in someone's head.
When to use it
Use this when you need to prove what is and isn't tested: planning coverage for a release, finding gaps in a suite you inherited, or showing a stakeholder where the risk still sits.
Who uses it
QA engineers tracking their own coverage, senior QA reviewing a suite for gaps, and leads who report coverage and defend where effort went.
On this page11 sections
WHAT IS A TEST COVERAGE MATRIX
A test coverage matrix is a grid that lines up what the product does against what your tests check. Each row is a feature or requirement; the columns record how it's covered — the scenarios, how many manual cases, how much is automated, the risk level, and the current state.
Its job is to make coverage visible. Read down a column and you see where automation is thin; read across a row and you see whether a high-risk feature is actually well tested. Either way, the gaps stop being invisible.
WHY COVERAGE MATTERS
Without a coverage view, "is it tested?" gets answered from memory — and memory favours the features you worked on recently. A matrix replaces that with a record anyone can check, which is what turns coverage from a feeling into a fact.
It also directs effort. When you can see that a high-risk feature has six manual cases and zero automation, the next thing to do is obvious. Coverage matters because it converts a vague worry about gaps into a specific, prioritisable list.
COVERAGE VS TRACEABILITY
These two matrices look similar and get confused, but they answer different questions. A coverage matrix asks "how well is each feature tested?" — it's about depth and type of testing. A traceability matrix asks "is every requirement linked to a test, and every test back to a requirement?" — it's about completeness of the chain.
You can have full traceability and poor coverage: every requirement has one test, but the high-risk ones need ten. And you can have deep coverage with gaps in traceability: lots of tests, but no line back to which requirement they protect. Mature teams keep both, for different reasons — the traceability guide is linked below.
MANUAL COVERAGE
Manual coverage records what a human checks by hand — the exploratory passes, the UX judgement, and the scenarios not yet worth automating. In the matrix it's usually a count of cases plus a note on what they cover, so it's clear this isn't a blind spot just because it isn't automated.
Track it honestly. Manual coverage that lives only in a tester's head disappears when they're on leave; written into the matrix, it's a repeatable part of the plan that the next person can run.
AUTOMATION COVERAGE
Automation coverage records what runs without a human — the regression checks, API tests, and end-to-end flows wired into CI. In the matrix, capture how much of each feature is automated and whether those tests are reliable, not just that some automation exists.
Be wary of counting automation as coverage when it's flaky or shallow. Ten automated checks nobody trusts cover less, in practice, than two that always tell the truth. The matrix should reflect coverage you'd actually rely on for a release decision.
RISK COVERAGE
Risk coverage is the most important column to read: it asks whether the depth of testing matches the risk of the feature. A high-risk feature with thin coverage is the row that should keep you up at night; a low-risk feature with heavy coverage is effort you could redeploy.
Pairing a risk level with each row turns the matrix into a prioritised to-do list. Sort by risk, scan the coverage, and the next test to write picks itself — this is risk-based testing made concrete, linked below.
BROWSER / DEVICE COVERAGE
For anything with a UI, coverage isn't just which features but on which browsers and devices. A flow that passes on desktop Chrome can break on mobile Safari, so the matrix should record the browser/device combinations a feature has actually been checked on.
You can't test every combination, so cover by usage and risk: the browsers and devices your real users bring, plus any the feature specifically depends on. Note the combinations explicitly so "works on my machine" never stands in for coverage.
API COVERAGE
For services, coverage means endpoints, methods, and contracts — not screens. Track which endpoints are tested, whether you cover success, validation errors, auth failures, and edge cases, and whether the response contract itself is checked.
API coverage is often where automation pays back fastest, because the tests are fast and stable. The matrix should show how thoroughly each endpoint is exercised, so a partially-tested endpoint isn't mistaken for a covered one.
EXAMPLE COVERAGE MATRIX
| Feature | Risk level | Manual cases | Automated cases | Coverage status |
|---|---|---|---|---|
| Login | High | 12 | 8 | Good |
| Password reset | High | 10 | 4 | Partial |
| Profile update | Medium | 8 | 0 | Manual only |
| Notifications | Medium | 6 | 2 | Partial |
BLANK TEMPLATE
| Feature | Requirement | Risk level | Test scenario | Manual coverage | Automation coverage | Status | Owner | Last tested | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Login | REQ-001 | High | Valid + invalid credentials, lockout | 12 cases | 8 automated | Good | A. Okafor | 2026-06-05 | 3DS path manual only |
| Password reset | REQ-002 | High | Request, expiry, reuse | 10 cases | 4 automated | Partial | A. Okafor | 2026-06-04 | Email link expiry not yet automated |
| | | | | | | | | | |