Test Data

Tests in msg.ZenTestAI rarely operate on a single fixed set of values. You usually want to run the same steps with different data — different users, different products, different countries — and you sometimes want a single test step to iterate over many rows of data on its own. Test data is the umbrella term for both.

Test data is per-test today

Test data currently lives inside the test definition — there is no tenant-wide or shared test data catalog yet. A global test data concept is on the roadmap; until it ships, each test owns its own test data, and the only built-in way to share values is to import them through a connected external system (e.g. Jira XRay).

Two flavours of test data

A test has two distinct kinds of test data, and they answer two different questions:

Flavour	Answers	Where it lives
Execution variants	"Run the same test multiple times, each with different parameter values."	The Variants tab on the test details page.
Tabular data parameters	"Inside a single run, repeat one part of the test for each row of a data table."	A parameter on the test, defined with type Tabular.

The two flavours can be combined: a test with a tabular parameter can also have variants, and each variant can give the table different content.

Parameters in brief

Before diving into variants and tables, recall what a parameter is: a named placeholder referenced from anywhere in the test using [[parameterName]] (steps, URLs, conditions, loops, …). A parameter has:

• a name (the value used in [[…]]),
• a type: Text (the default — any string), Boolean, or Tabular (a table of rows and columns), and
• one or more values, one per variant.

Parameters are managed on the Variants tab. The same tab manages variants too — parameters are the columns, variants are the rows.

Execution variants

A variant is a named bundle of parameter values that defines one execution of the test. Every test has a Default variant — it is created implicitly when the test is created, and you can rename or edit it but not delete it.

Adding and managing variants

On the Variants tab:

• Click New combination to add a new variant. You can name it freely (e.g. DE-private, FR-business, expired-license).
• Fill in the value for each parameter in that variant.
• Each variant can also override a few execution settings — typically the Base URL, Agent and Language — when those should differ between runs.
• Copy combination duplicates an existing variant to use it as a starting point.
• Delete removes a variant (the Default variant cannot be deleted).

There is no automatic "cross-product" generator today — each variant is entered manually or imported from an external system.

Choosing variants when executing

When you click Execute Test on the test details page, you are asked which variant(s) to run. You can pick:

• the Default variant (if you don't make an explicit selection),
• one specific variant,
• multiple variants — msg.ZenTestAI schedules one execution per selected variant.

In the test list, the Last Execution / Status columns reflect the most recent run regardless of which variant produced it. The execution details show, per run, which variant's values were used.

Tabular data parameters

A Tabular parameter is a parameter whose value is a table of rows and columns, not a single value. You use it when:

• You want a loop (on an activity or a snippet-reference) to iterate once per row of data, or
• You want to keep a tidy list of related values together rather than scattering them across many scalar parameters.

Editing the table

On the Variants tab, a Tabular parameter shows a small preview of its table and a button to open the table editor. The editor offers a familiar spreadsheet-style grid:

• Add or remove columns; column names are free-form, with no schema enforced up front.
• Add or remove rows one by one, or paste from a spreadsheet to fill the table in bulk.
• A row can have empty cells; the values are plain text.

The same table can carry different content per variant — for instance, your DE-private variant might give the customers table three German rows while the FR-business variant gives it five French ones. When you run a specific variant, the loop sees exactly that variant's rows.

Using the table in a loop

Once a tabular parameter exists, attach it to an activity or snippet loop by opening the activity / snippet-reference sidebar and choosing Loop → Over a data table. The loop wizard then asks you to:

• pick the tabular parameter that drives iteration,
• choose a row-matching strategy — Index (row N for iteration N — the simplest case) or Lookup (find the row that matches certain column values),
• map each inner-step parameter to either a column of the table or some other source (iteration index, fixed value, value from the calling test, …).

See Loops and Conditions → Iteration variables and parameter mapping for the full mapping flow.

Test data inside snippets

When a test calls a snippet, the snippet's inner steps have their own parameter references — typically things like [[user]] or [[amount]]. The calling test feeds those parameters through the parameter bindings on the snippet-reference step. Bindings can be:

• a fixed value entered in the binding form,
• a mapping from a parameter of the calling test (so the snippet inherits the current variant's value), or
• — when the snippet-reference is wrapped in a loop — a column of the loop's data table.

This is how variants and tables propagate into snippet logic: the snippet itself does not own the values; the calling test (or its loop) supplies them per execution / per iteration.

Tests bound to Jira XRay

For tests imported from and bound to Jira XRay, the General tab exposes a Sync Test Data toggle. With it enabled:

• Variants and tabular parameter rows are kept in sync with the corresponding XRay dataset on every save and re-sync.
• When the XRay dataset gains new rows, your test picks them up on the next sync.
• Local edits to variants and tables can be pushed back to XRay.

Use this when XRay is the system of record for your test data. Without the toggle, msg.ZenTestAI imports the test but keeps test data local from then on.

See External Systems → Re-synchronizing for the full sync flow.

Permissions and limits

• Permissions — test data follows the same rights as the rest of the test definition. Anyone with edit rights on the tenant can add, edit and delete variants and tabular data.
• Limits — there are no hard caps in the application on the number of variants per test or rows per table. Very large tables (tens of thousands of rows) may run into limits in connected external systems before they affect msg.ZenTestAI itself.