Reusable test steps¶

Reusable step blocks describe a shared procedure once for use in several normal test cases. A block contains formatted test steps and optional expected results. Preconditions remain part of the test case. There are no additional attribute schemas, parameters or separate execution results for each block.

Quick test cases and their variants are excluded from this initial scope. Blocks do not execute another test case and do not replace test case dependencies.

Maintain blocks in the browser¶

Open Reusable test steps in the project. Each block belongs to a test unit. Reading requires read access to that unit; maintenance requires the corresponding full access. The list only includes content you are allowed to access.

1. Select the test unit and enter a meaningful title, such as “Sign in to the customer portal”.
2. Enter the steps in the formatted editor and add expected results if required. A change note explains a new state.
3. Save the block. A change creates a new fixed version.

Archived blocks remain available to existing uses. A new block version does not automatically change test cases that use it.

Use a block in a normal test case¶

Open a normal test case in the Test library, select the variant if applicable, and open the reusable step composition editor. You need edit access to the test case and read access to the blocks you use.

A composition contains ordered local sections and block sections. Local sections also contain steps and optional expected results. A block section uses an explicitly selected fixed version. Check the content, order and complete output before saving. On the first switch to managed composition, the existing effective steps and expected results are included as a local section.

When a section offers a newer block version, open the comparison and review the previous and new content. Only explicitly adopting it and saving changes this use. Other uses retain their previous state.

Converting an individual block section to local text preserves its content within the managed composition. Save the change afterwards. Converting the entire composition instead removes its managed state and stores the steps and expected results as free text on the test case. This action uses the last saved state; save any desired edits first. Check the preview before confirming. Neither action changes other test cases or the block library.

Variants can inherit content from the primary variant. When creating a separate composition, check which effective content is included. An explicitly saved empty expected result in a separate managed composition stays empty instead of inheriting the primary text.

Images and attachments¶

Inline images belong to the content of a block revision. Saving creates separate image copies so older revisions and adopted content remain readable after the original image is changed or deleted. Externally linked images remain outside the project and are not permanently captured content.

Blocks do not have their own file attachments in this first version. Existing attachments remain on the test case or variant; a step block revision does not version those attachments.

Plan and execute tests¶

Steps and expected results remain readable as complete text, including during execution, reporting and export. Using a block does not create an additional result status or change test statistics.

A new library state is deliberately synchronized into the plan template. Existing test runs retain the content they received, including the block versions used. Test new content in a new run or through the applicable retest workflow.

Windows and automation¶

Blocks and their compositions are maintained in the browser. Windows displays the complete content and uses it during execution. Managed steps and expected results are read-only there; the web link opens the corresponding editor or the read-only view of a planned content snapshot. Other permitted test case fields remain editable. Automatic sign-in handoff uses the same mechanism as Open in web.

MCP integration uses the same project and object permissions as the interface. Read tools and prepared write actions for block maintenance, composition and conversion are also available through MCP; they do not grant additional permissions. See Safe actions and MCP for the tool contracts.

Copying and transferring projects¶

When individual content is imported from another project, block uses become independent local sections. They are not linked to the source project’s block library, and later source changes do not affect them. A complete project transfer retains the blocks, versions and uses together.

Existing text modules remain an insertion aid: inserted text is a copy without a continuing version link. Existing text is not automatically matched or migrated to a block.

Related topics: Test cases in the browser, Test variants and Planning tests.

The same operations are available through the REST API: read with POST /api/v1/operations/ztm_project_reusable_test_steps and {"operation":"list"}; write through ztm_project_action_prepare and ztm_project_action_commit. The capabilities are project.reusable-test-step.save, project.reusable-test-step.composition.save and project.reusable-test-step.composition.detach. A project header and API key are required; the same permissions and preview checks apply.