SpecSync Documentation
Getting StartedConfigurationGuidesDownloads
Azure DevOps
Azure DevOps
  • Introduction to SpecSync for Azure DevOps
  • Getting started
    • Getting started using SpecFlow
    • Getting started using Cucumber or other Gherkin-based BDD tool
  • Installation & Setup
    • Install as .NET tool
    • Install as .NET Console App
    • Install as native binaries for Linux or macOS
    • Install as Docker image
    • Setup and Configure
  • Features
    • Push features
      • Pushing scenario changes to Test Cases
      • Configuring the format of the synchronized test cases
      • Synchronizing Scenario Outlines
      • Add new Test Cases to an Area or an Iteration
      • Mark Test Cases as Automated
      • Setting Test Case state on change
      • Update Test Case fields
      • Attach files to Test Cases using tags
      • Customization: Setting Test Case fields with default values
      • Customization: Update custom Test Case fields on push
      • Customization: Ignoring marked Test Case steps
      • Customization: Ignoring Test Case Tags
      • Customization: Ignore non-supported local tags
      • Customization: Mapping tags
      • Customization: Synchronizing scenarios from feature branches
      • Customization: Reset Test Case state after change
      • Customization: Automatically link changed Test Cases
      • Customization: Synchronize linked artifact titles
      • Customization: Add Test Cases to Suites
      • Customization: Do not synchronize title
    • Pull features
      • Pulling Test Case changes to local scenarios
    • Common synchronization features
      • Configuration key
      • Remote scope
      • Linking Work Items using tags
      • Synchronizing Test Case hierarchies using Test Suites
      • Include synchronized Test Cases to a Test Suite (deprecated)
      • Excluding scenarios from synchronization
      • Synchronization conflict resolution
      • Re-link scenarios to new Test Cases
    • Test result publishing features
      • Publishing test result files
      • Support for Azure DevOps Test Plan / Test Suite based test execution
      • Customization: Publishing test results to multiple Test Suites
    • General features
      • Azure DevOps authentication options
      • Configuration file
      • Hierarchical configuration files
      • Local test case conditions
      • Configuration wizards
      • SpecSync plugins
    • Customizations
    • Plugin list
  • Licensing
  • Guides
    • What is my Azure DevOps project URL?
    • How to define the local feature-set to be synchronized
    • Filters and scopes
    • How to synchronize automated test cases
    • How to use SpecSync from build or release pipeline
    • How to publish test results from pipelines using the VSTest task
    • How to use the SpecSync Azure DevOps pipeline tasks
    • How to link GitHub pull requests
    • How to upgrade to a newer version of SpecSync
    • How to attach files to test results
    • Using SpecSync with SpecFlow+
    • Using SpecSync with Cucumber
    • Using SpecSync with Cypress
    • Using SpecSync with Postman
    • Using SpecSync with TestNG
    • Using SpecSync on macOS or Linux
    • Using SpecSync inside a Docker container
    • How to handle Test Cases of multiple parallel application releases
    • Migrating from SpecSync v3 to v5
    • Migrating from SpecSync v2 to v3
    • Migrating from SpecSync v1 to v2
  • Changelog
  • Release Model and Roadmap
  • Downloads
  • Reference
    • Command line reference
      • init
      • upgrade
      • push
      • pull
      • publish-test-results
      • re-link
      • version
    • Configuration reference
      • toolSettings
      • local
      • remote
      • knownRemotes
      • synchronization
        • push
        • pull
        • automation
        • state
        • areaPath
        • iterationPath
        • links
        • attachments
        • format
        • fieldUpdates
      • hierarchies
      • publishTestResults
      • specFlow
      • reqnroll
      • customizations
    • Compatibility
    • Older versions
  • Contact
    • SpecSync Support
    • Troubleshooting
    • FAQ
  • Project Website
Powered by GitBook
On this page
  • The work item tags
  • Using multiple tag prefixes
  • Link types
  • Restrict linked work item to be of a specific type
  • Linking Pull Requests
  • Linking GitHub Pull Requests
  • Linking Hyperlinks
  • Limitations

Was this helpful?

  1. Features
  2. Common synchronization features

Linking Work Items using tags

PreviousRemote scopeNextSynchronizing Test Case hierarchies using Test Suites

Last updated 5 months ago

Was this helpful?

SpecSync can synchronize the scenarios with Azure DevOps Test Cases. In order to be able to use these Test Cases in Azure DevOps, you might want to link them to other work items. For example, if the scenario is describing the behavior of the User Story #123, you make a link between the Test Case synchronized from the scenario and the story. This gives you a better traceability and allows you to create requirement- or query-based Test Suites in Azure DevOps. For example you can create a test suite that contains all Test Cases (scenarios) that are related to User Story #123.

Although you can establish these links manually, once SpecSync has created the test cases from the scenarios, it is an error-prone manual process. A better way to do this is to mark the relation of the scenarios to other work items via tags and let SpecSync create the necessary links between the work items.

