CSV import walkthrough

Most test cases arrive in a spreadsheet, not in Probara’s own shape. This guide is about the one format you can build by hand: the Probara CSV — the same file Probara exports and reads back. It is also the format to reach for when you are migrating from a tool whose export Probara does not read, because a CSV you control is a CSV you can get right.

An import is not a fuzzy read. Probara reads your file row by row against a fixed structure, so one renamed column, one missing header, or one wrong separator can fail the whole file before a single case is created. Each section below covers one piece of that structure.

Download the example file

⬇ Download the example CSV — a real export of a small e-commerce repository: 21 cases across 4 top-level suites and 3 of their children, 52 steps, and every system field filled — priority, severity, status, type, layer, behavior, automation status, preconditions, postconditions and flaky — plus tags, suite paths and automation keys.

It is not a mock: a real export you can open next to your own spreadsheet and copy the shape from. The file is a plain UTF-8 CSV — open it in Google Sheets or Excel, or read it as text.

Prefer your own data? Export one of your projects from Probara and open that file here instead: the columns and the row layout are the same ones this guide documents.

The ten fixed columns

These ten columns are read by position, not by header text. Their order is part of the format: renaming one, reordering two, or leaving one out is not the same file. Keep the header row exactly as exported.

A file whose first header cell is not title is refused outright — no cases are created and the dialog reports that the file could not be read as a CSV export.

One case, several rows

Steps live in rows, not in cells. The first row of a case carries the case-level columns plus that case’s first step; every following row for the same case leaves the case-level columns empty and contributes one more step.

title,description,suite,priority,type,status,tags,step_action,step_data,step_expected
Add to the cart updates the badge and the line item,"The header badge and the cart line item are two views of the same fact.",Cart/Cart totals,Critical,Smoke,Active,cart;smoke,Add the product to the cart,Trail Runner GTX,The header badge shows 1 without a reload.
,,,,,,,Open the cart,—,One line item for SKU SHO-1001 appears.

Two rules decide where a case ends:

• A non-empty title starts a new case. Everything on that row — suite, fields, tags — belongs to the new case.
• An empty title continues the case above it, and only its step_action / step_data / step_expected cells are read. Anything else you leave in those columns is ignored, not an error.

A case with no steps at all is imported with a single empty step row, so a title-only row is a valid case.

Optional columns after the fixed ten

Five columns are optional. Probara recognizes each by its header, wherever it sits after step_expected. The first column with each header is used; a repeated header is read as an extra column.

Give a case a key when you want CI reports to find it, and leave it empty for the cases a human runs. Keys are unique within a project: two rows with the same key are a conflict, not a merge.

A Gherkin step has no expected result, so leave step_expected empty on its row. The keyword is matched without regard to case. This example is a Gherkin case with three steps:

title,description,suite,priority,type,status,tags,step_action,step_data,step_expected,step_format,step_keyword
Checkout requires a valid card,,Cart/Payment,High,Smoke,Active,payment,the user is on the payment step,,,gherkin,Given
,,,,,,,the user enters an expired card,,,,When
,,,,,,,the payment is refused,,,,Then

Parameters and excluded combinations

A case’s parameters go in the parameters column, and its excluded combinations go in excluded_combinations. Each is a JSON array written on the case’s first row. Each parameter is a single or a group:

• A single: {"kind":"single","name":"Site","values":["EU","US","APAC"]}.
• A group: {"kind":"group","name":"Network","columns":["VPN","Cookies"],"rows":[["on","yes"],["off","no"]]}.

An excluded combination lists a value for every parameter of the case. For a case with the single above, the exclusion of APAC is [[{"name":"Site","value":"APAC"}]]. An exclusion that matches no combination of the case is dropped on import, without a notice.

Quotes inside a cell are doubled in the file, and a spreadsheet quotes the cell for you. This example is a case with one parameter:

title,description,suite,priority,type,status,tags,step_action,step_data,step_expected,parameters
Sign in on ${Site},,Auth,High,Smoke,Active,login,Open the login page for ${Site},,,"[{""kind"":""single"",""name"":""Site"",""values"":[""EU"",""US"",""APAC""]}]"

Extra columns: system fields and your own

