Traceability & Coverage

Link to Test Cases

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.

How to Link Test Cases

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, expand the Traceability section and find the Test Cases field.
3. Click the + (Link test cases) button beside the field. 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. Confirm to create the links. The linked test cases now appear in the Test Cases field.

Bidirectional Nature of Links

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, the test case is listed in the Test Cases field of the Traceability section.
• On the test case detail view, the requirement is listed under Requirement ID in that test case's Traceability section.

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 Test Cases field. Unlinking does not delete the test case; it only removes the association between the test case and the requirement.

Defects on a Requirement

Knowing which business needs are impacted by known issues is what makes a requirement's health readable at a glance. In TestKase you never link a defect to a requirement directly -- the relationship is derived from the test case the two have in common.

How the Defects Field Is Populated

The Defects field in a requirement's Traceability section lists every defect that is linked to a test case which is itself linked to this requirement. To make a defect show up against a requirement:

1. Link the test case to the requirement (Traceability -> Test Cases on the requirement, or Requirement ID on the test case).
2. Link the same test case to the defect (Defects ID on the test case, or Traceability -> Test Cases on the defect).
3. Reopen the requirement. The defect now appears in its Defects field, with a refresh control that re-reads the defect statuses.

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-flight defects (assigned, in testing, deployed) -- The issue is being addressed. Track the defect's progress to know when the requirement will be fully satisfied again.
• Resolved defects (closed, achieve) -- The defect has been resolved and verified. It continues to appear for as long as the shared test case links remain, giving you a historical record of which requirements were previously impacted by bugs.

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. Because both the requirement and the defect hang off that same test case, TestKase can show each from the other -- 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 the failing test case, which is already linked to 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.

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 the project, giving you a clear picture of testing completeness. 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.

Coverage counts every requirement in the project, regardless of its status.

How Coverage Is Calculated

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

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

All requirements are included in coverage calculations, regardless of their status. 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.

Coverage Reports

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

• Requirement Coverage -- A donut showing how many requirements in the project are covered and how many are uncovered. It reflects the current state of the project and takes no filters.
• Uncovered Requirements -- A table of the requirements that have zero linked test cases, ordered by requirement ID. It takes no filters.
• Traceability Matrix -- A table of every requirement with its linked test-case count and the IDs of those test cases. This is the primary artifact for compliance audits and release sign-off. It does not include defects.

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.