Version History and Rollback
Every test case in QAM Hub keeps an automatic version history — a timeline of snapshots capturing how the case looked at each meaningful change. From that history, an authorized user can roll back the case to any earlier snapshot. This protects against accidental edits, supports auditing what changed and why, and lets teams revise cases confidently knowing prior states are recoverable.
What each version captures
Each version is a full snapshot of the test case at the moment of change, including:
- Title, Steps, Expected Result, and Automation status
- Tags assigned at that time
- Custom field values
- Linked requirements
- Attachments (screenshots) and how they were arranged per block
- The group the case belonged to
- Who made the change (the editor's name is stored permanently, surviving even if that user is later removed)
- Timestamp, and an optional "Reason for change" comment
Versions are numbered sequentially (v1, v2, v3 …). QAM Hub keeps the most recent 20 versions per test case; older ones are pruned automatically.
When a new version is created
- On edit — when a case is edited and saved, a snapshot of the prior state is recorded.
- On attachment changes — screenshot additions and removals are snapshotted.
- On restore — before a rollback is applied, the current state is first saved as a new version labeled "Restored from v{n}", so a rollback is itself reversible.
Viewing version history
Version history lives in the test case's History tab, under an Edit History section (alongside execution history and automation runs). For each version, the UI shows the version badge (v{n}), the editor's name, the timestamp, and any "reason for change" comment.
A change summary compares each version to the one before it — across title, steps, expected result, automation status, group, tags, custom fields, requirements, and attachment counts. Long text fields (steps, expected result) offer an expandable inline diff, so reviewers can see exactly what text changed.
Rolling back to an earlier version
When you choose to restore a version, a confirmation modal previews the exact state the case will have afterward — title, steps, expected result, automation status, tags, custom field values, and screenshot counts per block — plus any warnings.
On confirm, QAM Hub restores the snapshot intelligently:
- Core fields (title, steps, expected result, automation) are restored.
- Tags are restored; any tag names that no longer exist are re-created automatically.
- Custom fields are restored only for fields that still exist in the project (fields deleted since are skipped).
- Requirements are restored only if they still exist and the Requirements module is enabled.
- Attachments are restored where possible: existing images are re-positioned, and missing ones are recovered from the project's asset library if still available. If some screenshots can't be recovered, the restore still completes and you're told how many could not be restored.
Crucially, a rollback does not erase history: the pre-rollback state is saved as a new version first, and the version you restored from is protected from pruning — so nothing is lost and the action can be undone.
Who can view and restore
Viewing version history is available to all project members, including read-only Viewers. Restoring a version requires edit rights (project Admin or User); Viewers can see history but cannot roll back. Every restore is recorded in the audit log, annotated with which version it was restored from. See roles and permissions.