For that you need to mark the scenarios with tags, like @story:123, and specify the tag prefix (in this case story) in the SpecSync . The links can be configured in the of the configuration.

{
  ...
  "synchronization": {
    ...
    "links": [
      {
        "tagPrefix": "story"
      }
    ],
    ...
  },
  ...
}

This will synchronize the scenario with the Azure DevOps test case and establish a link between the test case and the user story #123 work item.

The links created by SpecSync are by default are "tracked". This means that the links are removed when the tag is removed from the scenario. You can disable creation of tracked links by setting disableTracking to true in the link configuration. Non-tracked links and links created manually are never removed.

Links created by SpecSync v3.2 or earlier are not removed automatically.

The work item tags

The work item tags should follow the pattern @prefix:N, where prefix is a label of your choice (e.g. story, bug or wi) and N is the ID of the related work item (e.g. 123).

The work item tag can be specified at scenario level or feature level. In the latter case, it behaves like you would have applied the tag for all individual scenarios. This can be useful if all scenarios in the feature file are related to a feature or a user story work item.

If the work item with the specified ID does not exist or the user who performs the synchronization does not have permission for it, SpecSync will display an error message for that particular scenario. If at least one scenario has failed to synchronize, the command line tool returns with the exit code 10.

In SpecSync v3.3 or earlier, tags, where N is not a valid number, are ignored.

Optionally you can add an additional label to the work item tags to help the readers to understand what the referred work item is about. The additional label has to be separated by the work item number with a colon (:) character, like @bug:456:argument_error_for_empty_input .

Using multiple tag prefixes

In order to distinguish between the different relations in the feature file, you can also use and synchronize multiple prefixes. E.g. you can tag a scenario with @story:123 and @bug:456 indicating that the scenario was related to the user story #123 and it fixes the bug #456.

In order to use multiple tag prefixes, you have to list multiple link type configurations within the synchronization/links section.

{
  ...
  "synchronization": {
    ...
    "links": [
      {
        "tagPrefix": "story"
      },
      {
        "tagPrefix": "bug"
      }
    ],
    ...
  },
  ...
}

SpecSync does not check the type of the referred work item. Specifying @bug:123 will also make the link between the user story #123 and the test case. Though you can establish different link types for the different prefixes.

Link types

SpecSync creates a "Tests" link type between the test cases and the other work items by default. If you want to establish another kind of relationship (e.g. Parent), you can specify the link type in the relationship setting. The specified relationship defines how the linked work item is related to the test case, e.g. specifying Parent means that the linked work item will be the parent of the test case work item.

{
  ...
  "synchronization": {
    ...
    "links": [
      {
        "tagPrefix": "story",
        "relationship": "Parent"
      }
    ],
    ...
  },
  ...
}

The link type name is case sensitive and might contain spaces.

For linking Pull Requests, the relationship setting is mandatory and has to be set to Pull Request.

Restrict linked work item to be of a specific type

By default SpecSync will not verify the type of the linked work item: any type of work items can be used. You can enforce that a certain tag prefix can only be used for a specific work item type using the targetType setting.

When the "pull" command is used, SpecSync attempts to use the best tag prefix if there are multiple available by selecting the first with matching targetType or the first of the ones without targetType otherwise.

The following example allows using the @bug: prefix only for "Bug" work items.

{
  ...
  "synchronization": {
    ...
    "links": [
      {
        "tagPrefix": "bug",
        "targetType": "Bug"
      }
    ],
    ...
  },
  ...
}

Linking Pull Requests

Test Cases can also be linked to Pull Requests using tags. For that the relationship setting of the link specification must be set to Pull Request.

Linking GitHub Pull Requests

Linking Hyperlinks

Test Cases can also be linked to arbitrary URLs (hyperlinks). For that you need to specify the relationship as Hyperlink. You can include the full URL in the tag (e.g. @url:https://www.specsolutions.eu/specsync/) or you can specify a link template in the configuration (e.g. "linkTemplate": "https://docs.specsolutions.eu/specsync/{id}") and use the tag only for the relevant part of the link (e.g. @doc:features/plugin-list)

Limitations

  • In SpecSync v3.3 or earlier: Link tags are not created when the Test Case changes retrieved with the pull command.

  • In SpecSync v3.2 or earlier: Existing test case links are not removed automatically, even if you remove the tag from the scenario. They have to be removed manually.

SpecSync attempts to create and maintain work item tags during . In order to choose the right tag for new Test Case link, it considers the specified target work item type (targetType setting). Therefore if you plan to use the pull command it is recommended to set the target type. See section for details.

Changing the link type will not trigger the re-synchronization of the scenario. If the scenario has been synchronized already, you have to to force synchronization using the .

Test Cases can also be linked to GitHub Pull Requests using tags. For further details on that please check the .

configuration file
synchronization/links section
--force command line option
pull command
Restrict linked work item to be of a specific type
How to link GitHub pull requests guide