On this page
Case versions and review
Every meaningful change to a test case is preserved as a version, and every case moves through a review workflow before it's trusted as "approved." Together, these keep your test history honest: what a test run actually checked, and who signed off on the case content, are always visible after the fact.
Version history
Every time a case's content changes — title, description, preconditions, steps, or priority — Proba.run saves a full snapshot as a new version. Changes that don't touch content, like re-tagging a case or adjusting its linked accounts, don't create a new version.
Open a case and go to its History tab to see the version list: newest first, each with its author and date, and the current one marked current.
Comparing versions
Click Compare with previous on any version to see a field-by-field and step-by-step diff against the version right before it. Version 1 has nothing to compare against, so this action isn't available there. Only adjacent versions can be compared directly — comparing two arbitrary versions isn't supported yet.
Viewing an old version
Click into any version to see a read-only snapshot of its content — title, description, preconditions, priority, and steps, with any shared step blocks expanded as they were at the time.
Restoring a version
If a change turns out to be a mistake, restore an earlier version (requires case-management permission). Restoring copies that version's content back into the case and creates a brand-new version on top of it — history is never rewritten or lost, so you can always see that a restore happened and what came before it. You can't restore the current version, since there's nothing to restore to.
Why test runs stay honest
When a case is added to a test run, that run's copy of the case is pinned to whatever version was current at that moment. Editing the case afterward never changes what an already-created run shows or records — the run continues to reflect the case exactly as it was when it was included, even years later.
Review workflow
A case moves through a small set of statuses as it matures:
| Status | Meaning |
|---|---|
| Draft | Work in progress, not yet reviewed. |
| In review | Submitted and waiting for a reviewer's decision. |
| Active | Approved and live — the default for new cases (review is optional, not forced). |
| Deprecated | No longer in use. |
Moving a case through review
- Submit for review (
draft → in review, or re-submit an active case): available to anyone who can manage cases. - Approve (
in review → active) or send back for rework (in review → draft): both require review permission — a separate right from general case editing, so an author submitting a case and a reviewer approving it can be different people. - Deprecate or bring back to draft/active: available to anyone who can manage cases.
Jumping straight between statuses outside this flow (for example draft directly to active without going through review) isn't allowed.
By default, project admins and managers hold review permission; testers don't, unless a custom role grants it. This split lets a QA lead or manager act as gatekeeper while testers write and submit cases.
Approval and content drift
Approving a case records who approved it, when, and exactly which version was approved — this shows up on the case as a line like Approved v3 · reviewer name · date. If the case is edited afterward (creating a new version), the case stays Active, but you'll see a "content changed since approval" indicator, since the approved snapshot no longer matches what's live. A reviewer can re-approve at any point by sending the case back through the review cycle.
Sending a case back for rework doesn't erase this approval history — you can still see who approved which earlier version.
Filtering by review status
The case list's status filter includes In review, so you can quickly see everything waiting on a decision.