If you’re using an export from your original tool, the way test steps are structured may not match how Qase expects them. This is common, as different tools store and export steps in different formats.
To avoid issues like broken steps, missing formatting, or incorrect values, it’s important to understand how Qase expects this data to be organized. This guide will walk you through what to check and how to prepare your test cases before importing, including which import format to use.
Test steps format
If you’ve exported data from your existing tool, or even generally if your test cases are stored in Excel, the steps may be structured differently.
For example, they could be split across multiple rows, or the step action, data, and expected result might be stored in the same column. In such cases, this structure will need to be adjusted before importing into Qase.
In Qase, all steps for a single test case must be consolidated into a single steps_actions field. Additionally, step data and expected results should also be grouped accordingly for each step, maintaining the correct sequence.
The columns we'll be working with are -
steps_actionscolumn: to define the steps,steps_resultscolumn: to capture the expected result for each step,steps_datacolumn: to include any additional data required to perform that step.
Here’s how it should look:
This approach works well when your steps are simple and do not contain special characters, line breaks, commas, or nested steps. However, if your steps include any of these, you’ll need to use a different format to ensure they are imported correctly.
Choosing the right import format
When preparing your CSV file, one important decision is which format to use. Qase provides two formats, but in most cases, you can start with the V1 format.
If your test steps are straightforward, short, single-line instructions like “Click the Login button” or “Verify the dashboard loads,” V1 works well. It’s easy to read, simple to edit in a spreadsheet, and requires minimal preparation.
However, if your steps are more complex, for example, if a single step includes line breaks, longer descriptions, commas, or sub steps, V1 may not interpret them correctly. This can result in incomplete steps, missing data, or import errors.
In such cases, you should switch to the V2 format. It is designed to handle complex step content more reliably, preserving formatting, special characters, and step structure. It’s also the better choice if you’re exporting test cases and re-importing them.
As a rule of thumb: start with V1, and only switch formats if your test steps require more structure or detailed formatting.
When to use the V2 format?
Use the V2 format (labeled "Qase.io" in the import dialog) if any of the following apply:
Your test steps contain line breaks, commas, or other special characters. In V1, each step is written as a numbered line (e.g.,
1. Click the button), and the parser uses line breaks to tell steps apart. If a single step's text itself contains a line break, V1 can misinterpret where one step ends and the next begins. V2 wraps each step's content so that special characters are preserved exactly as written.Your test cases use nested (hierarchical) steps. V2 supports sub-steps via tab indentation in the step columns. V1 does not reliably parse step hierarchy on import.
You are doing a round-trip export and re-import (exporting from one Qase project and importing into another). V2 is designed so that an exported file can be re-imported without any data loss in the steps columns. V1 may lose or mangle step content that contains special characters during this round-trip.
What exactly is different between the two?
| V1 (old format) | V2 (current format) |
First column header |
|
|
Import source label | Qase.io CSV [deprecated] | Qase.io |
Export source label | CSV (old format, deprecated) | CSV |
Steps columns | Plain numbered text, one step per line | Each step's content is specially encoded to preserve special characters |
Nested steps | Not supported on import | Supported via tab indentation |
Best for | Simple test cases with single-line steps; easy hand-editing in a spreadsheet | Complex steps, round-trip export/import, or steps with rich text content |
