Key takeaways
- A traceability matrix is a table that maps every requirement to test cases that verify it. If a row has no linked tests, that requirement isn't being validated.
- The matrix is only useful if it's maintained. A traceability matrix that was last updated three sprints ago is worse than having none, because it gives false confidence about coverage.
- For mobile apps, matrix needs rows for platform-specific behaviors (push notifications, device fragmentation, offline mode, deep links) that aren't in original product spec.
What a traceability matrix actually does
A traceability matrix connects two things: what product is supposed to do (requirements) and how you verify it does those things (test cases).
At its simplest, it's a spreadsheet. Requirements on left, test case IDs across top, and marks in cells where they connect. When you read across a row, you see which tests cover that requirement. When you read down a column, you see which requirements a test validates.
The matrix answers three questions that are hard to answer without one:
- What's not covered? A requirement row with no linked test cases means nobody is testing it. This is most common gap matrix reveals, and it's main reason teams build one.
- What changed? When a requirement gets modified mid-sprint, matrix shows which test cases need to be re-evaluated. Without it, change ripples through project and breaks things nobody thought to re-test.
- What's over-tested? A requirement with 15 linked test cases might be getting more attention than it warrants, while a higher-risk requirement has 2. The matrix makes this imbalance visible.
The four types (and which one you actually need)
Traceability matrix articles list four types. Here's what each one does and when it matters.
Forward traceability. Maps requirements → test cases. Answers: "is every requirement being tested?" This is one most QA teams need. If you build only one type, build this one.
Backward traceability. Maps test cases → requirements. Answers: "does every test trace back to a business need?" Useful for identifying orphan tests, test cases that exist but aren't linked to any current requirement. These are usually leftovers from deprecated features and can be pruned.
Bi-directional traceability. Combines forward and backward. Maps requirements → test cases AND test cases → requirements. Shows gaps in both directions. This is standard choice for regulated industries (healthcare, fintech, automotive) where audit compliance requires proof that every requirement is tested and every test has a purpose.
Full traceability. Extends bi-directional to include business requirements, functional specs, design documents, test cases, defects, and release artifacts. This is heavy. It's justified for safety-critical systems (medical devices, aviation software) and overkill for most SaaS or mobile app teams.
For most mobile QA teams, forward traceability (requirements → test cases) is enough. Add backward traceability if you suspect your test suite has accumulated bloat from feature churn.
How to build one step by step
Step 1: Collect your requirements
Pull requirements from wherever they live: Jira epics, user stories, PRDs, Figma annotations, Confluence docs. Each requirement needs a unique identifier. If your requirements don't have IDs, assign them (REQ-001, REQ-002, or use Jira ticket number).
Keep granularity consistent. "The app should work" is too vague. "User can reset password via email" is right level. Each requirement should describe one testable behavior.
Step 2: List your test cases
Pull test case IDs from your test management tool or test case documents. Each test case should already have a unique ID. If you're starting from scratch, write test cases first, then build matrix.
Step 3: Map connections
Create a table. One row per requirement. Columns for:
- Requirement ID
- Requirement description (short, one sentence)
- Priority (P0/P1/P2 or High/Medium/Low)
- Linked test case IDs
- Test type (manual, automated, or both)
- Status (not started, in progress, passed, failed)
Link each requirement to every test case that validates it. One requirement often maps to multiple test cases (happy path, error cases, edge cases). One test case can also cover multiple requirements if flow spans several features.
Step 4: Identify gaps
Sort by "linked test case IDs" column. Requirements with no linked tests are your coverage gaps. Prioritize filling gaps for P0 and P1 requirements first.
Also look for requirements where all linked tests are manual. If a P0 requirement is only covered by manual testing, it's a regression risk. Those are candidates for automation.
Step 5: Keep it alive
This is where most matrices fail. The initial build takes a day or two. The maintenance takes discipline. Add "update traceability matrix" to your definition of done for every sprint. When a requirement changes, update linked test cases. When a test case is added or retired, update matrix.
What matrix looks like for a mobile app
Generic traceability matrix examples use requirements like "user can log in" and "system displays error message." Mobile apps have additional requirement categories that most templates miss.
Here's what a partial matrix looks like for a mobile checkout feature:
REQ-107 has no linked test cases. That's gap. Without a matrix, this gap is invisible until a user with a screen reader reports issues from production.
Notice that REQ-102 (background/restore) and REQ-103 (slow network) are mobile-specific requirements that don't exist for web apps. If your matrix template doesn't have rows for these, you're missing coverage that your users will find for you.
Why most matrices die after sprint 3
The initial build is satisfying. The spreadsheet is clean. Every requirement has test cases. Coverage looks good.
Then reality happens:
- A product manager adds a requirement mid-sprint. Nobody updates the matrix.
- A developer changes how a feature works. The linked test cases are now stale, but matrix still shows them as "passed."
- A QA engineer writes 12 new test cases during a testing cycle. They update test management tool but forget to update matrix.
- Someone asks "what's our coverage for payments module?" The matrix says 95%. The reality is closer to 70% because three requirements changed since matrix was last updated.
A stale matrix is worse than no matrix. It gives stakeholders a coverage number they can point to in a meeting, and that number is wrong. Decisions get made based on false data.
How to keep it alive:
- Automate mapping where possible. If you use Jira + a test management tool (TestRail, Zephyr, qTest), requirement-to-test-case links live in the tool. The matrix generates itself from links.
- Add "update matrix" to your sprint's definition of done. Not optional. Not "if we have time."
- Review matrix during sprint retrospectives. Five minutes per sprint prevents decay that kills it.
- Assign ownership. If nobody owns matrix, nobody updates it. One person (usually QA lead) should be responsible for its accuracy.
When you don't need one
Not every project needs a formal traceability matrix.
- A 3-person team shipping a feature with 8 requirements can track coverage in their heads or in a Jira board.
- A prototype or hackathon project that's getting thrown away in two weeks doesn't need a matrix.
- A team that already uses a test management tool with built-in requirement linking already has a matrix. They just don't call it one.
You need a formal matrix when:
- Regulatory compliance requires proof of coverage (healthcare, fintech, automotive)
- The project has 50+ requirements and multiple QA engineers
- Requirements change frequently and team keeps missing ripple effects
- Stakeholders ask "are we done testing?" and nobody can answer with data
Drizz fits into "test cases" column of matrix. Each Drizz test covers a user flow written in plain English, and those flows map directly to requirements. Because Drizz runs on real devices, mobile specific rows in your matrix (device fragmentation, background/restore, screen size rendering) get actual coverage instead of sitting there marked "manual" with no execution history.
FAQ
What is a traceability matrix in testing?
A table mapping requirements to test cases. It shows what's covered, what's not, and what changed.
What's the difference between RTM and traceability matrix?
Same thing. RTM (requirements traceability matrix) is formal name. Teams use both terms interchangeably.
What are types of traceability matrices?
Forward (requirements → tests), backward (tests → requirements), bi-directional (both), and full (all artifacts).
How often should you update the traceability matrix?
Every sprint, as part of your definition of done. A matrix last updated three sprints ago is unreliable.
Can you automate a traceability matrix?
Yes. Test management tools like TestRail and Zephyr generate matrices from requirement-to-test-case links automatically.
