🎉 Zephyr for Jira is now Zephyr Squad! Read more about this |
|---|
| Redirect | ||||||
|---|---|---|---|---|---|---|
|
Documentation for Traceability Matrix Reports:
| Child pages (Children Display) |
|---|
Introduction
The ability to trace linkages from requirements all the way to defects or vice versa is particularly useful in a software release cycle. In fact, it can have a special meaning at various phases in that release cycle. For example, starting with requirements, knowing how many of them have tests written for them is useful in the early stages to ensure there is appropriate test coverage. Once the software has been built, keeping track of which test executions have passed for a particular requirement allows the team to make a quality statement about these requirements. Also, keeping track of how many open defects exist for requirements help make a Go/No-Go decision regarding the readiness of the software to be shipped.
Traceability reports can also be tremendously useful in producing end-of-release audit reports for compliance and regulatory reasons. They can also be used as customer delivery reports highlighting how every one of their requirements has been met, tested and is defect-free.
Another very important reason to run Defect to Requirement traceability reports is to get a better sense of how many defects are holding up the requirements and more importantly, which defect(s) is impacting the most number of requirements – thereby allowing for better bug-fixing prioritization.
To get accurate and useful traceability reports, ensure that the following criteria are met during testing (from test creation to test execution):
Your Requirements are linked to your Tests.
Your Tests are scheduled in a Test Cycle and are Executed properly.
Your Defects that are filed (created) are linked to the Test Executions in which they were found.