The Chain: Requirements → Tests → Executions → Defects
Every QA tool can draw a line from a requirement to a test case. The hard part is what the line has to survive — hierarchy, provenance, disagreeing counts, and links that quietly stop pointing anywhere.
Every test management tool can draw a line between a requirement and a test case. It’s a list field. You pick some cases, you save, and the requirement now claims coverage.
The line is the easy part. Traceability is what that line has to survive — a requirement that grows children, a case that got into a run by three different routes, a defect that used to point at a specific step and now points at nothing in particular. Get any of those wrong and you still have a matrix. It just answers a question nobody asked.
Four edges, four different shapes
It’s tempting to model the chain as one kind of link repeated four times. It isn’t. Each edge carries different information, because each one is answering a different question.
Requirement to test case is the simple one — a list of requirement IDs on the case. But requirements aren’t flat. A requirement can have sub-requirements and tasks beneath it, and they live in the same space, so anything that links to a requirement can link to any of them.
Test case to run is the interesting one, because Hawzu records how the case got there. A case pulled in by hand is marked as such; a case that arrived because it was attached to a requirement or a suite carries the name of what brought it. That’s provenance, not mode — it has nothing to do with manual versus automated testing. It’s how you can later ask which of your coverage was deliberate and which was inherited from a grouping decision somebody made a year ago.
Run to release is an absence as much as a presence. A run either belongs to a release or it doesn’t, and standalone runs aren’t second-class — plenty of real testing happens outside a release. The link is what makes a run count toward a ship decision.
Defect to anything is a map rather than a list, keyed by whatever the defect points at, and it records what kind of thing that is. A defect can be attached to a requirement, a test case, a run, or a release — and when it comes from a test case, it remembers which step. Not “this test found a bug.” Step four found it.
Coverage rolls up, and admits when it’s borrowed
Once requirements have children, coverage gets ambiguous. A parent requirement with no directly linked tests, whose four sub-requirements are thoroughly covered — is that covered or not?
Both answers are defensible and only one is useful. Hawzu rolls up: a requirement row unions its own links with everything linked to any descendant beneath it. A parent isn’t uncovered just because the work was organised one level down.
The part that matters is that it says so. Every test case on a requirement row is tagged with whether it’s linked directly or inherited from a child. The roll-up gives you the honest coverage number; the tag stops it from being a rounding error you can’t see. A requirement showing green entirely on borrowed coverage is a different situation from one that’s covered on its own terms, and the matrix has to let you tell them apart.
Two counts that disagree on purpose
Here’s a question with two correct answers: a test case ran in four executions this release — passed three times, failed once. How many results is that?
One, if you’re deciding whether the requirement is at risk. The current state of that case is what matters, and the current state is its latest verdict.
Four, if you’re looking at the execution breakdown. Three passes and a failure is what happened, and collapsing it to a single verdict hides the flakiness that’s the most interesting thing on the screen.
So the traceability matrix computes both, and uses each where it belongs. The latest-verdict count drives the risk assessment. The run-weighted count drives the displayed breakdown. They will not always agree, and a tool that forced them to agree would have to throw away one of two true things.
There’s a smaller version of the same discipline in the status vocabulary. When a case needs rerunning because its source drifted, that’s not a fifth outcome sitting beside passed and failed — it’s a case that hasn’t been validly executed yet, and the reports count it as Not Executed. One idea, one bucket.
Risk that explains itself
The last thing the chain owes you is a reason.
A requirement doesn’t just come back red. It comes back with the specific factors that made it red — no coverage at all, failing tests against it, open defects above a severity threshold — each carrying its own severity and its own detail line. Softer signals are separated from hard ones: a minor open defect, coverage that exists but has never been validated, a requirement whose last execution is old enough to be stale. Those are worth watching. They aren’t the same as a critical blocker, and flattening them into one colour makes the colour useless.
Defect attribution is transitive, too. A defect reaches a requirement either because it’s linked to it directly or because it’s linked to a test case that covers it. Teams file defects against whatever they were looking at when they found the bug; the matrix shouldn’t punish them for filing against the test instead of the requirement.
The link that pointed at nothing
The sharpest thing we learned building this came from a bug.
Defect-to-test-case links carry the specific steps they were raised against. Un-link the last remaining step and — in an earlier version — the link itself stayed behind, holding an empty list. It still rendered as a link. Every reader treated it as a link, because a link that exists is a link. It just didn’t point at anything any more.
That’s the failure mode traceability has that other features don’t. A broken chart looks broken. A broken chain looks fine, and quietly answers questions wrong for months — which is why a report built on it has to say what it’s measuring rather than just showing a number. Removing the last step is now the same terminal state as removing the link outright, and the whole operation is idempotent — a double-click used to raise a server error, which is its own small lesson about how often people double-click.
The chain isn’t valuable because it’s drawn. It’s valuable because every link in it still means what it claimed to mean — which is also what a run has to promise about the copy of the test case it froze at execution time.
A link that points at nothing still renders as a link. That’s the whole problem.
The requirement traceability matrix
