Agree the test before the build. Here is how a project can produce useful acceptance evidence before anyone calls it ready.
Not just a good demo.
A test should reflect the work and the people who will rely on it. The evaluation method belongs in the scope, not in a post-launch footnote.
01
Define the acceptance decision
Choose representative work, important failure modes, and a named reviewer. Agree what must be correct, what may be uncertain, and what should cause the workflow to stop.
02
Record a baseline
Use the current process or system as the starting point. Document the inputs, source versions, manual checks, quality expectations, and any measurement limitations.
03
Compare on the same work
Use normal cases and exceptions. Keep inputs and scoring criteria consistent across candidates. Include missing data, stale information, repeated submissions, and requests outside the permitted scope.
04
Keep an inspectable evidence pack
Retain appropriate test inputs, expected behavior, observed output, sources, failures, and reviewer decisions under agreed data-handling terms. Separate a demonstration from a production test.
05
Make an explicit go / revise / stop decision
A successful demonstration does not authorize a deployment. Review unresolved defects and operational readiness, agree monitoring and fallback, and obtain the owner’s launch approval.
An acceptance check
Make “works” specific enough to check.
An invoice workflow is a useful example. The record should connect the expected behavior to evidence and a reviewer’s decision.
Case
The same invoice arrives twice.
Expected behavior
Flag the likely duplicate. Do not create a second approved record.
Evidence to collect
The source reference, matching rule, proposed output, and exception trail.
Acceptance owner
The designated finance reviewer for the engagement.
Inspect a working example.
Follow a duplicate-invoice check from extracted fields to a review decision. The synthetic inputs, comparison rules, results, and runnable example are all available.
A fictional test invoice states net 100, tax 20, and total 120 in the same currency. The fixture set also contains a second copy of that invoice and a scan with an unreadable invoice number.
Expected behavior
Prepare the stated fields with source references, flag the second copy as a duplicate candidate, and hold the unreadable number for review. The output is a draft finance record.
What to check
Compare every required field with a reviewer-prepared reference record. Check that 100 plus 20 reconciles to 120, the duplicate is held for review, and the missing number stays unresolved. Verify that rerunning the same accepted input does not create another destination record.
Scope and limits
Agree the required field checks and duplicate rules for the actual source system. Invoice approval, accounting treatment, and payment remain separate authorized decisions.
Illustrative test design
Company knowledge search
Test input
A fictional knowledge set contains a current travel policy, a superseded version, and a document restricted to a different user group. The questions include a covered expense, an exception absent from the policy, and a request for the restricted document.
Expected behavior
Answer the covered question with the current source and passage. State that the exception is not established by the available guidance and direct it to the policy owner. Do not reveal information from the restricted document.
What to check
Check the cited version and whether the passage supports the answer. Verify the unsupported question is escalated and repeat the permission test with accounts from each relevant user group. A correct answer for one account does not establish access behavior for another.
Scope and limits
Source changes, user permissions, and model updates require ongoing checks under an identified owner.
Take the acceptance worksheet
Write down the normal case, the failure case, and the evidence a reviewer needs. Use the same record for the current process and the candidate.
Free to download. No email required. Keep credentials and confidential records out of an initial brief.
The ones that fit the task: for example, correctness, completeness, harmful actions, review burden, latency, or cost per completed task. Thresholds are agreed for the project.
Does passing tests mean a system cannot fail?+
No. Tests cover the cases examined. Monitoring, human review, and a recovery plan are still needed for real operation.
A useful conversation starts here
Where does the work get stuck?
Describe the result you would need to trust. That is a useful place to start defining acceptance.
