Skip to main content

Parameters and Test-Data

You can parameterize a test case to run it with different data, users, environments or browser languages — without copying the test for every variation. The two building blocks are:

  • Parameters — named placeholders you reference from steps or the start URL.
  • Execution Variants — concrete sets of parameter values (and optional overrides for URL, user/role and language) that turn one test definition into several runnable executions.

This chapter covers both, plus the "Remember" pattern for capturing values during a run.

Parameters​

A parameter is a named value that can be referenced from any free-text field in your test (step descriptions, the start URL, instructions on AI steps, …).

Defining parameters​

There is no separate "Parameters" form — you don't go anywhere first to declare them. Parameters are created the moment you use them:

  • In a step description, type = to open the autocomplete picker. It lists all parameters (and macros) available, plus a Create Parameter entry to add a new one inline. Pick an existing one or create a new one — the editor inserts the reference for you.
  • Use the parameter button in the toolbar next to the step description editor — it opens the same picker without typing =.
  • Or just type [[PARAMETER_NAME]] directly. msg.ZenTestAI auto-derives the parameter from the step text and adds it to the Variants tab. This works, but is rarely needed — the picker is faster and avoids typos.

The parameter then appears on the Variants tab, where you can set its value for each variant.

Parameter types​

Three types are supported:

TypeUse for
TextThe default — any string value (names, identifiers, URLs, dates, …).
Booleantrue / false. Especially useful with conditional / Deactivate Step settings.
TabularMulti-row table values, useful for data-driven loops where one variant needs to iterate over many rows.

Where parameters can be used​

  • Inside the start URL (query or path segments).
  • In any step description — including assertions, Remember prompts, and AI step instructions.
  • In macro arguments — e.g. ${=global_addDays(7, YYYY-MM-DD, [[startDate]])} — see Macros.
  • In other parameters' values in a variant, so one parameter can compose from another.
tip

For computed values — today's date, a sum, a random number — prefer a macro over a dynamic calculation. Macros are deterministic and testable in isolation; their result can be assigned to a parameter via Remember if you need the same value across many steps.

Execution Variants​

A test case has one or more execution variants. Each variant is a named set of:

  • Parameter values — what every parameter should evaluate to.
  • Overrides — optionally replace the test's start URL, the test's user/role, or the browser language.

You manage them on the Variants tab of the test details page.

The Default variant​

Every test starts with an implicit variant called Default. It cannot be renamed or deleted. The Default variant is the fallback used:

  • when the test is executed without explicitly picking a variant (e.g. from the test-list Play action),
  • when a parameter is left blank in another variant — the value from the Default variant is used as a fallback,
  • when a referenced execution plan does not specify a variant for this test.

Adding variants​

Click Add new execution variant to create another one. You then fill in:

  • A name (or pick from suggested tag labels such as Desktop / Mobile / DE / EN).
  • A value for every parameter defined on the test. Leave a value blank to inherit it from the Default variant. Parameter values can themselves contain [[otherParameter]] references and ${=macro(...)} calls.
  • Optional overrides (see below).

The list on the left of the tab shows every variant; the currently selected one is shown on the right.

Variant actions​

Each variant row has:

  • a radio button to select it for editing,
  • a name input (Default has a fixed chip label),
  • a copy action to duplicate the variant with all its overrides and values,
  • a delete action (hidden for Default and for variants synchronized from an external system).

Overrides​

Three switches are available at the bottom of the variant editor — each is off by default and becomes a value picker once toggled on:

  • Overwrite the URL — run this variant against a different start URL than the one on the General tab. Useful for running the same test against multiple environments.
  • Overwrite the User/Role — run as a different agent than the test's default. Use this for "same flow, different role" variants.
  • Overwrite the Language — set the browser locale for the run (e.g. de, en, fr). Affects what the browser advertises to the application under test; useful when you want to run the same flow against different localizations.

Running a test with variants​

When you press Execute Test on the test details page, a variant picker appears:

  • During normal execution you can tick multiple variants — each selected variant runs as a separate execution.
  • During recording you can pick only one variant.
  • You must pick at least one variant — the dialog rejects an empty selection.

When you start a run from the test list (the Play action on a row), the variant picker is not shown — the test runs with its Default variant. To run a specific non-default variant, open the test details and use Execute Test.

Capturing values during a run — Remember​

Beyond values you set in a variant, parameters can also be filled at execution time with whatever is visible on the screen, using a Remember step:

Remember the order number visible in the confirmation message in the parameter ORDER_NUMBER

When naming the destination parameter inside a Remember prompt, write the parameter name without the [[ ]] brackets — those are only used when reading the parameter back in a later step.

The captured value is shown in the execution details for that run, and can be used by later steps in the same test or — through an execution plan — by following tests.

Sharing parameters across tests​

Parameters live on a single test, but their values can flow into other tests via execution plans:

  1. Test A captures a value into a parameter with a Remember step (e.g. ORDER_ID).
  2. In the execution plan, you bind Test A's ORDER_ID output to Test B's ORDER_ID parameter.
  3. When the plan runs, Test B sees the value captured in Test A.

This is the standard way to do end-to-end / multi-test scenarios — create an order in one test, approve it in another, archive it in a third.

When are parameters resolved?​

Parameter substitution happens in two phases:

  1. At interpretation — when the test description is translated into actionable steps. Only parameters that are defined on the Variants tab and not updated by an earlier Remember step are resolved here.
  2. At execution — just before each step runs. Dynamic parameters (those set by Remember) are resolved with their current value.

Worked example​

Step 1: I click the button with the text [[BUTTON_TEXT]]
Step 2: Remember the visible button text in the parameter BUTTON_TEXT
Step 3: I click the button with the text [[BUTTON_TEXT]]

With BUTTON_TEXT = "Value" set on the variant:

  1. Step 1 is resolved during interpretation. The AI agent sees I click the button with the text Value.
  2. Step 3 is not resolved during interpretation — the agent sees the literal [[BUTTON_TEXT]] and knows the value will arrive at execution time. The action it determines (clicking a button by text) is therefore established up front.
  3. At execution, Step 3 resolves BUTTON_TEXT to the value captured in Step 2 and clicks that button.

Limitation​

You cannot use a Remember step to change a step's action type. The interpretation phase needs to know what kind of action each step performs (click, type, assert, …) before any Remember runs.

STEP_DEFINITION = "Click on the button with the text ABC"

Step 1: Write Hello
Step 2: Remember the value visible in the combobox in the parameter STEP_DEFINITION
Step 3: [[STEP_DEFINITION]]

Step 3 fails — interpretation sees only [[STEP_DEFINITION]] and cannot pick an action. The dynamically-set step text never gets a chance to drive a real action.

Tests bound to an external system​

For test cases imported from and bound to Jira XRay or Zephyr with synchronized test data, variants and their parameter values become read-only. The external system is the master for the data set; unlink the test (see External Systems) if you need to edit the variants locally.