SpecSync Documentation
Jira
Jira
  • Introduction to SpecSync for Jira
  • 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
      • 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: Automatically link changed Test Cases
      • Customization: Synchronize linked artifact titles
      • 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
      • Excluding scenarios from synchronization
      • Synchronization conflict resolution
    • Test result publishing features
      • Publishing test result files
    • General features
      • Jira authentication options
      • Configuration file
      • Hierarchical configuration files
      • Local test case conditions
      • Configuration wizards
      • SpecSync plugins
    • Customizations
    • Plugin list
  • Licensing
  • Guides
    • What is my Jira server URL?
    • Jira Test Case Management (TCM) solution
    • How to define the local feature-set to be synchronized
    • Filters and scopes
    • How to use SpecSync from build or release pipeline
    • How to upgrade to a newer version of SpecSync
    • How to attach files to test results
    • 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
    • Migrating from SpecSync v1 to v5
  • Changelog
  • Release Model and Roadmap
  • Downloads
  • Reference
    • Command line reference
      • init
      • upgrade
      • push
      • pull
      • publish-test-results
      • version
    • Configuration reference
      • toolSettings
      • local
      • remote
      • jira
      • knownRemotes
      • synchronization
        • push
        • pull
        • links
        • attachments
        • format
        • fieldUpdates
      • hierarchies
      • publishTestResults
      • specFlow
      • customizations
    • Compatibility
    • Older versions
  • Contact
    • SpecSync Support
    • Troubleshooting
    • FAQ
  • Project Website
Powered by GitBook
On this page
  • How to choose remote scope type
  • Processing removed local test cases
  • Tagging removed Test Cases
  • Excluding removed Test Case from hierarchies
  • Detection of removed test cases with filtered synchronization
  • Undo removal

Was this helpful?

  1. Features
  2. Common synchronization features

Remote scope

PreviousConfiguration keyNextLinking Work Items using tags

Last updated 1 day ago

Was this helpful?

A remote scope is a configuration setting in SpecSync that defines the set of Jira Test Cases that are to be considered for synchronization from a particular SpecSync configuration.

The primary purpose of the remote scope is to detect if a local test case has been removed, for example when a scenario has been deleted from a feature file (see details ). The remote scope is also used for to create new local test cases based on Jira Test Cases.

Configuring a remote scope is optional, but recommended. If no remote scope is configured SpecSync will not be able to detect removed local test cases and the related option for the pull command will not be available.

The remote scope is configured using the remote/scope configuration section. When configuring the remote scope, you can choose from different options on how the remote scope should be maintained by SpecSync. When changing the remote scope configuration, you need to perform a full (unfiltered) push synchronization so that the remote scope is established.

This feature has been significantly improved in SpecSync v5 and the configuration has been changed. In earlier versions only testSuite remote scope type was available that was configured using the remote/testSuite configuration setting. For trying out the new extended behavior, please check the .

The following configuration file configures a tag remote scope.

specsync.json
{
  "$schema": "https://schemas.specsolutions.eu/specsync4azuredevops-config-v5-latest.json",
  "compatibilityVersion": "5",
  "configurationKey": "my-project-config",
  "remote": {
    "projectUrl": "[...]",
    "scope": {
      "type": "tag"
    }
  },
  ...
}

The following table contains an overview of the possible options. Please check the section for help to decide.

Type
Description

tag

How to choose remote scope type

For Jira currently only the tag remote scope type is available. We recommend to use that.

Processing removed local test cases

As mentioned above the the primary purpose of the remote scope is to detect if a local test case has been removed, for example when a scenario has been deleted from a feature file.

This detection is performed during push synchronization in a way that SpecSync loads the Test Case IDs that are in remote scope and matches them to the processed local test cases (e.g. scenarios) as the following example shows.

In this example, the Test Case #12 is in the remote scope, because SpecSync has included it earlier when the related scenario was synchronized. The scenario has been removed from the feature file, so SpecSync will not find a matching scenario for Test Case #12 therefore it is considered to be removed.

Tagging removed Test Cases

SpecSync never deletes Jira Test Cases to avoid data loss.

The Test Cases corresponding to the deleted local test are not deleted from Jira to avoid data loss, but they are tagged with specsync:removed. The tagged Test Cases can be deleted by the user in Jira if they are not required anymore.

Excluding removed Test Case from hierarchies

This means that whenever SpecSync detects a test case as removed, it will excluded it from any Test Case hierarchy it was previously included in.

Detection of removed test cases with filtered synchronization

Therefore by default SpecSync the removed test detection is disabled when a filtered synchronization is performed.

This behavior can be modified by setting the toolSettings/forceProcessingRemovalsOnFilter configuration option to true.

Undo removal

Thanks to the fact that SpecSync does not delete, but only tag the removed Test Cases, the removal is reversible.

The Jira Test Cases in the remote scope are marked with the tag specsync:<config-key> (this is a remote-only tag, it will not be synchronized to a local tag during pull). The advantage of this remote scope type that it is easy to know from a Test Case that it was synchronized from a particular SpecSync configuration and you can also use the tag for querying Test Cases in Jira. In order to use the pull command for crating new local tests from Jira Test Cases, the new Test Cases can be added manually to the remote scope by adding the tag to the Test Case. The disadvantage is that the additional Jira tag might be disturbing. In order to use this remote scope type you need to specify a .

If the SpecSync configuration has a specified, the removed Test Cases will be tagged with a specsync:removed-from:<config-key> tag in addition to specsync:removed. This can help identifying which configuration was used to synchronize this Test Case earlier.

SpecSync can synchronize Test Cases into hierarchical structures using the feature. These structures are also maintained with removed test cases if remote scopes are used.

The push synchronization can be limited to a smaller set of test cases using the . This is usually used to quickly synchronize the set of the test cases the user is currently working on and not to check if test cases have been removed from the entire configuration.

If the removed local test case (scenario) is restored and a push synchronization is performed, SpecSync will detect that there is already a Test Case corresponding to the restored local test case and it simply removes the added specsync:removed and specsync:removed-from:<config-key> tags. The restored Test Case will be included again to the remote scope and to any it has been removed from. With that the original state is restored.

configuration key
Test Case hierarchies
--filter command line option
Test Case hierarchies
configuration key
below
How to choose remote scope type
pull command
preview version of v5
Remote scope is used to detect removed scenario