Test plans and versions
Publish a frozen v1 of your test plan, edit freely afterwards, and diff v1 against v2 when the next release ships.
Most test tools store one mutable copy of each test case. Six months after a release, nobody can say what the case said at the time, which makes "we tested this" an assertion rather than a record. BugMojo keeps three separate things instead: the case as it is now, every version of it that ever existed, and the plan that pinned specific versions for a specific release.
Revisions: the history of one case
Every write to a test case — from the case editor, from the review queue, or from an AI agent over MCP — creates revision N+1. A revision is a complete snapshot, never a delta: fields you did not touch are copied forward, so any single revision can be read on its own.
Revisions record the steps, the expected result, preconditions, the execution mode and its reasons, and the Playwright spec or Maestro flow attached to the case. They also record who wrote them — a member or an agent — and which generation session the change belonged to.
Versions: the plan you agreed to
A plan version is a document, not just a list of cases. It carries the scope, entry and exit criteria, the environments it applies to, the known risks, and an ordered list of cases each pinned at one revision.
While the version is a DRAFT, it follows your edits: editing a pinned case re-points the draft at the new revision automatically. The moment you publish, it stops moving.
Publish a version
Open Test Plans for the project and choose the plan. The rail shows the current version and any draft.
Review the scope, entry and exit criteria, environments and risks on the draft. These are part of what gets frozen.
Check the case list. Each row shows the mode, the readiness score and the revision it is pinned at.
Choose Publish. BugMojo re-pins every case at its current revision, computes the content hash, assigns the next published number and marks the version approved — all in one transaction.
Keep editing cases afterwards. They move on to new revisions; the published version keeps what it froze.
Publishing is idempotent. Re-publishing a version that is already frozen returns it unchanged and writes nothing — including no new hash, no renumbering and no second approval record. An audit log row is still written, because "who tried to re-freeze v1" is a question worth being able to answer.
The diff: what changed between v1 and v2
Open any two versions of the same plan and BugMojo renders the difference: cases added, cases removed, cases reordered, and for each case that survived both versions, the field and step-level changes between the revisions each version pinned.
This is the section clients and release managers read first. It answers "what is different about the testing this time?" without anybody reconstructing it from memory.
Runs bind to a version
When a run executes a published plan version, each result binds to the revision that version pinned. When it does not, the result binds to the case's current revision. Either way the result names the exact text that was executed, which is why a result from March still means something in September.
Doing this from an agent
The same operations are available over MCP, so a coding agent can build and publish a plan without a person clicking through the dashboard. See the MCP tool reference for the full surface.
list_test_plans plans with their current version
get_test_plan_version a version with every case AT the revision it pinned
create_test_plan_version the next DRAFT; publish=true freezes it with a hash
diff_plan_versions v1 → v2, added / removed / reordered / step-levelCommon questions
Can I edit a case after the version is published?
Yes. The case moves on to a new revision and the published version keeps the revision it froze. Publish a new version when you want the plan to catch up.
Does restoring an old revision delete the newer ones?
No. Restore rolls <em>forward</em>: it writes a new revision whose content equals the one you restored. History is never mutated or deleted.
Why does my draft version show a different number after publishing?
Draft numbers are provisional. Publishing assigns the next sequential published number, so a draft created before someone else published can shift.
Is versioning limited to a paid plan?
No. Plans, versions, the diff and the review queue are on every plan including Free. Test authoring is gated on your role, never on your tier.
Related articles
- Review agent-proposed test casesAccept, edit or reject every case an AI agent proposes — and watch the acceptance rate to tell whether generation is getting better.
- Manual vs automated: modes and reason codesEvery case gets a mode, a readiness score from 0 to 100, and named reason codes explaining exactly what is blocking automation.
- Client reports and sign-offTurn a published plan version and its runs into a shareable, hashed report a client signs — with their name on it, not an email thread.
- Evidence: what gets captured and whyNine artifact kinds, hashed, tied to one result and one commit — and identical whether a machine or a person produced the run.