Test Case Properties

So far, we’ve seen that when most test case fields are left empty in the import sheet, Qase automatically fills them with default values.

But what if you want to migrate the original test case values instead of relying on defaults?

To understand this, it’s important to first look at the different types of test case fields. Some fields, like Description, Pre-conditions, and Post-conditions, allow free form input where you can write full text or paragraphs. Others, like Priority, Severity, and Status, are structured fields where you must choose from predefined options or enter a specific type of value (for example, a number).

While it’s straightforward for text fields, structured fields require more attention. For example, how do you know whether Priority accepts a number or a set of predefined values?

You can check this by navigating to Workspace → Fields, where you’ll find a list of all fields along with their types.

For free form fields (like Description), you can simply enter your content in the CSV and import it. However, for other fields, you need to provide the exact expected values. This applies specifically to dropdown type fields, which we’ll explore in more detail in this article.

When importing test cases, fields like Priority, Severity, and Status are not free form. Qase expects specific values called slugs. These must match the configured values in the system. Even small differences, like a mis-spelling, can cause the value to be ignored.

Slugs are standardized identifiers used for dropdown fields. They act as a consistent “code” that Qase can reliably understand, especially when importing data from a CSV. While slugs in Qase are case insensitive, their main purpose is to keep things consistent and predictable.

One key advantage is that slugs do not change even if the display name is updated in the UI. For example, a value shown as “High Priority” may have the slug high, and even if you rename it later, you can continue using the same slug high. This ensures that your imports continue to work even if names are updated.

Let’s look at this with an example.

Take the Severity field. Head over to your workspace → Fields → click Edit on the Severity field, and then open the Values section.

Here, you’ll see a list of values that are already set up by default. Along with each value, you’ll also see its slug, this is the exact value Qase expects in your CSV.

This example is shown for Severity, but the same concept applies to all other dropdown field types. Each of these fields has corresponding slugs, and this is how you can identify both the available values and their slugs.

Note: If you enter a value that is not defined, the system will apply the default value configured for that field after the file is uploaded.

Below is a reference of all major headers, including whether they can be left empty and the accepted slugs for each.

Based on this, you can populate the CSV sheet. If you need a reference, here’s how your file should look afterward: Test Case Attributes CSV

There are still a few more fields to cover; we’ll take a look at them in the later sections.