Uploaded image for project: 'Xray for Jira Cloud'
  1. Xray for Jira Cloud
  2. XRAYCLOUD-10988

Xray Cloud should support interoperability of Requirements, Tests, and Test Execution artifacts across multiple Jira Cloud instances.

    XporterXMLWordPrintable

Details

    • Suggestion
    • Status: New
    • Resolution: Unresolved
    • None
    • None
    • None
    • None
    • UNCOVERED

    Description

      Description

      While Xray provides powerful traceability and reporting capabilities within a single Jira instance, it currently lacks native support for establishing and maintaining relationships between artifacts that reside in different Jira Cloud instances.

      Xray should provide a mechanism to establish, maintain, and report on relationships between artifacts located in different Jira Cloud instances while preserving ownership and governance boundaries.

      Examples include, but are not limited to:

      • Requirements in one instance and Tests and Executions in another such as to cover  Traceability and coverage reporting spanning multiple Jira Cloud instances.
      • Tests in one instance and Test Executions in another.

      The goal is to enable enterprise-scale test management without requiring data duplication, migration, or custom integrations.

      User friction
      Organizations operating multiple Jira Cloud instances face challenges such as:

      • Inability to create native traceability between related artifacts located in different instances.
      • Fragmented visibility of testing progress and coverage.
      • Reliance on manual processes to correlate information across instances.
      • Duplication of requirements, tests, or execution artifacts.
      • Loss of end-to-end reporting and auditability.
      • Increased dependency on custom integrations and synchronization solutions.

      Steps to reproduce (right now) / Actual Result:

      1. Create an artifact in Jira Cloud Instance A (Requirement, Test, Test Plan, etc.).
      2. Create a related artifact in Jira Cloud Instance B.
      3. Attempt to establish native Xray traceability between the two artifacts.
      4. Attempt to view coverage, execution status, traceability, or reporting across instances.

      Actual Result:

      Xray relationships and reporting are limited to artifacts residing within a single Jira instance.

      Organizations cannot natively create or consume cross-instance traceability and must rely on custom solutions, duplicated data, or external reporting mechanisms.

      IMPACT

      What would improve if solved: 

      • Enterprise-wide traceability across Jira instances.
      • Federated test management capabilities.
      • Reduced artifact duplication.
      • Improved reporting and visibility.
      • Better audit readiness and compliance support.
      • Simplified management of distributed teams and platforms.
      • Reduced dependence on custom integrations.

      Impact on stakeholders:

      Quality Engineering Teams

      • Ability to manage tests and executions regardless of where related artifacts reside.
      • Improved coverage and execution visibility.

      Product and Business Teams

      • Visibility into quality status without requiring all work to exist in a single Jira instance.

      Program and Portfolio Managers

      • Consolidated reporting across organizational and platform boundaries.

      Compliance and Audit Teams

      • Easier verification of end-to-end traceability and testing evidence.

      Jira and Xray Administrators

      • Reduced operational overhead from maintaining custom synchronization mechanisms.

      Current workaround:
      Organizations typically rely on one or more of the following:

      • Manual tracking of relationships.
      • Custom API integrations and for Data replication

      CONTEXT & EXAMPLES:
      Many enterprises intentionally distribute work across multiple Jira Cloud instances due to:

      • Organizational boundaries.
      • Security and access control requirements.
      • Regulatory or compliance constraints.
      • Customer-specific environments.
      • Mergers, acquisitions, and platform consolidation efforts.
      • Separate ownership of requirements, testing, and delivery functions.

      These organizations require a federated operating model rather than a centralized one.

      Concrete example:

      Example 1

      • Requirement in Instance A
      • Test in Instance B

      Desired outcome:

      • Native traceability between the requirement and the test.
      • Cross-instance coverage reporting.

      Example 2

      • Test in Instance A
      • Test Execution in Instance B

      Desired outcome:

      • Execution results contribute to the test's overall status and reporting.
      • Users can navigate and report across both instances.

      Workaround risk:
      Current workarounds introduce risks including:

      • Broken traceability.
      • Data inconsistencies.
      • Synchronization failures.
      • Duplicate artifacts.

      Attachments

        Issue Links

          Activity

            People

              bernardo.cottim Bernardo Cottim
              jayanthi.murthi Jayanthi Murthi
              Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated: