Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

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 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 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. And then 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 a Defect to Requirement traceability report is to get a better sense of how many defects are holding up requirements and more importantly, which defect(s) is impacting the most number of requirements – thereby allowing for better bug-fixing prioritization.

Access

Traceability in Zephyr for JIRA can be accessed from the top menu or from the “Tests” menu in the Project sidebar

IMPORTANT

: In order to get useful traceability reports, ensure the following during test creation and execution:

  • Your tests are linked to requirements
  • Defects that are filed are linked to the test executions in which they were found

Types of Traceability Reports

Requirements to Defects

Select a Version and a particular Issue Type that can be the starting point of your traceability report. That is usually a “New Feature” issue-type or a “Story” or an “Epic”. The resulting list of issues can then be narrowed down to the ones you want a report on. Selecting the “Requirement to Defect” option and clicking on “Generate Traceability Report” will give you a full traceability report from Requirements --> Tests --> Test Executions --> Defects.

This can then be exported as an HTML file or an Excel file for further manipulation.

Useful for:

  1. Keeping track of progress at various stages of the software release cycle
  2. Audit and Compliance reports
  3. Customer Delivery Reports


Here's an example of such a report:

 

 

Defects to Requirements

Select a Version and a particular Issue Type that can be the starting point of your traceability report. That is usually a “Bug”. The resulting list of issues can then be narrowed down to the ones you want a report on. Selecting the “Defect to Requirement” option and clicking on “Generate Traceability Report” will you give you a full traceability report from Defects --> Test Executions --> Tests --> Requirements.

This can then be exported as an HTML file or an Excel file for further manipulation.

Useful for:

  1. Keeping track of how many open defects are impacting requirements
  2. Prioritizing defect fixing based on which defect(s) is impacting the most number of requirements
  3. Creating defect-regression test cycles for individual requirements based on number and status of defects

Here's an example of such a report:

  • No labels