Exporting Test Cases From TestLink: What the XML Carries (and What It Doesn't)

Someone has the TestLink admin panel open, an export button in front of them, and a migration deadline the team agreed to two sprints ago. They click export, get an XML file, and assume the job is mostly done. It isn't. Exporting test cases from TestLink carries your case text and suite structure reasonably well, and it leaves behind a surprising amount: execution history, attachments, custom fields, and requirement links. This post gives you the export procedure itself, then the honest list of what survives it and what doesn't, so you decide what you're prepared to lose before you export, not after you've already switched.

The export procedure, step by step

TestLink's export lives in the Test Specification view, and it works at two levels: a single test suite, or an entire project.

For a single suite:

• Open the project and navigate to Test Specification
• Select the test suite you want to export in the tree on the left
• Use the export option in the suite's context menu or toolbar, typically labeled Export Test Suite Data
• Choose XML as the format
• Save the resulting file, and note which suite it came from, since the filename alone often won't tell you later

For a full project:

• Open Test Specification for the project
• Select the top level node of the suite tree, which represents the whole project
• Run the same export action from that top level node
• This produces one XML file covering every suite beneath it

Do this suite by suite if the project is large, rather than one enormous project level export. A smaller file is easier to inspect by hand before you trust it. It is also easier to re-run if something in the import step downstream doesn't parse cleanly the first time.

What the XML actually carries

The export is genuinely good at the core content. Open the file and you'll find:

• Case titles, exactly as written in TestLink
• The steps and expected results for each case, in order
• The suite hierarchy, meaning the folder structure your cases live in, preserved as nested XML nodes

If your TestLink instance is mostly used the way most teams use it, as a structured library of documented steps, this is the part that matters most, and it comes through cleanly.

What it does not carry

This is the list worth reading twice before you commit to a migration date:

• Execution history: every past run, pass, fail, and the tester who recorded it, is absent from the export
• Attachments: screenshots, log files, and documents attached to cases don't travel with the XML
• Custom fields: any field your team added beyond TestLink's defaults is dropped
• Requirement links: connections between a case and the requirement it verifies aren't in the export
• User assignment: who was responsible for which case or suite doesn't carry over either

None of this is a bug in TestLink's export feature. XML export was built to move case definitions, not the full operational history sitting around them. Knowing that in advance changes how you plan the migration, instead of discovering the gap after the old instance is already decommissioned.

The database route, and why it's a project, not an afternoon

Execution history does exist, just not in the XML export. It lives in TestLink's underlying database, and technically you can pull it out with a direct database query or a custom script against that schema.

Be honest with yourself about what that actually takes. It means understanding TestLink's database schema well enough to write correct queries. It means building some way to reshape that data into a format your destination tool accepts. And it means testing the result against real records before you trust it. For a team with a spare database engineer and a week to invest, that's realistic. For most QA teams, it's not a weekend project, it's a small engineering effort with its own risk of getting the mapping wrong.

Decide early whether that effort is worth it for your team, because it changes your whole timeline. Three years of execution history for a 900 case suite is a meaningfully different lift than exporting six months of records for a suite half that size.

Keeping the old instance read only, usually the better answer

For most teams, the honest answer to "how do we migrate our execution history" is: you don't, at least not into the new tool. Keep the old TestLink instance running in read only mode for whatever retention period your team needs, whether that's six months or two years, and let the new tool hold everything going forward.

This sidesteps the database extraction project entirely. Anyone who needs to check what happened on a release from eighteen months ago logs into the old instance and looks it up. New execution, new cases, and ongoing work live in the new system from day one. It's not a perfect answer, since it means keeping a second system alive for a while, but it's dramatically less risky than a bespoke history migration. It's usually the answer teams land on once they've weighed the alternative honestly.

Field mapping before import

TestLink and your destination tool won't use identical vocabulary for the same concepts, and sorting that out before import saves a round of cleanup after. A few common mismatches worth checking:

• TestLink's "test suite" concept may map to a folder, a section, or a similarly named grouping in the destination tool, and the nesting depth supported can differ
• Expected result fields sometimes split differently, where TestLink keeps step and expected result tightly paired and another tool separates them
• Priority and importance fields often use different scales, so a TestLink "High" doesn't automatically mean the same thing as a "High" on the other side

Walk through this mapping with a handful of real cases before you import the whole suite. A five minute check on ten cases catches a mismatched field far more cheaply than finding it after four hundred cases have imported wrong.

A pre-export checklist

Work through this in order before you click export for real:

• Confirm which suites you're exporting, and export suite by suite rather than one giant project file if the suite count is large
• List every custom field currently in use, and decide for each one whether it's worth manually recreating in the new tool
• Decide now whether execution history matters enough to justify a database extraction project, or whether a read only legacy instance is the better call
• Identify any cases with attachments, and plan to re-attach the important ones by hand, since they won't travel in the XML
• Check whether any cases are linked to requirements you still need to trace, and note those links somewhere before the export drops them
• Do a field mapping pass on ten representative cases before importing the full suite