Traceability matrix without spreadsheet hell

A traceability matrix maps requirements to the test cases that verify them, and to the defects discovered against each. In regulated industries it's mandatory; everywhere else it's the difference between "we tested it" and "we can prove we tested it". The common pattern is a spreadsheet — and the common failure is that the spreadsheet diverges from reality within weeks.

The fix isn't a better spreadsheet. It's deriving the matrix automatically from the underlying entity graph, so the view stays accurate as the underlying data evolves.

What a traceability matrix actually contains

The minimum schema:

The matrix lets the QA lead answer two questions instantly:

• Coverage: which requirements have no tests? (Last row is the red flag)
• Health: which requirements have failing tests or open defects? (Second row)

In a regulated environment, this becomes a third question: which requirements have test evidence that meets the audit standard?

Why the spreadsheet approach fails

Manually-maintained traceability fails in three predictable ways:

1. Update drift. A new test case gets added but the spreadsheet doesn't get updated. The matrix shows the requirement as untested when it isn't. Or worse: the matrix shows it as tested when the test was deleted six months ago.
2. Granularity collapse. The team writes "Test Case 2841" in the matrix, but TC-2841 has been split into TC-2841a and TC-2841b. The matrix still references the original; the report is wrong.
3. Defect drift. A new defect is filed against AC-4 but nobody updates the matrix. The defect-tracking system has the truth; the matrix is six weeks behind.

The cumulative effect: after three months, the matrix is roughly 60% accurate. After a year, 30%. It becomes a compliance artefact maintained for audits, not a working tool for the QA team.

The derived-matrix approach

The alternative: don't maintain the matrix; derive it. Each underlying artefact (requirement, test case, defect) carries explicit links to the others. The matrix view is a query over the graph, not a separately-maintained document.

The data model:

• Stories have an array of acceptance criteria
• Acceptance criteria are linked to test cases that verify them
• Test cases have test runs with pass/fail status
• Test runs can produce defects
• Defects are linked back to the acceptance criteria they affect

When you have this structure, the matrix is just a query: "for each requirement, list the linked AC, the test cases linked to each AC, the latest test-run status for each, and any open defects linked to any of the above."

The matrix is always current because the data it derives from is current. Updates happen at the source — when a defect is filed, it's linked to the AC; the matrix reflects it immediately. No double-entry.

Implementation options

Spreadsheet, manually maintained: works at small scale (≤ 100 ACs, single team) if the team has the discipline. Fragile beyond that.

Test-management tool with built-in traceability (TestRail with Test Runs, Zephyr with Cycles, qTest with Requirements): better than spreadsheets because the tool enforces some links. Still requires manual entry for the source artefacts; matrix accuracy depends on team discipline.

Issue tracker + test tool with integration (Jira + Xray, Jira + Zephyr, Linear + custom): the integration handles cross-system links. Matrix is queryable from the test tool. Quality depends on the integration's depth — Jira/Xray is the most mature; others vary.

Delivery platform with unified graph (Stride, in-house equivalent): everything in one entity graph. Matrix is a query, no integration to break. The model that scales best beyond 1K ACs but requires committing to a single platform for the entire delivery flow.

The right choice depends on team size and complexity. For most teams under 50 engineers shipping at moderate complexity, an integrated test tool is sufficient. For teams that need real-time accuracy across thousands of ACs (regulated industries, large enterprise), the unified-graph approach pays back.

What an audit-grade matrix needs

Beyond the basic schema, audit-grade traceability requires:

• Evidence preservation: every test run captured with timestamp, environment, executor, and pass/fail rationale.
• Audit trail on requirements: when an AC changes, the prior version is preserved with the timestamp and approver.
• Defect lifecycle visibility: when a defect was opened, who triaged it, what severity, when it was resolved, who verified the fix.
• Test-case lifecycle visibility: when a test was written, who reviewed it, when it was last updated, who approved the update.

Manual matrices can technically support all this with rigorous spreadsheet discipline. In practice, nobody does it for long. Tooling that captures these as side effects of the underlying workflow does it reliably.

A worked example

Team A has 800 ACs across 60 stories in a release. Their derived matrix shows:

• 92% of ACs have ≥1 linked test case (8% untested — flagged for the QA lead)
• 78% of ACs have a test case that passed in the last 7 days (14% have stale results — flagged)
• 6 ACs have open defects (each linked to specific defect IDs)
• All 800 ACs have an owner; the matrix surfaces 12 with no responsible engineer assigned

Team A's QA lead reviews this in 15 minutes per week and produces a status report for the release manager. The matrix never goes stale because no one maintains it directly.

Team B has the same scale but maintains the matrix in Excel. Their version (also at 800 ACs):

• "Around 80%" have linked tests (they aren't sure; the column hasn't been audited in months)
• They run a manual audit before each release that takes 2-3 days
• They typically find ~50 inconsistencies per audit (broken links, stale references, missing rows)
• The matrix is 3-4 weeks behind reality at any given moment

The difference compounds. Team A's QA lead spends 15 min/week; Team B's spends days per release. Multiply across releases and the labour cost difference is enormous.

Common pitfalls

• Over-detailed matrices: a matrix with 20 columns becomes harder to maintain than a matrix with 5 columns. Pick the 5 questions you actually need answered.
• Manual export to PDF/Excel for audit: this is where most spreadsheet errors come from. If you must export, do it from the source system, not from a maintained intermediate.
• Treating the matrix as a static artefact: a healthy matrix is a live query, not a snapshot. Static matrices are out of date the day they're produced.
• Ignoring the "untested" rows: the matrix's biggest value is surfacing what's NOT tested. Teams that focus on the "all green" rows miss the gaps.

Related reading

For the test-case structure that feeds the matrix, see Test-case design that doesn't go stale. For deciding which of the matrixed tests to run when, see Regression strategy at scale. For what to do with the defects the matrix surfaces, see Defect triage that doesn't drown the team.