Test Case Import Format for TestRail and Zephyr
You wrote two hundred test cases. The import fails, or worse, it succeeds and produces two hundred rows with the steps in the wrong column. This is a formatting problem with a small number of causes.
What shape survives the import?
Every one of these trackers accepts a flat table. Flat means: one header row, one case per row, no merged cells, no blank spacer rows, no notes floating above the header.
A minimum set of columns that maps onto all four:
| Column | Purpose |
|---|---|
| ID | Your reference, stable across re-imports |
| Title | One line, states the behaviour under test |
| Preconditions | State the system must be in before step 1 |
| Steps | Numbered actions, one cell |
| Expected Result | What the tester verifies |
| Priority | Maps to the tracker's own scale |
| Section or Suite | Where the case lands in the tree |
The section column is the one people forget. Without it, every case imports into a single flat list, and reorganising two hundred cases by hand afterwards takes longer than the import saved.
Free and open sourceCasely writes these cases for youAttach a spec and one file of your team's existing test cases in Claude. Casely copies your columns, names the gaps it found in the spec, and exports a single Excel file your tracker imports in one pass.Read the install docsWhat five things break an import?
Merged cells. A merged cell spanning three rows produces one value and two empty ones. Parsers read the blanks as missing data and either reject the file or create cases with empty titles. Unmerge everything before exporting.
Steps split across rows. Two conventions exist. Some teams write one row per case with all steps in a single cell, separated by line breaks. Others write one row per step, repeating the case ID. Both work, and the trackers handle both, but the importer needs to know which one it is looking at. Mixing the two in one file guarantees a mess.
Line breaks inside cells, saved as CSV. A step list with real newlines survives XLSX. Exported to CSV it depends on quoting, and one badly quoted cell shifts every following column. If your steps contain newlines, export XLSX.
Expected results attached to the case instead of the step. Step-based templates in these tools pair each step with its own expected result. If your file has one expected result for the whole case and the target project uses a step template, the mapping has nowhere to put it. Decide which template the project uses before you write the cases, not after.
Unstable IDs. Re-importing a corrected file with regenerated IDs creates duplicates instead of updating the originals. Assign IDs once, from a scheme that will not shift when you insert a case in the middle. Sequential numbers per module beat global sequential numbers for this reason.
What should you do before you import two hundred cases?
Import three.
Take the first three rows, save them as their own file, and run the import into a throwaway section. You will learn which of your columns the tool did not recognise, whether the steps landed as steps, and whether the priority scale mapped. Fixing the mapping on three rows takes two minutes. Fixing it after two hundred rows landed wrong means deleting and starting over, and in some setups the deleted IDs stay burned.
The differences worth knowing
The four tools converge more than their documentation suggests, and the differences that bite are these.
Section hierarchy is expressed differently. Some importers take a path in one column, others expect you to have created the tree first and match on name. Check which one your target uses before assuming your nesting will survive.
Custom fields do not import unless they exist in the project already. Create them first, with matching names, or those columns get dropped without an error message.
Priority and type values are enumerations. Your spreadsheet saying High needs to match a value the project defines. A mismatch either fails the row or silently assigns the default, which is the worse outcome because nobody notices for a month.
Keeping the format after the first import
The format that imported cleanly is the format worth reusing. Save that file as the template. When someone writes new cases, they start from it rather than from a blank sheet, and the next import behaves the same way.
This is the reason Casely asks for a sample of your existing cases before it writes anything. Copying the columns, their order, the tone, and the ID scheme from a file that already imported into your tracker removes the whole class of problems above. The export lands as a single all_test_cases.xlsx holding every case under your own headers, which your tracker imports in one pass.