If you're migrating test cases from spreadsheets or from a test management tool that isn't directly supported by Qase's built-in import feature, you can use the Qase.io file import option.
It supports three formats: XML, JSON, and CSV. Of these, CSV is the easiest to work with, especially if your data already lives in Excel or Google Sheets.
How can this guide help?
Getting your test case data into the exact CSV format that Qase expects can be tricky. Small mistakes like a renamed column, a missing header, or an incorrect value, can cause your entire import to fail.
This guide breaks down everything you need to know before you start your migration. Each section covers a specific concept with practical examples, so you can follow along and build confidence before importing your real data.
Before You Begin: CSV Accuracy Matters
When you import a CSV, Qase doesn't process it the way a human would, scanning for context and making reasonable guesses. It reads your file programmatically, row by row, matching each value against a strict internal structure.
Here's what that means in practice, a few examples:
Headers must be exact. The importer uses the first row to determine what each column represents. If a header is renamed, missing, or reordered, the importer won't guess what you meant, it will reject the file or misplace your data.
Values must match what Qase expects. Many fields require values in a specific format. If a value doesn't match, it's silently skipped and a default is applied instead, you won't get a warning.
Error messages are minimal. If something goes wrong, the importer returns a generic error without telling you which row or column caused the problem. Debugging after the fact is difficult, which is why getting it right before you upload matters.
Each section of this guide focuses on one part of the CSV structure, so by the time you're ready to import, your file will match exactly what Qase expects.
Section | Key concept |
See how the format works by importing a minimal test case | |
Understand how the case's | |
Learn why suites should be defined before test cases. | |
Understand how nested suites work. | |
Learn how to look-up and create new | |
Understand how steps should be formatted, and see if your data requires usage of the | |
Learn how to differentiate | |
Create custom fields and use them to import additional test data. | |
Understand some miscellaneous fields, and how to work with them. |