Answer: Xray test data is stored as Jira issues (Test, Pre-Condition, Test Set, Test Execution, and Test Plan issue types) so it is captured by Jira backups in principle. In practice, the relationships between these issues, the custom fields that link tests to requirements, the test execution results, and any Xray-specific configuration are frequently broken or incomplete after a generic Jira restore. For regulated industries that require traceable test evidence, this is a compliance problem, not just an inconvenience.
Xray is the most widely adopted test management tool in the Atlassian ecosystem. According to its publisher, Xray is used by more than 10,000 companies in 135 countries, managing more than 100 million test cases each month. For these organizations, Xray data is not auxiliary. It is the system of record for whether software is fit for release. When a Jira restore is required, the question of what happens to that test data has direct consequences for release sign-off, audit readiness, and regulatory compliance.
How Xray stores its data
Xray is a native Jira application. It introduces new issue types (Test, Pre-Condition, Test Set, Test Execution, Test Plan) that are stored using Jira’s standard issue infrastructure. This is both Xray’s defining advantage and the source of restore complexity. Because tests are Jira issues, they appear in any Jira backup that captures issues. But the meaning of an Xray test depends on more than the issue itself:
- Custom fields hold test steps, expected results, datasets, and execution status.
- Issue links connect tests to the requirements they validate and the defects they discover.
- Test Execution issues store the results of test runs against specific versions and environments.
- Xray-specific configuration governs how test entities behave inside each project.
What typically survives a generic restore
If you restore Jira from a standard backup, the following usually return:
- The issues themselves, Test, Test Set, Test Execution issues all exist again.
- Native Jira fields and standard issue links between them.
- Comments, attachments, and history on each issue.
This sounds reassuring, and it can be enough for casual use. For regulated industries, it usually is not.
What typically breaks
The failure modes after a generic restore tend to cluster:
- Test step data in custom fields. If the custom field contexts that hold Xray’s test step information are not properly restored, the test issues appear empty. Atlassian documents this risk in their own custom field guidance.
- Test-to-requirement traceability. The links between tests and the requirements they cover (central to coverage reports and compliance evidence) frequently restore incompletely if Xray’s relationship metadata is treated as ancillary.
- Test execution history. Past test runs are evidence that a specific build passed a specific test suite at a specific time. Lose this and you lose your release sign-off audit trail.
- Pre-condition relationships. Tests that depend on shared pre-conditions can become orphaned, requiring manual re-linking.
- Xray app configuration. Settings that govern test workflow behavior, status mappings, and permissions are part of Xray’s own configuration and are not part of standard Jira exports.
Why this matters more than it seems
For three categories of organization, broken Xray restore is not an inconvenience, it is a regulatory event:
- Medical device and life sciences. FDA, ISO 13485, and IEC 62304 require traceable test evidence linking requirements to verified tests to results. A restore that breaks traceability is a quality system compromise.
- Financial services and payments. PCI DSS and internal audit demand evidence that controls were tested. Test execution history is part of that evidence.
- Aerospace and automotive software. DO-178C, ISO 26262, and similar require provable test coverage. Reconstructing this manually after a restore is impractical and audit-risky.
What QA leaders should require
If Xray is part of your release process, four requirements should be non-negotiable for your backup posture:
- Xray-aware backup. Backup tooling that explicitly understands Xray’s data model, not just generic Jira issue capture.
- Relationship preservation. Test-to-requirement, test-to-defect, and test-to-execution linkages must be captured and restored as first-class state.
- Configuration capture. Xray’s own settings, like workflow mappings, custom statuses, and project-level test configuration, must be part of every backup.
- Restore validation. After any restore, a documented checklist that confirms test coverage reports still render correctly, traceability links resolve, and execution history is intact.
The bigger pattern
Xray is one example of a broader truth: when SaaS data is restored, the question is rarely whether the rows came back. It is whether the relationships, configuration, and meaning that gave those rows business value came back with them. For QA organizations, the answer determines whether the next release ships on time and on evidence.
Sources
- Xray — Test Management for Jira (Atlassian Marketplace listing) — https://marketplace.atlassian.com/apps/1211769/xray-test-management-for-jira
- Xray — Native Test Management for Jira (architecture overview) — https://www.getxray.app/blog/test-management-tool-that-integrates-natively-with-jira
- Atlassian — Configure field contexts in your site — https://support.atlassian.com/jira-cloud-administration/docs/configure-custom-field-context/
Rewind">
