Version history
The record of how a test case changed over time, who changed it, and the ability to view or restore an earlier version. It matters when a case starts failing and nobody remembers whether the product changed or the test did. Without it, a test case is a document with no accountability, and disputes about it are settled by recollection.
The question it answers
A case passed for months and now fails. Either the product changed or someone edited the steps or the expected result. With version history this takes a minute: open the case, compare the current version with the one that last passed, and see whether the expected result moved. Without it, the team asks around, and the person who made the edit may have left.
What a useful history records
Each saved change as its own numbered version, with author and time, and a diff that shows which fields changed. Restoring an older version should add a new entry to the history instead of erasing the later ones, so the trail stays complete even after a rollback.
Version history and execution history are different records
Execution history tracks what happened each time the case ran. Version history tracks the case itself. A result only means something against the version that was executed: a pass on last month's wording says little about this month's. When a pass rate shifts after a large edit to a suite, check the version history before blaming the build.
Limits to plan for
Tools keep a limited number of versions per case, so a case edited every sprint loses its oldest entries first. If an audit or a regulated process needs the full record for longer, export it on a schedule instead of relying on the tool's retention.
In QAM Hub
Version history is on Standard and Advanced. Every save creates a numbered version, Edit History shows the differences between versions, and any earlier version can be restored. The last 20 versions of each test case are kept. The steps are in version history and rollback.