Xray Test Case Export: What Comes Out, What Gets Left Behind

A QA lead at a mid sized SaaS company spends a Friday afternoon on an Xray test case export before a tool switch closes out in next week's sprint planning. The export finishes in under a minute. The CSV opens clean, rows and columns, exactly what was promised. Then someone asks where the screenshots went, and where the last 40 execution runs against release 6.2 ended up. The room goes quiet.

This is the moment most migrations actually start, not the moment the export button gets clicked. A rushed Xray test case export can look complete and still be missing the parts a team relies on every release. This post walks through what an Xray export genuinely contains, what quietly gets left behind, and how to plan around the gaps before they show up mid migration.

What the standard Xray CSV export actually includes

A default Xray test case export through Jira's CSV export gives you the fields that live directly on the Jira issue. That means the summary, key, test type, priority, labels, and any custom fields exposed in the export configuration.

For manual tests this usually includes the test steps, expected results, and preconditions. Xray stores those as structured fields on the issue itself.

That part works reasonably well in practice. A 600 test case regression suite will export its titles, step text, and Jira metadata without much drama. The catch is that a test case in Xray is rarely just its steps. It carries a history and a set of relationships that a flat CSV was never built to represent.

The three things teams find missing after the export finishes

Most teams don't notice the gaps until they try to rebuild the suite in a new tool and something doesn't line up. The recurring misses are:

• Execution history. Past test runs, who ran them, when, and with what result, live in Xray's Test Execution and Test Run objects, not on the test case issue. A standard CSV export skips these entirely.
• Attachments. Screenshots attached to a failed step, log files pulled in during a bug investigation, and evidence files linked to a run do not travel with a CSV row. They stay in Jira's attachment storage, tied to the original issue.
• Field mappings and structure. Test sets, test plans, folder hierarchy in the Test Repository, and links between a test and the requirement it verifies are relationships, not flat fields. CSV cannot express a tree or a many to many link on its own.

None of this is a bug in Xray's export feature. A CSV is a table. Runs, attachments, and hierarchy are not tabular data, so they need a different export path or a different tool entirely.

Why the CSV looks complete when it isn't

The CSV passes a quick glance because the fields people check first, summary and steps, are exactly the fields that do export cleanly. A reviewer scrolling through 200 rows sees titles and step text that match what's in Jira, and reasonably assumes the rest came along too.

The gap only becomes visible once someone tries to answer a question the CSV was never built to hold. Something like "when did we last run this against the 900 test regression suite" or "where's the screenshot from the Safari only checkout bug that reached a customer."

Building an Xray test case export plan that actually holds up

Treat the export as three separate jobs rather than one click.

• Test case content. The CSV or Xray's REST API covers this well. Confirm every custom field you rely on is included in the export configuration before running it, not after.
• Execution history. Decide up front how much history actually matters. Many teams only need the last two or three release cycles of run results, not five years of every execution. Pulling this through Xray's API against Test Execution issues is more reliable than any CSV route.
• Attachments and evidence. Attachments need to be pulled per issue, usually through the Jira REST API, and re-linked in the destination tool. Skipping this step is the single most common complaint teams raise after a migration, because the evidence trail behind a defect disappears.

Running these three as separate checklist items, with someone accountable for each, catches the gap while there's still time to fix it.

Running them as one afterthought is how a team ends up rebuilding 150 test cases by hand two weeks after the "migration is done" email went out.

What this means if you're moving to Tesbo

Tesbo is a test case management tool, so a migration into it is fundamentally about test case content: titles, steps, expected results, and organization into suites. It does not execute tests or hold your Xray run history for you.

Any execution history you want preserved needs to be pulled and archived separately before the cutover, using the plan above. Getting the test case content itself into a clean, organized structure is the part Tesbo is built to make straightforward once the export is in hand.

A short pre export checklist

Before anyone clicks export, walk through this list as a team:

• Confirm which custom fields must be in the CSV export configuration
• Decide how many release cycles of execution history actually need to be preserved
• Identify every test case with attachments and plan how they'll be pulled and re-linked
• Map folder structure and test sets to whatever hierarchy the destination tool supports
• Assign one owner per data type, not one owner for the whole migration

Working through this list takes an afternoon. Skipping it costs a lot more than an afternoon once the gaps surface in front of a release manager.