Traceability and Regression Strategy
Prove every requirement has a test, and build a regression strategy that catches old bugs coming back without re-testing everything by hand every release.
What you'll learn
- Build a traceability matrix linking requirements to test cases
- Identify a requirement with no test coverage using a traceability matrix
- Explain how automation changes what a sustainable regression strategy looks like
Prerequisites
Explanation
A project has 40 requirements and 120 test cases. Is every requirement actually covered? Nobody can answer that by eyeballing two separate lists — you need a traceability matrix: a mapping that links each requirement to the test case(s) that verify it. Read one way, it answers "which tests cover requirement R12?" Read the other way, it answers the more dangerous question: "which requirements have zero test cases pointing at them?" A requirement with no linked test case isn't just under-tested — as far as testing evidence goes, it's completely unverified, and that's the exact kind of gap that ships silently because nobody wrote it down anywhere obvious.
Traceability also matters when a requirement changes. If requirement R12 changes and the matrix says test cases 45, 46, and 52 verify it, you know exactly which tests need review — without traceability, a changed requirement leaves you guessing which of 120 test cases might now be stale.
The other half of this lesson is regression strategy: as a product grows, the number of previously-passing behaviors that a new change could accidentally break grows with it. Re-running every test manually before every release does not scale — a suite that takes a day to run manually becomes a suite nobody actually runs before a Friday release. This is exactly where automation earns its keep: a regression suite that runs in minutes, unattended, on every code change, catches old bugs coming back without costing a human day of repetitive manual clicking every single time.
A sustainable regression strategy is deliberate about what gets automated and what stays manual: stable, frequently-repeated checks (does login still work, does checkout still complete) are ideal automation candidates — they change rarely and run constantly. Areas still actively changing, or requiring human judgment (does this new design actually feel right, is this error message actually clear to a real user) are often better left to manual and exploratory testing, at least until they stabilize. Automating a test for a feature that's still being redesigned weekly just means rewriting the automation every week, which usually costs more than it saves.
Example
A tiny traceability matrix, and a function that finds requirements with zero linked test cases — exactly the gap that matters most.
const requirements = ["R1", "R2", "R3"];
const traceability = {
R1: ["T1", "T2"],
R2: [],
R3: ["T3"],
};
function findUncoveredRequirements(reqs, matrix) {
return reqs.filter((r) => !matrix[r] || matrix[r].length === 0);
}
console.log(findUncoveredRequirements(requirements, traceability)); // ["R2"]Try it yourself
Add a test case to R2's array so it's no longer uncovered, then re-run.
Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.
Guided exercise
Guided exercise
Given the matrix below, set uncovered to the array of requirement names with zero linked test cases, using the findUncoveredRequirements function already defined.
Checks: correctly finds the uncovered requirements
Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.
Stuck? Get a hint.
Independent exercise
Independent exercise
Write a function recommendedApproach(isStableAndRepeated, isStillActivelyChanging) that returns 'automate' if the check is stable and repeated, 'manual' if the area is still actively changing, and 'manual' as a safe default otherwise.
Checks: a stable, repeated check is recommended for automation · an actively-changing area stays manual · the safe default is manual
Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.
Stuck? Get a hint.
Common mistakes
- Building a traceability matrix once at project kickoff and never updating it as requirements change, so it silently becomes inaccurate.
- Automating a regression test for a feature that's still being redesigned weekly, spending more time maintaining the automation than it saves.
- Treating "no test case is linked to this requirement" as a minor gap instead of what it actually is: zero testing evidence for that requirement.
Knowledge check
Takeaway
A traceability matrix turns "is everything tested?" from a guess into a checkable fact, and a sustainable regression strategy automates the stable, repeated checks while keeping still-changing areas manual.
Summary
This lesson covered building a traceability matrix to find requirements with no test coverage, and choosing what to automate versus test manually as a product grows.
References
Your notes
Notes save automatically.
Finished this lesson?
Mark it complete to track your progress and schedule a future review.
AI tutor
The optional AI tutor isn't enabled in this deployment. All lessons, exercises, quizzes, and search work fully without it.