Tests need data: a price to check against, an account to sign in with, a reference number a later step depends on. Studio keeps that data out of the test itself, so the same tests can run against different environments and so secrets never end up written into a step.
The whole picture
Execution presets: the main mechanism
An execution preset is a named set of variables, defined once per project and applied at run time.
Find them at Project Settings → Execution → Execution presets. Studio describes them as:
Execution presets are reusable variable sets that configure how tests run in this project. Select a preset when running tests or starting sessions to apply its variables automatically.
They exist at project level only — they describe an environment or a data set, and both are properties of the project rather than of one test.
Creating one
- Open Project Settings → Execution → Execution presets.
- Choose New Preset and give it a name. Name it after the environment or data set it represents — QA data, Staging, Large account — not after who made it or when.
- Open the preset to manage its variables.
One preset is marked Default, and that is what applies when nobody chooses otherwise.
Adding variables
Each variable has three parts:
| Name | How the test refers to it. Use something descriptive and stable —
expectedAcPrice, not val2. |
| Value | What it resolves to at run time. |
| Encrypt value | A checkbox. Switch it on for anything sensitive. |
Using one in a test
Refer to a preset variable by name, in this form:
{{fze.preset.expectedAcPrice}}You will see this shape in generated steps — a login step, for example, records that it typed
the password provided by {{fze.preset.…}} rather than recording the password.
The simplest way to wire one in is to ask:
Use the preset variable expectedAcPrice for the price check instead of a hard-coded value.Where to verify it worked
Two places, both under the browser pane in the test editor.
The Variables tab shows the values a step actually used. When a step used none it says so plainly — "No variables recorded for this action". This is where you confirm a variable resolved to what you expected, rather than inferring it from the step text.
The Components Model tab shows the substitution happening. Two components in the per-step pipeline do this work:
-
Variable Inject Pre— makes the variables available to the step. -
Variable Expander— replaces the placeholders with values.
Both are listed with an elapsed time and a confidence score, alongside the rest of the pipeline. If a value did not resolve, this is where the evidence is.
Secrets
Studio prints a warning under every prompt box:
In no event should you put sensitive information into Functionize.
Preset variables with Encrypt value enabled are the supported alternative. The rule in practice:
- Never type a real password, API key or token into a prompt, a test step, or a skill file.
- Do put it in a preset variable with encryption on, and refer to it by name.
- Prefer tests that need no credentials at all. Our exercise series runs entirely signed out for exactly this reason.
For environment-level access — HTTP basic auth, client certificates, mutual TLS — use the Access & Auth settings instead, covered in Timeouts, Access and Browser Behavior.
The other ways data reaches a test
| Cookies | Injected into the browser before each run. The clean way to skip a consent banner, set a feature flag or fix a locale without adding steps. |
| Custom HTTP headers | Sent with every request — environment routing, gateway tokens. |
| Extensions | Your own code, when data must be generated or fetched: a one-time passcode, a seeded record through an internal API, a value read from a file format. |
| Values captured mid-run | A step can capture something the application generated — an order number, a reference — for a later step to use. These appear in the Variables tab too. |
Patterns worth adopting
One preset per environment. The same tests, pointed at QA or staging by choosing a different preset at run time. This is the alternative to duplicating a suite, and duplicated suites are how coverage silently diverges.
Put expected values in variables when they move. A price that changes with every catalog update belongs in a preset, not in forty steps. A page heading that never changes is fine inline.
Do not over-parameterize. A test where every value is a variable is unreadable, and unreadable tests do not get maintained. Parameterize what genuinely varies.
Name variables for meaning, not for source. expectedAcPrice tells
the next person what it is for. var3 does not.
A worked example
The demo project used throughout our exercises has a preset named Anaqa Test Data holding one variable:
expectedAcPrice |
$966.00 |
If the store repriced that product, one edit in the preset would update every test asserting on it — instead of hunting through steps. That is the whole case for test data management in one sentence.
See also Settings: Where Everything Lives for how project and test settings relate, and Extensions: Running Your Own Code Inside a Test for generated data.