TestKase Docs
Core TestingRequirements

Traceability & Coverage

Link requirements to test cases and defects, track coverage, and build complete traceability.

Linking test cases to requirements is the core mechanism for tracking test coverage in TestKase. When a test case is linked to a requirement, it signals that executing that test case will verify (fully or partially) the behavior described by the requirement. This link is bidirectional: the requirement shows its linked test cases, and each test case shows its linked requirements.

  1. Open the requirement you want to link test cases to by clicking its title in the requirements list.
  2. In the requirement detail view, find the Linked Test Cases section.
  3. Click the Link button. A search dialog will open.
  4. Search for test cases by title or browse by folder. You can select multiple test cases at once.
  5. Click Confirm to create the links. The linked test cases now appear in the requirement's detail view.

Links between requirements and test cases are bidirectional. When you link a test case to a requirement, the link is visible from both directions:

  • On the requirement detail view, you will see the test case listed under Linked Test Cases with its title, priority, and status.
  • On the test case detail view, you will see the requirement listed under Linked Requirements.

You only need to create the link from one side -- it will automatically appear on the other. Similarly, removing a link from either side removes it from both.

Unlinking Test Cases

To remove a link, click the unlink icon next to the test case in the Linked Test Cases section. Unlinking does not delete the test case; it only removes the association between the test case and the requirement.

A requirement with zero linked test cases is considered uncovered. Coverage tracking (see Coverage Tracking below) uses linked test cases to calculate the coverage percentage for each requirement and across the project.

For complex requirements, link multiple test cases that each verify a different aspect or edge case. For example, a "User can log in" requirement might be linked to test cases for valid credentials, invalid credentials, locked account, two-factor authentication, and session timeout. A single test case can also be linked to multiple requirements if it spans several features.

Linking defects to requirements tracks which business needs are impacted by known issues. When a defect is linked to a requirement, it provides immediate visibility into which parts of the product are at risk and helps the team prioritize defect resolution based on requirement priority.

  1. Open the requirement you want to link defects to by clicking its title in the requirements list.
  2. In the requirement detail view, find the Linked Defects section.
  3. Click the Link button. A search dialog will open.
  4. Search for defects by title or browse the defect list. You can select multiple defects at once.
  5. Click Confirm to create the links. The linked defects now appear on the requirement's detail view.

Understanding Defect Impact on Requirements

When a defect is linked to a requirement, it signals that the requirement may not be fully satisfied in the current product. Consider the following when managing defect-to-requirement links:

  • Open defects -- The requirement is at risk. The defect represents a known gap between the expected behavior (the requirement) and the actual behavior (the bug). Prioritize fixing defects linked to P0 and P1 requirements.
  • In Progress defects -- The issue is being addressed. Track the defect's progress to know when the requirement will be fully satisfied again.
  • Closed/Achieved defects -- The defect has been resolved and verified. The link remains for historical traceability so you can see which requirements were previously impacted by bugs. You may choose to keep or remove these links based on your team's preference.

A requirement can be "covered" by test cases but still have open defects. Coverage tells you that tests exist; defect links tell you that some of those tests found problems. Both pieces of information are necessary for a complete picture of requirement health. A requirement with multiple open defects is a strong indicator that the feature needs immediate attention.

Traceability

Traceability is the ability to follow the chain from a business requirement through the test cases that verify it to the defects discovered during testing. This chain is the backbone of quality management in TestKase and enables your team to answer critical questions throughout the release lifecycle.

The Traceability Chain

Requirement -> Test Case -> Defect

This chain works as follows: a Requirement describes what the system must do. One or more Test Cases are linked to verify that the requirement is met. When a test case fails during execution and a bug is found, a Defect is logged and linked back to the failing test case and/or the impacted requirement. This creates a complete loop of accountability from business need to verified outcome.

Why Traceability Matters

  • Forward traceability -- Starting from a requirement, which test cases verify it? This ensures every requirement has adequate test coverage and nothing is left untested.
  • Backward traceability -- Starting from a defect, which requirement does it impact? This helps you understand the business significance of a bug and prioritize its resolution.
  • Impact analysis -- When a requirement changes (e.g., new acceptance criteria are added or existing behavior is modified), traceability lets you immediately identify which test cases need to be reviewed and updated.
  • Compliance and audit -- Regulated industries (healthcare, finance, automotive) require documented evidence that every requirement has been verified. TestKase's traceability chain provides this evidence automatically.
  • Root cause analysis -- When a defect is found in production, you can trace it back to the requirement and test cases to understand what was missed and improve your testing strategy.

