Traceability matrix
A traceability matrix maps requirements to the test cases that verify them, and to the defects discovered against each. Traceability lets a QA lead answer 'is requirement X tested?' and 'which requirements does this failing test affect?' — critical for regulated industries and useful for everyone else.
In practice, traceability lives on a continuum. The lightest form is a story-to-test ID column. The heaviest is a multi-axis matrix (requirement → AC → test case → test run → defect) updated continuously. Stride generates this view automatically from the underlying entity graph — every test case is linked to the AC it verifies, every defect to the test case that caught it. Most teams need the lightweight version; FDA-regulated and SOX-audited teams typically need the full matrix with audit trail.
Long-form posts that explore traceability matrix in depth — when to use it, common failure modes, how AI helps.
Related terms
- Acceptance criteria
Acceptance criteria are the conditions a story must satisfy to be considered complete — testable, bounded statements describing what the system does.
- Regression test
A regression test verifies that previously working functionality still works after a code change.
- Definition of Done
Definition of Done (DoD) is a team-wide checklist that every story must satisfy before being marked complete — typical entries include: code reviewed, tests passing, documentation updated, deployed to staging, AC verified.