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

The version can be identified with the text from the A1 cell – the first column header. The latest version has the value: v2.id and the old one just has id.

There aren't many differences between the two versions. The only major difference in the latest version is test case steps (action, input_date, and expected_result) all have to be enclosed in double quotes.

Format	Export	Import
Current CSV Format	CSV	Qase.io
Deprecated CSV Format	CSV (old format, deprecated)	Qase.io CSV [deprecated]

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