Change History
The Change History tab on the test details page gives you an audit trail of every modification made to a test definition. It answers the question "what changed, and when?" — not "who changed it" (see Limitations below).
Versions
Every time a test is saved with actual changes, msg.ZenTestAI captures a new version. The version list is shown newest-first, each entry showing:
- Version N — an integer counter that increases by 1 with every recorded change. The current state of the test is always the highest version number.
- Timestamp — when the save happened, in your local timezone.
- Category chips on the right side — a quick summary of what kind of changes that version contains (see Change categories).
A save that doesn't actually change anything (e.g. you opened the test, hit Save, but edited nothing) does not create a new version. Renaming-only and reordering-only step changes are also filtered out so they don't pollute the history.
Click a version row to expand it and see the field-level details. Use the chevron arrows to step between versions.
Change categories
Each version carries one or more category chips that summarize the kind of changes it contains. You can use them to scan the history at a glance — for example, "which versions touched the Variants?".
The categories used in the UI mirror the structure of a test definition:
- Step — a step was added, removed, or its content changed.
- Activity — a step grouping (activity) was added, removed, or renamed.
- Parameter — a parameter was added, removed, or its name/type was changed.
- Variant — a variant (combination of parameter values) was added, removed, or modified.
- Value — one of the parameter values inside a variant changed.
Header-level fields (title, description, URL, agent, tags, etc.) appear in the table under the Header section without their own chip.
Field-level changes
When a version is expanded, the changes are grouped under section headings that match the structure of the test:
- Header — title, description, start URL, user/role, tags, login required, the "fail on HTTP requests" toggle and other top-level meta-data.
- Activities — additions, removals and renames of step groupings.
- Steps — every individual step that was added, removed, or whose description / settings changed.
- Variants — parameters, the variants themselves, and the values they contain.
Each row in the section shows three columns:
| Column | Meaning |
|---|---|
| Field | The field that changed (e.g. Step 1: Description, Parameter gender, Variant Default: gender). |
| Old Value | The value in the previous version, or — if the field/entity did not exist before (i.e. it was newly created in this version). |
| New Value | The value in the saved version, or — if the field/entity was removed in this version. For created entities, shows e.g. Created with name: gender. |
Example: how additions and removals look
- A new step:
Old Value: —·New Value: Created with description: …. - A deleted step:
Old Value: Removed (description was: …)·New Value: —. - A renamed parameter: shown as a normal update on the field that changed — not as a delete-and-recreate.
- A reordered step list: not shown — order changes alone do not create a history entry.
Saves from external sources
Saves triggered by anything other than the user editor — for example, when an Xray test is Synchronized and re-pulled from Jira — produce a version in the history just like a regular save, with the categories of fields that actually changed.
The AI Assistant also creates regular versions: a single conversation that adds multiple steps and a parameter will result in one version covering all those changes, not many small ones.
Limitations
The Change History tab is intentionally read-only. In particular:
- No user attribution. The history shows what changed and when, but not who made the change. There is no user name or actor recorded against versions.
- No rollback / restore. You cannot revert a test to a previous version, copy an old value back into the current version, or restore a deleted step from history. The Change History tab is purely an audit view; restoring previous content has to be done by editing the test manually.
- No export, search, or filter. You can browse versions chronologically and expand them, but there is no export, no full-text search of changes, and no filter by date or field.
- Retained forever. Versions are kept for the lifetime of the test — there is no automatic eviction or cap on the number of versions stored.
Visibility
Anyone with access to the test can view its Change History. There is no separate permission for it: if you can open the test, you can open the Change History tab.