End-to-end traceability

Azure DevOps Services

One of the chief advantages of adopting a platform such as Azure DevOps is the support it provides to trace work from requirements to deployment. You gain insight at each step of decisions made and the software deployed. The scenarios illustrated in this article are supported when you use Azure Repos git repositories.

The following are some of the supported tasks to facilitate end-to-end traceability:

  • Create a branch from a requirement
  • Create a pull request of updated branch
  • Validate the pull request using a build pipeline
  • Create and run inline tests on requirements
  • Merge the pull request into the main, default branch
  • Deploy changes into production with deployment status to Azure Boards
  • Monitor and report on requirements traceability


Tracking the origin of work through delivery, and the ability to trace work across the development lifecycle, is essential to achieving end-to-end traceability.

End-to-end traceability is supported by linking various objects such as work items, branches, commits, pull requests, builds, and releases. Build in reports and Analytics support the ability to monitor traceability in real time. This article presents an overview of Azure DevOps traceability support without going into the details of how to enable and support traceability. More detailed information is provided under Related articles.

Traceability and linking

Throughout the development lifecycle, you can capture which code changes, builds, and releases support the completion of a work item. In this way, your team can understand what work was done or how a bug was fixed through the audit trail of changes to the code base.

The link types used to construct these links for Git repositories—as illustrated in the following image—are Build, Found in build, Integrated in build, Branch, Commit, Pull Request, and Integrated in release stage.

Conceptual image of code, build, and release links to work items.

Branch from a requirement

You can accomplish many tasks with a single click from the product Kanban board. Here we show creating a branch from a requirement by opening the work item card menu.

Screenshot of Kanban board card, menu, choose New branch option.

You can name and label a branch off the default main branch from the dialog that opens. The work item is automatically linked to the branch you created with the Branch link type.

Create a branch dialog.

You can also accomplish this task through the work item form by choosing the create a branch link.

Work item form, Create a branch link.

Create a pull request from a requirement

After code changes have been made to the new branch, developers can then create a pull request from the requirement by opening the work item form.

Work item form, Create a pull request.

Another advantage of driving software development from the Kanban board and work item is to encourage developers to input comments as they work to further the audit trail of changes occurring.

Add and run tests from requirements

Just like you can create a new branch from the Kanban board, you can also add tests to the work item.

Screenshot of Kanban board card, menu, choose Add test option.


Test traceability supports linking a test to a set of requirements and validating that the application works as expected.

After adding and defining the tests, you can run them from the Kanban board and set the test status.

Screenshot of Kanban board card, test menu, choose Run test.

Test integration with the Kanban board makes it easy for teams to get started with manual testing and then take advantage of the full testing capabilities provided by Azure Test Plans. The Kanban board shows the test added to support the requirement when test cases are created from the Kanban board or when requirement-based test suites are created under Test Plans.

Manual and automated testing

Teams that are moving from manual testing to continuous, automated testing, and have a subset of tests already automated, can execute them as part of a pipeline or on demand. Referred to as planned testing, automated tests can be associated to the test cases in a test plan and executed from Test Plans. Once associated, these tests contribute towards the quality metrics of the corresponding requirements.

Deploy changes into production

After you define a pipeline to build and release the code changes, you can track the deployment of the requirement to each release stage. From the work item form, you can quickly open the links to builds and releases from the Deployment and Development control sections.

Deployment and Development controls

When you open the work item form, you can see the stages the requirement has been deployed to, and drill down for greater details by choosing the links. Under the Development section, you can open the branch ,commit, or pull requests that have been linked to the requirement.

Work item form, Deployment control, Release Settings Stages.

The Deployment control shows release information for those work items that have been associated to a Git commit which is part of a build being released.

Release view

The following image illustrates the multiple environments that the release is targeting which the selected work item is associated with.

Example showing multiple environments that the release is targeting.

Release settings

You manage the deploy to production view options from the release settings.

Screenshot of Release pipeline Options>Integrations settings.

The work item deployment control displays the status of releases within those work items that are associated with commits in the build and those release pipelines you've configured to report deployment information to Azure Boards.

Requirements Traceability Matrix

Requirements traceability relates and documents two or more phases of a development process, which can then be traced both forward or backward from its origin. Requirements traceability provides teams insights into indicators such as quality of requirements or readiness to ship requirements. A fundamental aspect of requirements traceability is association of the requirements to test cases, bugs and code changes.


The Requirements Traceability Matrix (RTM) is a document that links requirements throughout the validation process. The purpose of the Requirements Traceability Matrix is to ensure that all requirements defined for a system are tested in the test protocols.

Requirements traceability reports

Requirements traceability reports

Requirements quality widget

Bug traceability

View the bug with the test result, directly in context, within the Tests tab. The Work Items tab also lists any linked requirements for the test result.

Bug traceability

Source traceability

Based on the build or release pipeline, you can choose the timeline or pipeline view to see what code changes were committed. You can analyze the code changes to identify the potential root cause of the test failure.

Screenshot of source traceability.

Test analytics

Test analytics for builds

To help teams find and fix tests that fail frequently or intermittently, use the top failing tests report. The build summary includes the Analytics page that hosts this report. The top-level view provides a summary of the test pass rate and results for the selected build pipeline, for the specified period. The default range is 14 days.

Screenshot of build analytics.

Test analytics for releases

Open a build or release summary to view the top failing tests report. This report provides a granular view of the top failing tests in the pipeline, along with the failure details.

For tests executing as part of release, access test analytics from the Analytics link at the top right corner. As with build, the summary provides an aggregated view of the test pass rate and results for the specified period.

Screenshot of release analytics.

Track the quality of requirements

To track the quality of work items that belong to the Requirements category. This includes work items such as User Stories (Agile), Product Backlog Items (Scrum) and Requirements (CMMI).

Screenshot of requirements tracking, OData and PowerBi.

Test failures

Open a build or release summary to view the top failing tests report. This report provides a granular view of the top failing tests in the pipeline, along with the failure details.

Screenshot of test failures.

To learn more about any of the concepts introduced in this article, refer to the following articles.



Reports and Analytics