Release worksheet
How to write a Golden Journey Test Contract
UxerProof Editorial · · 4 min read
A Golden Journey is the end-to-end task you most need to work for a particular release. The Test Contract makes that task precise enough to execute responsibly and review afterward. It connects the user's goal to permitted actions and an observable result.
Pick a task that represents the release promise
Start with the reason someone would use the product today. A task should cross the important handoffs needed for that outcome, rather than collecting unrelated screens into a long tour. For a fictional expense product, a suitable journey might be saving a draft expense with its attachment and reopening it for editing.
That journey can test a meaningful result without authorizing reimbursement or sending anything to a real approver. Where a multi-role handoff is essential, document the roles and allowed transitions separately. A single-role run cannot prove that all permissions and handoffs work.
Fill in the Test Contract worksheet
Copy these fields into your release record. The example is illustrative; replace its values with your authorized environment and actual acceptance criteria before use.
| Field | Illustrative entry |
|---|---|
| Decision owner | Named release owner who will review the evidence. |
| Target and authority | Owned staging environment; permission covers this exact task. |
| Version and starting state | Recorded release identifier; fresh test account; empty expense list. |
| Role and goal | Contributor saves a draft expense and reopens it. |
| Safe data | Synthetic expense details and a clearly marked test attachment. |
| Allowed actions | Create, edit and reopen drafts in the isolated test workspace. |
| Excluded actions | No real approvals, reimbursements, invitations or customer-record changes. |
| Success criteria | Correct draft and attachment visible after reload; editing remains possible. |
| Budget and stops | Team-defined time/action limits; stop at any unexpected external action. |
| Evidence and retention | Redacted step record; named reviewers; explicit expiry for raw artifacts. |
| Cleanup | Delete test drafts and revoke temporary access when the review ends. |
Make success more specific than a green toast
A success message is one piece of evidence. It does not by itself establish that work persisted or that the correct role can retrieve it. Add the check that closes the loop: reload, reopen the item and verify the fields needed for the task. Keep permission checks explicit and within the authorized test scope.
Playwright's guidance favors user-visible behavior and isolated tests. Those principles support this contract: start from a controlled state and verify the result someone can use. The broader release decision still needs any separate database, security or operational evidence required by your product.
The official guidance recommends checking user-visible behavior and isolating test state. Playwright: testing philosophy.
Record outcomes that preserve uncertainty
Use outcome language that tells the next reviewer what to do. These are suggested worksheet labels, not a claim that every testing tool implements the same statuses.
- Completed: the defined outcome has supporting evidence.
- Completed with friction: the outcome was reached, with recorded obstacles or repeated effort.
- Failed: evidence shows that an in-scope product behavior prevented the outcome.
- Blocked: a dependency, permission boundary or environment prevented a valid test.
- Not assessed: the run never evaluated this part of the task.
Close the loop with a reviewable decision
Attach the execution version, relevant observations, unresolved findings and reviewer identity to the decision. A conditional release should state the accepted limitation, its owner and when it must be revisited. If the journey failed, name the smallest repair and the rerun required to evaluate it.
Keep the contract version alongside the result. Changing the task after seeing a failure can hide the original problem. When a product change legitimately changes the journey, create a new contract version and explain why direct comparison with the old run may no longer be valid.
Put the evidence structure to work
Inspect UxerProof's fictional sample report, or use the free readiness check to prepare your next journey. External Circuit execution is not yet activated; see current launch status for availability.