Import test cases

The import wizard lets you bring test cases from another tool — or re-import a Probara export — into a project without recreating them by hand. It opens as a compact dialog in place — no navigation away from the repository. Import reads an export file and writes it directly to the project — there is no preview step and no confirmation gate. In a project that requires review, the import opens review requests instead of writing cases (see When the project requires review). You get a confirmation once it’s done, or a list of any rows that could not be imported. Integrators who want to automate imports can use the test case import API instead.

Reaching the wizard

Open a project and go to the Repository page.
Click the header menu (⋯) and select Import.
The import dialog opens on top of the repository page.

The Import action is visible to members, admins, and owners. Viewers do not see it — import always requires member-level access or above.

Supported source formats

Source tool	Formats
Probara	JSON, XML, CSV, XLSX
Qase	XML, JSON, CSV, XLSX
TestRail	XML, CSV
Gherkin (.feature)	`.feature`

Probara’s JSON, XML, CSV, and XLSX files, and .feature files, carry a case’s parameters and excluded combinations. See Parameterized test cases.

You choose the source tool from a select field — Probara (preselected by default), Qase, TestRail, or Gherkin (.feature). Re-importing a file that Probara itself exported is the zero-configuration path: any of the four export formats round-trips back in. You never choose a file format directly: once you pick the source tool, the dialog automatically figures out the exact format from the file you upload (by its extension, or by inspecting the file’s content if the extension is missing). Export your test cases from the source tool first, then upload that export file here. If the file’s format is not one the chosen source tool supports — for example, uploading a JSON file after choosing TestRail, which only accepts XML or CSV — the dialog tells you so immediately, before uploading anything. A Gherkin file is recognized by its .feature extension only, so keep that extension when you save it. A .feature file that lives in a repository is better kept in sync than imported again and again: see Syncing feature files from Git.

.md files are not importable — Markdown is no longer an export format. The dialog rejects a .md upload immediately; export in one of the supported formats instead.

Building a file by hand instead of exporting it? The CSV import walkthrough documents every column Probara reads, the separators it expects, and the mistakes that fail a whole file — with a downloadable example CSV you can adapt.

The import dialog

The dialog is a single form. There is no separate upload/mapping/destination sequence to click through, and there is no preview or confirmation step — clicking Import test cases commits the file directly.

The form

The form has everything you need in one screen:

Source type — a select listing each source tool once: Probara (preselected by default), Qase, TestRail, and Gherkin (.feature). The dialog shows the formats each one supports (Probara: JSON, XML, CSV, XLSX; Qase: XML, JSON, CSV, XLSX; TestRail: XML, CSV; Gherkin: .feature) as a hint under the field, but you never pick a format yourself.
Parent suite — a select defaulting to Project root; imported suites and cases are placed beneath whichever suite you choose here. The source file’s own suite hierarchy (if any) is recreated underneath it.
Upload file — choose the exported file from the source tool you selected. The dialog resolves its exact format for you.
Field-mapping note — informational text describing which fields the import can populate, which depends on the source tool. Qase and TestRail exports map three system fields: Priority, Type, and Status. Probara re-imports map every system field — priority, severity, status, type, layer, behavior, flaky, preconditions, and postconditions — plus any user-defined custom field that already exists in the organization. Values in your file are matched to existing fields and options automatically, by name (case-insensitive) — there is no manual mapping control to configure, and import never creates a new field or option. A field that does not exist in the organization is skipped with a notice; an option value that does not match any existing option — for example, a priority named "Urgent" when the project only has "High"/"Medium"/"Low" — falls back to the field’s default option when one is configured, and is otherwise left unset. The case still imports; nothing fails because of an unmapped value. A Gherkin .feature import maps no system fields: tags become tags, and steps stay Gherkin steps. The test case import API reference documents the exact mapping and warning contract.
Replace matching test cases — a checkbox, off by default. See Replace matching below for the exact rule.

On a narrow (phone-width) screen, Source type and Parent suite lay out in a single column instead of side by side — the same two fields, in the same order, just stacked.

The primary Import test cases button stays disabled until a source type and a valid file are provided. If the file is larger than the import size limit, the dialog shows an error immediately and does not attempt to upload it. See Size limit below.

Clicking Import test cases stages the file and commits it directly — there is no intervening preview or confirm step.

What happens after you click Import test cases

Full success (every row imported). The dialog closes, a success toast confirms how many cases were imported, and the repository tree refreshes to show the new suites and cases.
Partial success (some rows failed). The dialog stays open, showing the list of failed rows — each with its row number, title, and the reason it failed. The rows that did import are already in the project; you can close the dialog once you’ve reviewed the list.