Every other column after the fixed ten and the optional columns above is an extra column, and extras carry fields. An export of a project that uses the full field set looks like this:

title,description,suite,priority,type,status,tags,step_action,step_data,step_expected,automation_key,step_format,step_keyword,severity,layer,behavior_test,automation_status,preconditions,postconditions,is_flaky,component,test_environment,requirement,automation_framework,estimated_minutes

The extra columns in that example, and where they come from:

Three rules decide what happens to a value, and none of them fail the import:

• Values are matched to your existing fields and options by name, ignoring case. High, high and HIGH all reach the High priority.
• Import never creates a field or an option. A column whose header matches no field in your organization is skipped with a notice; a value that matches no existing option leaves that field unset, or falls back to the option your field is configured to default to.
• The case still imports either way. An unmapped value is a warning in the dialog’s notice list, never a failed row. Fix it later on the case itself if it matters.

The header of an extra column is normalized the same way every time: lowercased, with every run of non-alphanumeric characters replaced by a single underscore. Test environment becomes test_environment, and it matches your field Test environment by name. The headers parameters and excluded_combinations are reserved for the parameter columns, so a custom field with either title keeps no value.

Building the file from a spreadsheet

Most people start in Google Sheets or Excel, and both are fine — the rules that matter are the ones a spreadsheet breaks quietly:

1. Keep the header row. Row 1 is the header; data starts on row 2.
2. Export as CSV (UTF-8), not as .xlsx. Probara reads .xlsx too, but CSV is the format you can inspect in a text editor when something goes wrong.
3. Never let the spreadsheet reformat your separators. Sheets written in a locale that uses ; as the list separator will happily write Catalog;Product detail — write suite paths with / and tag lists with ; yourself.
4. Watch for auto-conversion. A cell starting with =, +, - or @ becomes a formula, a phone number, or a date. Format those columns as text before you fill them in.
5. One case per row group, using the empty-title rule above. Do not merge cells, and do not put two cases on one row.
6. Save, then import. Save the file as CSV and upload that file; the import dialog resolves the format from the file itself.

Re-importing a Probara export

The round trip is the safest way to build the file: export your cases from Probara, edit the CSV until it holds what you want, then import it back. Nothing is lost on the way — every system field, every custom field value, the tags, the automation keys, the step formats, the Gherkin keywords, the parameters, the excluded combinations, and the suite tree come back, because the CSV is the export format.

Two behaviors are worth knowing before you lean on it:

• The suite tree is recreated from the suite column. Choose the Parent suite in the dialog to place the whole imported tree underneath an existing suite.
• Turn on “Replace matching test cases” to overwrite cases whose title already exists in the target suite instead of creating duplicates. With it off, an identical title produces a second case.

What a CSV cannot carry

• Attachments. Images embedded in steps are not imported; a missing image afterwards is expected, not a bug.
• Shared steps. A shared step in the source arrives as ordinary steps in the case — the shared step itself is not created.
• Shared parameters. An export writes a shared parameter as a local copy of its values, so a re-import keeps the values as the case’s own parameters. A file cannot carry a reference to a shared parameter: a cell that names one imports the case without its parameters.
• Markdown. .md is not an import format. Export CSV (or JSON, or XML) instead.

Limits and troubleshooting

Both limits are checked before anything is written: a file over either one is refused with a message, not half-imported. Split a large export into batches and import them one at a time.

A row can also import with a notice rather than a failure: Imported as classic steps — the steps did not fit the stated step format. Its Gherkin steps lack a step_keyword, or carry a step_expected. The case still imports, with each keyword kept at the start of its step.

A parameters or excluded_combinations cell that is not valid JSON, or that breaks a parameter rule, imports the case without its parameters and shows the notice Parameters not applied — case imported without them. A replace import then keeps the case’s existing parameters.

A cell that begins with =, +, - or @ is exported with a leading ' so a spreadsheet cannot execute it; the importer strips that ' again, so the case keeps the text you wrote.

Where to go next

• Import test cases — the dialog itself: source tools, formats, replace-matching and what is not imported.
• Test repository — suites, cases and steps, once the file has landed.
• Test case export API — every export format, if you want to go the other way.