Skip to content

Test case versions

Version history records how a normal library test case looked at an earlier point. A version includes the test case and its variants together. Quick test cases are excluded. Version history does not replace test results or the supplementary change log.

View and compare versions

Open a normal test case in the Test library and select Versions. You need read access to that test case. Select a saved version to inspect its content and files. To compare versions, select two entries. Changed areas are listed and their contents are displayed side by side.

Saving changed content automatically creates a version. Saving unchanged content creates no additional version. Save all groups the edited fields of a test case into one state. Immediately saved actions, such as adding an attachment, are separate changes.

The baseline captured when an existing project is upgraded is not a reconstructed history. Earlier changes may still be available in the previous change log; they are not presented as complete test case versions.

What a version contains

  • Description, preconditions, test steps, expected results and variants, including the inherited content effective at that time.
  • Custom fields with their historical values and definitions, including inherited values effective at that time.
  • Fixed versions of reusable step blocks and their complete text.
  • Stored attachments and embedded images as independent copies.
  • Captured business relationships as provenance information.

Historical files remain readable after their originals are removed from the current test case. Access still requires current permission to read the test case. Externally linked attachments are identified as references; their targets are not downloaded or permanently archived. Internal server paths are not exposed in version history. Restoration preserves the currently existing external links. Files already missing before capture cannot be recovered by versioning and are marked accordingly.

Password fields are excluded from readable historical content. Credentials and executable external-tool configurations are not reset by restoration. Each file may contain up to 100 MB, with a combined limit of 256 MB per version; larger content must be handled separately before saving.

Restore earlier content

With edit access, select an earlier version and choose Restore. Review the preview before confirming. Restoration creates a new current version referring to the source version. It never overwrites an old version.

If required field definitions have been removed or their types or allowed values no longer match, the preview blocks restoration. Restore those definitions or explicitly exclude the affected fields. Unavailable reusable block references can only be converted to independent historical text after you explicitly select that option.

Restoration restores the field values stored directly on the test case and its variants. Inherited custom values remain visible in the historical view; their parent definitions are not changed. The current test case continues to use the current inheritance rules after restoration.

Permissions, personal settings, results and previous review approvals are not restored. Historical relationships are not silently recreated. Existing test runs retain their copied content; restoration does not rewrite old results.

If someone changes the test case after your preview, restoration is rejected. Reload the current state and review the comparison again.

Templates, runs and reviews

A plan template can adopt a selected library state. New test runs retain their copied contents and recorded version origin. Later library synchronization does not change existing normal run definitions. Older runs without recorded provenance are not assigned an invented version. Individual copies between projects do not retain a foreign revision identifier when its archive is absent from the destination project.

Changes to inherited field values or central field definitions do not immediately create a version for every test case. Save the affected case before approving it again. While its current content differs from its saved version, a new review decision is rejected; a plan copy is not assigned a misleading version reference.

New review decisions refer to the content that was reviewed. If it changes before confirmation, the current content must be checked again. Restoring content does not automatically reinstate an earlier approval.

Windows and APIs

Windows remains usable for editing and executing test cases. Versions in the web client in the test case window opens the corresponding browser view through the same sign-in handoff as Open in web. Comparison and restoration take place in the browser. A web sign-in is only needed if the handoff fails.

MCP and REST enforce the same project and object permissions. ztm_project_test_case_versions provides the list, content, comparison, file content and restoration preview. The project.test-case-version.restore capability is prepared and confirmed through ztm_project_action_prepare and ztm_project_action_commit. General API write permission does not replace object permissions.

Upgrade and back up projects

Back up the complete project and close all old Windows, web and background processes for that project before upgrading its schema. The migration also installs database protection against writes from older clients. Ordinary writes from current clients are blocked while migration is in progress. After an interrupted migration, a current client must finish the upgrade.

This protection does not replace a maintenance window: older programs can access project files directly without writing to the database first. Mixed writing with old clients therefore remains unsupported.

Historical file contents are backed up with the project database. Full project transfers and database conversions must preserve history, files and version provenance together. A text or spreadsheet export is not an archive of the complete version history.