Recording

The recording flow lets you build (or extend) a test by interacting with the application in a live browser. Every interaction is observed, translated into a natural-language step by the AI, and inserted into the test definition. You can mix recorded steps with hand-written ones, edit the AI's wording at any time, and switch between automatic playback and manual recording inside the same session.

Recording is interactive in both directions:

• You drive the browser. Click an element in the live preview and pick Click, Type, Assert, Scroll, Drag & Drop, etc. — the AI describes what just happened as a step.
• msg.ZenTestAI drives the browser. Press Next Step or Run and the runner plays the existing steps one-by-one or to the end. You can pause, reposition the playback cursor, and switch back to recording at any point.

When to use it

Recording is fastest when:

• you need to build a straightforward end-to-end test against a UI you already know,
• you want to extend an existing test with a few extra steps without re-typing the whole flow,
• a recorded run failed and you want to take over from the failed step to either fix it or branch into a new path.

For deeply parameterized or assertion-heavy tests, writing prompts by hand often stays cleaner — recording is best at capturing the actions. After recording you can edit any step's description to make it more generic, parameterize it, or add macros.

Starting a recording

There are four ways to enter the recording flow:

• Record Test — the button in the header of the test details page. Starts a new session at the end of the existing steps (append mode). Visible only for normal tests (not snippets), on saved tests, when you have edit rights and the test isn't bound to an external system.
• Record from here — appears inline between any two steps in the Steps tab when you hover the gap. Inserts new recorded steps at that exact position; the steps before it are played back to set up the browser state first.
• Start Recording from here — appears in the step popover when you open a finished execution's step on the Test Executions page. Useful for going back to a specific point of a past run and recording a different continuation.
• Switch to interactive mode after a failure — when a normal test execution fails, a dialog asks whether the failure was expected. Choosing No (Switch to interactive mode) pivots the running execution into recording, with all earlier steps preserved as they ran.

If the test has multiple execution variants, you'll be asked which one to use — recording always runs a single variant.

note

Snippets cannot be recorded. The Record Test button and the per-step Record from here button are hidden for tests of type Snippet.

The recording screen

The recording view replaces the Steps tab with a two-pane layout:

• Left pane — the step list. Every step of the test is shown as a numbered row with a status icon (pending, running, passed, failed). The currently active step is highlighted, and a draggable action bar sits between rows to mark where playback will resume.
• Right pane — the live browser. A real browser session controlled by the runner. You see what the runner sees, with a URL bar, navigation chrome (Back / Forward / Reload), a lock toggle and a Dev Console button.

The divider between the two panes is resizable.

The lock toggle

The browser preview has a lock / unlock toggle in its toolbar that decides what happens when you click inside it:

• Locked (default during recording) — clicking the screenshot opens the Action menu and creates a step.
• Unlocked — clicking the screenshot does not create a step. Instead you can drive the browser freely: click, type, hover, press a key, scroll, edit the URL in the address bar and so on. Use this when you need to massage the browser into a particular state before the next recorded step (e.g. close a banner you don't want in the test, scroll to a section, log in via a one-time UI you don't want captured).

The lock button pulses when you reposition the playback cursor, as a hint that the browser state may need to be adjusted to match the new starting point.

Capturing a step

With the browser locked, hover the live preview — a red highlight follows your mouse. Click any element and a small Action menu appears next to the cursor. Pick the action type and the AI will translate the click + action into a natural-language step:

Action	What it captures
Click	A plain left click on the chosen element.
Type	A text input. A small popover asks for the text and an Confirm via Enter toggle.
Select from combobox	A combobox / dropdown choice. The popover asks for the option to select.
Additional mouse actions	Sub-menu with Hover, Focus, Right click, Double click, Triple click, Middle click, Back button click, Forward button click, and Drag & Drop.
Assert	An expectation step. The popover asks for the expectation text — e.g. "the page shows a green success badge".
Scroll	Scrolls a specific container by a pixel offset. The popover offers the available scrollable containers.
Freestyle	A free-form natural-language step bound to the element you clicked. Use this when none of the built-in action types fits.

For Drag & Drop you click twice: first on the source, then on the drop target.

After you confirm the action, the AI looks at the screenshot, the accessibility tree, and the candidate XPath selectors, and produces:

• a natural-language step description (e.g. "Click on the Save button"),
• a hidden XPath hint that pre-populates the XPath cache so future runs of this test can skip the element-identification AI call.

The step appears immediately in the step list and is auto-saved on the backend — there is no separate "approve" step. You can edit the wording at any time (see Editing steps below).

tip

The lock-and-action-menu flow is the recommended way to drive recording. Don't try to use the browser's right-click context menu or keyboard shortcuts inside the preview while locked — they don't create steps.

Driving the playback

The step list controls how the runner plays back existing steps:

