QA glossary
What is a traceability matrix?
A traceability matrix, often called a requirements traceability matrix (RTM), is a table that maps each requirement to the test cases that verify it and the defects found against it. It shows at a glance which requirements are covered, which are untested and which still have open bugs.
An example from QA practice
A medical app has 120 requirements. Each row of the matrix holds a requirement ID, its linked test cases, the latest result and any open defects. Before release, the QA lead filters for requirements with no passing test. Four rows come back, one of them the unit conversion on a dosage field. That gap is tested before sign-off, not after an auditor asks about it.
Forward, backward and both
A forward matrix starts from requirements and checks that each one has tests. A backward matrix starts from tests and checks that each one traces to a requirement, which exposes tests nobody asked for. A bidirectional matrix does both, and it is what regulated teams usually need.
It matters most in medical, financial and safety-critical software, where auditors ask for evidence that every requirement was tested. For a small product team the same view answers a simpler question: what did we not test?
How BetterQA does it
BugBoard, the test management tool we built, links test cases to Jira tickets, so ticket coverage comes out of the tool instead of a spreadsheet someone keeps by hand. Its release-decision report is one you could present to your auditors. BetterQA is ISO 13485 certified, the quality management standard for medical devices.
Related terms
Where traceability is an audit requirement, not a nice extra.