Client reports and sign-off
Turn a published plan version and its runs into a shareable, hashed report a client signs — with their name on it, not an email thread.
Most teams end an engagement with a spreadsheet and a "looks good to me" in email. That is fine right up until somebody asks, four months later, which build was accepted and on what basis. A report with a content hash and a named approval answers that in one line.
Build the report
Publish the plan version the engagement was tested against. A report is built from a published version — a draft has nothing stable to report on.
Open Reports for the project and choose New report, then select that version.
Pick which runs to include. The report assembles the scope, what changed since the previous version, coverage by feature, results by execution mode, the evidence behind each pass, open bugs and verified fixes.
Write the narrative section. This is the part a person should write: what was in scope, what was deliberately not tested, and what the client should know.
Check the manual section. The report states which cases were manual and why, quoting the reason codes. Leaving that honest is what makes the rest credible.
Publish and share
Choose Publish. The report gets a slug and a public URL of the form
/r/<slug>.Add a password if the contents are sensitive, and an expiry if the link should stop working after the engagement.
Apply your branding under white-label settings — logo, colours, and a verified custom domain if you have one configured.
Export a PDF or CSV if the client wants a file. The PDF footer prints the content hash.
Send the link. Open it yourself in a private window first — that is exactly what the client will see.
The content hash
The hash is a SHA-256 over the report's canonical content: object keys sorted, array order preserved, and every timestamp excluded — both keys that name a time and any date value wherever it appears. Assembly metadata such as when the report was generated is excluded too, because that is a fact about the builder, not about the report.
The practical consequence: build the same report twice, a second apart or on two machines, and the hash is identical. Change a result, a pinned revision, an evidence artifact or a sentence of the narrative, and it moves. "I approved this" is therefore a checkable statement rather than a hopeful one.
Sign-off
The client opens the link, reads the report, and chooses Approve or Request changes. Approving records their name, email, the statement they agreed to, the timestamp, and the content hash of exactly what was on the page.
| State | What it means | What can happen next |
|---|---|---|
PENDING | Published, nobody has signed. | Approve, or request changes. |
CHANGES_REQUESTED | A reviewer asked for changes. The report reopens and stays editable. | Fix it; a later approver can still approve the corrected content. |
APPROVED | Signed. Terminal and immutable. | Nothing. A change creates a new report. |
From an agent
create_test_report build the report for a PUBLISHED plan version and its runs;
returns the share URL and the content hash
get_report_status publication, expiry, hash and the sign-off state
(approved / changes requested / pending) with its approversCommon questions
Does the client need an account?
No. The report is a public page at its own link, with an optional password and expiry. Signing needs no sign-in either.
Can I edit a report after it has been signed?
No. APPROVED is terminal and immutable. A change after sign-off creates a new report, which is exactly what the client was promised.
What does the content hash actually cover?
The report's content and nothing else — keys sorted, timestamps excluded entirely — so two builds of the same report hash identically and any real change moves it.
What if the client wants changes?
They choose "request changes". That reopens the report so it stays editable, and a later approver can still approve the corrected content.
Is this a regulated e-signature?
No, and it does not claim to be. It is a named approval record — who, when, with which statement, against which hash — not a 21 CFR Part 11 workflow.
Related articles
- Test plans and versionsPublish a frozen v1 of your test plan, edit freely afterwards, and diff v1 against v2 when the next release ships.
- 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.
- Assign manual test cases to testersDistribute the manual half of a plan across your team by load and area affinity — and re-run it safely without reshuffling anyone's queue.
- Run a manual test with the extensionTest Run mode records replay, console, network and a screenshot per step while you work — the same evidence a CI run produces.