• Next Step ▼ — inline on the currently active step. Plays the step and pauses on the next one.
• Run ▶ — plays from the current position to the end of the test, without pausing. Use this to fast-forward through a known-good section.
• Run until here — appears on the gap between two steps. Plays everything up to that gap, then pauses.
• Drag the action bar — the resume line between two steps can be dragged up or down to reposition where playback will continue. Note that this does not rewind the browser; you may need to unlock and adjust manually to match the new starting position.

The list auto-scrolls to the active step. Each step row can be expanded to show the individual browser operations (click, type, assert, …) that composed it, each with their own pass/fail indicator — useful for diagnosing exactly which sub-action failed.

Adding, editing and deleting steps

You can mix recorded steps with hand-written ones at any time:

• Add step — both in the action bar and inline between any two existing steps. Opens a small editor where you describe the step in natural language without interacting with the browser. The newly added step inherits the position you opened it at.
• Edit step — click the description text on any step row. A popover opens with the step's text, sub-action breakdown, and Save / Cancel / Delete buttons. Editing replaces the entire step text; if you also click an element in the screenshot while editing, the AI re-resolves the step against that new element.
• Delete step — the Delete button inside the Edit step popover. Requires a confirmation.

There is no merging or partial-overwrite of edited descriptions — the new text fully replaces the old one and the runner re-resolves the action from scratch the next time the test runs.

Recovering from a failed step

When a step fails during recording, the failed row turns red and the action bar offers:

• Finish Recording — stop the session and keep the test as-is, with the failure recorded.
• Reset failed step — move the resume line back one step. You can then unlock the browser, adjust state if needed, and try again with Next Step or by recording a replacement.
• Add step — insert a new step at the current position (e.g. an extra wait, an assertion, or a workaround click).

You can also edit the failing step's description directly to see if a clearer wording resolves it.

The first time a step fails in a recording session, an explanatory dialog appears. It has a Don't show this automatically checkbox if you find it gets in the way.

Recommendation mode

If you're not sure how to phrase a step against a particular element, switch the step popover into Recommendation mode and click the element you want to interact with. The AI returns up to four alternative step descriptions for that element + action — for example "Click on the Save button", "Click on the primary action button in the dialog footer", "Click on the button labelled Save in the New Order dialog". Pick the one that best fits your audience and paste it into the step description.

Recommendation mode is read-only — it doesn't change the step on its own, it just suggests wordings. It is not available for login steps.

Finishing a recording session

When the runner reaches the end of the test (TEST_DONE state) the action bar shows two buttons:

• Finish Recording — ends the session. The browser closes and you're returned to the standard test details view.
• Add step — append one more step before finishing.

While the test is at the TEST_DONE state, you can also just click any element in the live preview to record one more step directly — no menu in between, since there are no further pre-existing steps to play back.

If you simply close the browser tab or navigate away, all steps you already captured remain saved on the test definition (recording auto-saves continuously). The runner side of the session is cancelled.

Login and authentication

If the test requires login, the runner uses the test's configured User / Role and the Login-Agent to log in before the recording session becomes interactive — you don't have to record the login flow yourself. The first interactive step is whatever comes after the login.

If you do need to record a login flow manually — e.g. for a snippet, or to capture a non-standard auth screen — unlock the browser, perform the steps manually first, then lock it again to continue recording from the post-login state. (Note that snippets still can't be recorded today; you'd need to log in inside a normal test.)

Limitations

Things the recording flow does not support today:

• Snippets — only normal tests can be recorded.
• Native file pickers — file uploads via the operating system's file dialog cannot be recorded. Use a File Upload assignment on the step instead.
• Multiple variants in one session — you must pick a single variant when entering recording.
• Remember / capture into parameter — there is no dedicated button to record a Remember step. Add the step manually via Add step and write the Remember … prompt; the parameter will be picked up from the text.
• Parameter and macro picker in the recording popover — the Edit step popover currently hides the parameter/macro autocomplete (=). If you want a parameter reference inside a recorded step, edit the step from the normal Steps tab after the recording session ends, or write [[PARAMETER_NAME]] by hand.
• Per-frame accessibility in nested iframes — clicks inside iframes generally work, but accessibility-tree reads are still limited to the main frame; if recording inside an iframe behaves oddly, try unlocking the browser and clicking the element directly.

Other things worth knowing

• Idle timeout. A recording session times out after about 10 minutes of no user interaction; the runner then leaves interactive mode and completes (or fails) the test on its own. Click something every now and then if you're parking the recording.
• Cost. Each captured or edited step makes one call to the AI to describe the action. The cost is in line with normal step execution; there is no separate recording quota.
• No "draft" mode. Steps are persisted to the test definition as soon as the AI returns their description. If you decide you don't want them, edit or delete them — there is no whole-session rollback.
• XPath pre-cache. Recording also fills msg.ZenTestAI's XPath cache, so the first normal run of the test after recording skips an AI element-identification call per recorded step and starts faster.