In Qase, you can export test cases from your repository in different formats, including CSV, JSON, and XML. You can then re-import the same exported files back into Qase by choosing Qase.io as the source type.

Available export formats.

Selecting the Qase.io source type while importing.

Out of the three formats, CSV is especially useful for tasks like updating multiple test case details at once. The flexibility to work with a spreadsheet software makes CSV a preferred option for data manipulation due to its simplicity.

CSV, short for Comma Separated Values, is a widely used format for storing export data. It saves table-like data, such as from spreadsheets or databases, in plain text.

In a CSV file, each line represents a row, and each value in the line represents a column. Values are separated by commas (or sometimes other symbols like semicolons or tabs), which makes CSV files easy to read and import into different applications.

Importing from Excel, or your previous TMS

Originally, the Qase CSV format was designed for exporting and re-importing test cases within Qase, but it works really well for importing test cases if you’re currently managing them in Excel.

Each team has their own way of storing test cases in Excel in different formats, unfortunately, this means, it’s not possible for us to create a one-size-fits-all solution for all formats.

The Qase CSV has a well defined format for things like headers, accepted values for each column, and how to structure the data in each cell.

We’ve provided an example CSV to show you the headers, explain each column, and demonstrate the proper format. If you export test cases from a Qase repository to CSV, you’ll see the same structure.

Here's a Sample CSV – this will be used as a reference for all examples in this article.

Example (v2) 🔗
Example (v1) 🔗

Your current Excel format might be quite different from the Qase format, and yes, it will take some effort to adjust your data to fit Qase’s structure. But for now, this is the only method to import your test cases using the built-in importer from the UI.

The rest of this article will break down the format, explain it, and guide you through the process to make it easier. If you encounter any issues that aren’t covered, feel free to reach out to us via live chat or email at [email protected] to help improve this guide.

Old (deprecated) vs New format

Which format should I use?

Please, use the v1 format. It's simpler, and this section outlines when and if you need to use v2.

For most users, the V1 format (labeled "Qase.io CSV [deprecated]" in the import dialog) is the simpler option.

If your test cases have straightforward, single-line steps -- for example, "Click the Login button" or "Verify the dashboard loads", v1 works perfectly fine.

The steps columns are plain text, easy to read and edit in any spreadsheet application, and simple to prepare by hand.

When should I use V2?

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	`id`	`v2.id`
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

The Format

The following sections explain each aspect of the CSV in detail to ensure a successful import.

do NOT modify the Headers.

The importer when it reads the CSV you upload, expects the headers to be in a specific sequence and each header to match a specific string, so it's important that we do not modify or delete any header.

Click here to view all the headers in the latest v2 format of the file. Here are the default and accepted values for each header.

Use default or slug values for all fields.

Headers	Can be Empty?	Accepted values
id or v2.id	Yes	This field only accepts numbers. Example 🔗
title	No	The only mandatory field needing to be filled out.
description	Yes	This field accepts text.
preconditions	Yes	This field accepts text.
postconditions	Yes	This field accepts text.
tags	Yes	Each tag is separated by a comma. If a tag doesn't exist in your workspace, it will be auto-created upon import. Example 🔗
priority	Yes	If set to `undefined` or left empty, it will appear as `not set`. Example 🔗 Default values: `undefined`, `high`, `medium`, `low`
severity	Yes	If set to `undefined` or left empty, it will appear as `not set`. Default values: `undefined`, `blocker`, `critical`, `major`, `normal`, `minor`, `trivial`
type	Yes	If left empty, it will appear as `Other`. Example 🔗 Default values: `other`, `functional`, `smoke`, `regression`, `security`, `usability`, `performance`, `acceptance`, `compatibility`, `integration`, `exploratory`.
behavior	Yes	If set to `undefined` or left empty, it will appear as `not set`. Default values: `undefined`, `positive`, `negative`, `destructive`
automation	Yes	If left empty, it will set to `manual`. Possible values: `is-not-automated`, `to-be-automated` and `automated`
status	Yes	If left empty, it will set to `Draft`. Possible values: `draft`, `actual` and `deprecated`
is_flaky	Yes	If left empty, it will set to `No`. Possible values: `no`, `yes`
layer	Yes	If left empty, it will set to `Not set`. Possible values: `unknown`, `e2e`, `api`, `unit`
steps_type	Yes	Accepted values: `classic` and `gherkin`
steps_actions	Yes	If this field is empty, `steps_result` and `steps_data` should not be filled.
steps_result	Yes	-
steps_data	Yes	-
milestone_id	Yes	If the `milestone` field is empty, you can still give an `id` of an existing milestone here.
milestone	Yes	If the `milestone_id` field is empty, but this field is filled, A new milestone is created. If the `milestone_id` contains a valid `id` of an existing milestone, this field's value is not considered.
suite_id	Yes	This field can be empty for `test case without any suite`
suite_parent_id	Yes	This field can be empty for `test case without any suite`
suite	Yes	This field can be empty for `test case without any suite`
suite_without_cases	Yes	This field should be empty for all cases. Accepted value: `1` - suite are denoted by a `1` in this column
parameters	Yes	If there are no parameters, this field can be empty
is_muted	Yes	If the field is empty, the case will have a the "Muted case" property `unchecked`. For the case to be muted, the field value should be `yes`.
cf_1	Yes	Leave the custom fields empty, to not add any value.

Arrange and nest Suites.

The first row will always be the header. Starting from the second row, we can start defining our Suites. Only once all suites are defined can we begin with the test cases.

When defining suites, we will be working with just 4 columns and they are:

`suite_id`	starts from 1, and keep incrementing for each additional suite
`suite_parent_id`	provide the parent suite's id to nest the suite under it
`suite`	provide the suite name
`suite_without_cases`	`1` to denote that this is a suite and not a test case

Only once all suites are defined can we start with test cases and to nest a test case under a particular suite, simply copy and paste the values of three columns

suite_id

suite_parent_id

suite

Leave the suite_without_cases field empty for test cases to denote it's a case, not a suite.

Test case Steps

Steps are formatted differently in the CSV v2. Each step content is now enclosed in double-quotes (").

Here's a comparison of both formats.

Here's what you need to know when working with test steps:

steps_actions is a mandatory field:
If there's no data under step_actions, there cannot be any data in the other two fields (steps_result and step_data).
All steps should be inside a single cell, in the sheet.
Each step of the case, should be numbered appropriately, and in sequence. (1, 2, 3 ... n).
Do not break the sequence for steps_actions data. For instance, it should not be like so - (1, 2, 5, 6), instead - use (1,2,3,4).
It is okay to not have a step result or data for a certain step_action. In this case, we can simply skip that step number. Eg: If 4th step doesn't have any expected result, or data, it's okay to skip this number in the sequence.
Please, enclose each step's contents in double-quotes ( " ).

Custom fields

You can also import data for custom fields from a CSV file. To do this, you’ll first need to find the IDs of the custom fields you want to update in the CSV.

How to find the custom field Ids?

You can retrieve custom field IDs using our API endpoint detailed in this documentation - https://developers.qase.io/reference/get-custom-fields

Updating the CSV:

Once you’ve identified the correct IDs, add additional headers in your CSV after all existing ones and insert the values for those fields in the appropriate columns.

Working with the Qase CSV format