On a narrow (phone-width) screen the failed-rows list (and the warnings list, when there are unmapped values) becomes a card list: each row presents as its own card, showing the same row number, title, and reason. At tablet width and above the list is the table described above.

Replace matching

The Replace matching test cases checkbox (off by default) controls what happens when a case in your source file has the exact same title as a case that already exists in the target suite:

Off: every source case is created as a new case, even if the title matches an existing one. This can produce duplicate titles.
On: a source case whose title exactly matches one existing case in the target suite overwrites that case’s content (steps, tags, description, and the mapped fields) instead of creating a duplicate. The existing case’s ID and creation history are preserved — only its content changes.

If a title matches more than one existing case in the target suite, that row is reported as a failure (ambiguous_match) rather than guessing which case to replace.

If your source file itself contains two rows with the same title, only the first one (in file order) is eligible to replace an existing case; the later duplicate is always created as a new case.

A replaced case also takes the parameters of its row. A Probara or .feature row without parameters clears the case’s parameters. A Qase or TestRail row keeps them, because those imports do not read parameters yet. A row whose parameters break a rule imports without them, shows a notice, and keeps the case’s existing parameters.

A case synced from Git is never replaced. When a row matches one, the row is skipped with a warning that the case is synced from Git, and the case keeps what its file says. Change the scenario in the file instead: see Syncing feature files from Git.

When the project requires review

In a project where test case review is mandatory, an import writes no test case:

The suites from the file are created as usual.
Each new case becomes a New case review request, and each case Replace matching test cases would overwrite becomes an Update request. You are the author, and the project’s default reviewers are assigned.
A case that already has an open review request is skipped and listed with the reason.
The success notification counts the review requests opened instead of imported cases. The cases reach the repository when their requests are merged, after the same checks as a case created in the app (for example, required custom fields must have a value).

Size limit

Import accepts files up to 10 MB. A larger file is rejected before upload, with a message telling you to choose a smaller export.

There is also a maximum number of test cases per import run. If your export exceeds that limit, the file is rejected before any data is read — split the export into smaller batches and import them one at a time.

Limitations in this version

No attachments. Images or files embedded in test case steps (for example, screenshots pasted into an expected result) are not imported. A missing image after import is expected — re-attach it manually afterward if needed.
Shared steps arrive as ordinary steps. When a Qase or TestRail case uses a shared step, the import copies that shared step’s steps into the case, in place, as regular steps — it never creates a shared step in Probara. If the file only points at a shared step without including its text, there is nothing to copy: the case imports its other steps and the row shows a notice naming the skipped reference. Re-importing a Probara export works the same way, because exports already write shared steps out as plain steps.
Qase and TestRail map system fields only. Imports from Qase or TestRail populate Priority, Type, and Status. Probara re-imports map all system fields plus existing custom fields — but import never creates a new field or option; unknown fields are skipped with a notice.
Gherkin structure depends on the source. Qase JSON, XML, and XLSX keep Gherkin steps as Gherkin steps. Qase CSV has no Gherkin structure, so its steps import as classic steps. Probara’s JSON, XML, CSV, and XLSX exports keep each case’s format and each step’s keyword.
Steps that do not fit the stated format. A case whose steps do not fit its format is imported as classic steps, with each keyword kept at the start of its step, and its row shows the notice Imported as classic steps — the steps did not fit the stated step format. For example, a Gherkin step with no keyword, or one with an expected result, does not fit. Nothing is dropped.
Parameters from Qase and TestRail are not read yet. A Qase CSV parameters column is ignored, so the case imports without parameters.
No live connectors. Import always works from a file you export manually from the source tool. There is no direct integration that pulls cases live from Qase or TestRail.
No Markdown. .md files are not importable — Markdown is no longer an export format.

Troubleshooting

Message	What it means
File exceeds the import size limit	The file is larger than 10 MB — export a smaller subset or split the file.
This file contains too many test cases	The parsed file exceeds the per-import case limit — split the export into smaller batches.
The file could not be read as a `<format>` export	The file’s content does not match the source tool/format you selected — confirm you selected the correct source tool.
No test cases were found in this file	The file parsed successfully but contained zero cases — confirm you exported the right file.
Too many import requests	You have started too many imports too quickly — wait a moment and try again.
The uploaded file could not be found	The staged upload expired or was not found — upload the file again from the form state.
Parameters not applied — case imported without them	A row’s `parameters` or excluded combinations are not valid, or break a parameter rule. The case imports without them, and a replace import keeps its existing parameters. See Parameterized test cases.

Permissions

Action	Viewer	Member	Admin	Owner
See the Import entry point	No	Yes	Yes	Yes
Open the import wizard	No	Yes	Yes	Yes
Run an import	No	Yes	Yes	Yes