Activities
Activities are the primary way to organize the steps of a test case. An activity is a named group of consecutive steps — think of it as a chapter or phase inside the test. Long tests become much easier to read and maintain when their steps are grouped into a handful of well-named activities ("Log in", "Fill out form", "Submit and verify", …) rather than presented as one flat list of 50+ steps.
Activities are first and foremost an organizational layer: they have no effect on how the test is executed. The runner simply walks through the steps in order. What activities affect is how the test looks — both while you're editing it on the Steps tab and afterwards in the Last-Runs / execution results view.
The shape of an activity
An activity has a small set of fields:
- Name — the heading shown for the group on the Steps tab and in execution results. Up to 200 characters. Optional, but strongly recommended.
- Description — an optional longer explanation (up to 1000 characters), shown under the activity header when collapsed.
- Disabled — when set, every step inside the activity is skipped at execution time. Useful for temporarily silencing a whole block of steps without deleting them.
An activity also exposes a few advanced settings — Condition, Loop and Parameter bindings — that can wrap the activity's steps. Those are documented separately; this page focuses on the organizational use of activities.
Rules
A few simple rules apply to activities:
- Every step belongs to exactly one activity. If you don't define any activity, msg.ZenTestAI automatically wraps your steps in a single, unnamed default activity.
- Activities span consecutive steps. You cannot have an activity that contains steps 2, 4 and 7 — the steps inside an activity are always a contiguous run.
- Activities cannot be nested. There is no "activity inside an activity".
- Empty activities are removed automatically when you save the test.
On the Steps tab
Each activity is rendered as a collapsible card with a header and a body. The body lists the steps that belong to the activity, in order.
The card header shows, from left to right:
- a drag handle — used to reorder activities,
- an expand/collapse chevron,
- the activity name as an inline-editable text field,
- a step-count badge (e.g. 3 steps),
- small chips indicating whether the activity has a configured Condition, Loop or Parameter bindings,
- on hover, a toolbar with buttons to disable / enable, open the settings sidebar, suggest a name via AI, and delete the activity.
A disabled activity is rendered semi-transparent so it stands out at a glance.
Adding an activity
Use the Add activity button at the bottom of the Steps tab. The button is a split button: the main action adds a blank activity at the end of the test, and the dropdown next to it offers Suggest activities, which asks the AI to group your existing steps into well-named activities for you.
Renaming and deleting
- Rename an activity by clicking on its name and typing. Changes are saved as you type — press Esc to cancel, Enter to confirm.
- Delete an activity using the trash icon on the hover toolbar. If the activity contains steps, you are asked to confirm. The steps themselves are not deleted — they are merged into a neighbouring activity (or wrap-around into the default activity if none remains).
Reordering, moving, splitting, merging
- Reorder activities by dragging the activity card by its drag handle.
- Move a step into a different activity by dragging the step from one activity's body and dropping it into another.
- Split an activity by opening a step's context menu and choosing Split activity here — the steps from that point on move into a new activity.
- Merge activities by dragging one entire activity card onto a step inside another activity. The dragged activity's steps are added to the target.
Settings sidebar
Clicking the settings icon on an activity's hover toolbar opens a sidebar with the activity's full configuration:
- General — name, description and the Disabled toggle.
- Condition — an expression that gates whether the activity's steps run at all.
- Loop — settings to repeat the activity's steps (for each row of a data set, for each value of a parameter, …).
- Parameter bindings — how parameters from the test are mapped to local variables used by the activity's steps and loop.
The Condition / Loop / Bindings settings are advanced and worth a chapter of their own — they don't change the fundamental organizational nature of activities, but they let an activity wrap a block of steps with extra runtime behavior.
Activities in the execution view
When you open the results of a past execution from the Last-Runs tab, the steps are still grouped under their activity headers, so the structure you defined while editing is preserved at review time too. This makes it much easier to scan a long run and find the section you care about.
Activities and change history
Adding, renaming, deleting and moving activities are all recorded in the test's Change History (see Change History). Activity changes appear under the Activity category chip, with old / new values for the affected fields.
Where activities come from
- Manual editing — most activities are simply created and named by the user on the Steps tab.
- AI suggestion — the Suggest activities option on the Add-activity button can group an existing flat step list into well-named activities. The single-activity AI button on the hover toolbar suggests a name for one specific activity.
- Recording — manual recording captures steps only, not activities. Once you've recorded a test, you can organize the captured steps into activities yourself or via AI suggestion.
- Import from external systems — when a test is imported from Jira XRay or Zephyr, msg.ZenTestAI preserves any source-side grouping where possible, or assigns the imported steps to activities using a positional heuristic.
Snippets and activities
Snippets also support activities — the structure on the Steps tab is identical. The hover toolbar inside a snippet is a little simpler (no per-activity AI name suggestion, no per-activity delete shortcut), but you can still create, rename, reorder and group steps using activities just like in a regular test.
Why bother
The reason to invest a minute in naming activities every time you create a test is that it pays back many times over:
- Readability — a 60-step test split into seven named activities reads like an outline, not a wall of text.
- Debugging — when you open the execution results, the failing step is shown under its activity, so you immediately know which phase of the test failed.
- Reuse and refactoring — moving a meaningful chunk of behavior into a snippet, or replacing it with a different flow, is far easier when the boundary is already drawn by an activity.
Activities cost nothing at runtime. The only "wrong" choice is not to use them at all.