Traceability in Practice

Consider a practical example. You have a requirement: "User can complete checkout with a credit card." You link three test cases to it:

  1. "Verify successful checkout with valid Visa card"
  2. "Verify successful checkout with valid Mastercard"
  3. "Verify error handling for declined card"

During a test cycle, test case #3 fails and a defect is logged: "Declined card shows blank error page instead of user-friendly message." The defect is linked to both the failing test case and the requirement. Now, anyone looking at the requirement can see:

  • 3 test cases are linked (requirement is covered)
  • 1 open defect exists (requirement is at risk)
  • The specific test case that revealed the defect

When a Requirement Changes

If a requirement is updated -- whether the title, description, priority, or acceptance criteria changes -- you should review all linked test cases to determine if they still accurately verify the requirement. Use the requirement detail view to see every linked test case, then open each one to check whether its steps and expected results still align with the updated requirement.

Use the Coverage & Traceability reports to visualize the complete traceability matrix across your entire project, identify uncovered requirements, and export compliance-ready documentation.

Build traceability incrementally. Start by linking test cases to your P0 and P1 requirements first. As your test suite matures, extend coverage to P2 and P3 requirements. Even partial traceability is far more valuable than none.

Coverage Tracking

Coverage tracking measures how thoroughly your requirements are verified by test cases. TestKase calculates coverage at the individual requirement level and aggregates it across folders and the entire project, giving you a clear picture of testing completeness at every level. It answers the fundamental question: "Are we testing everything we need to test?"

Coverage Statuses

  • Covered -- The requirement has one or more test cases linked to it. This means there is at least one test that verifies the behavior described by the requirement. Coverage does not imply that the test case has been executed or passed -- only that a test case exists.
  • Uncovered -- The requirement has zero test cases linked to it. This is a gap in your testing strategy that should be addressed, especially for high-priority requirements.

How Coverage Is Calculated

Coverage % = (Active requirements with >= 1 linked test case / Total active requirements) x 100

Example:
  Total Active Requirements: 50
  Requirements with linked test cases: 40
  Coverage = (40 / 50) x 100 = 80%

Only Active requirements are included in coverage calculations. Draft requirements are excluded because they are still being finalized, and Deprecated requirements are excluded because they are no longer relevant. A requirement is counted as "covered" if it has at least one linked test case, regardless of that test case's status or execution history.

Folder-Level Coverage

Coverage is also calculated per folder. This lets you identify which feature areas have strong test coverage and which areas need attention. For example, your "Authentication" folder might be at 95% coverage while your "Admin Dashboard" folder is at 40%, signaling where to focus test authoring efforts next.

Coverage Reports

Navigate to the Reports section of your project to access the following coverage-related reports:

  • Requirement Coverage Summary -- A high-level dashboard showing the overall coverage percentage, broken down by priority level (P0, P1, P2, P3) and by folder.
  • Uncovered Requirements List -- A filtered view showing only requirements that have zero linked test cases, sorted by priority so you can address the most critical gaps first.
  • Traceability Matrix -- A comprehensive matrix showing every requirement, its linked test cases, and its linked defects in a single view. This is the primary artifact for compliance audits and release sign-off.

Setting Coverage Goals

While 100% coverage is the ideal target, teams should set realistic goals based on their project's risk tolerance and resource availability:

  • P0 requirements: 100% coverage -- Every critical requirement must have at least one linked test case. No exceptions.
  • P1 requirements: 100% coverage -- High-priority requirements should also be fully covered in most projects.
  • P2 requirements: 80%+ coverage -- Aim for high coverage but accept that some medium-priority items may be deferred.
  • P3 requirements: Best effort -- Cover as many as resources allow, but these are the first to be deferred when time is limited.

Coverage tracking is automatic. As you link and unlink test cases from requirements, the coverage metrics update in real time. There is no manual step required to recalculate coverage. Track it regularly -- ideally at the end of each sprint -- to catch gaps early.

A high coverage percentage does not guarantee quality. A requirement can be "covered" by a single shallow test case. Aim for meaningful coverage by linking test cases that thoroughly verify the requirement, including happy paths, error handling, boundary conditions, and edge cases.