User acceptance testing should show that intended users can complete agreed business work—not merely that screens load or a technical build passes. Before launch, identify the version, business scenarios, test data, decision owners, and conditions that would stop release. The result should be a documented decision: ready, ready within explicitly accepted limits, or requiring correction and retesting.
This checklist is for organizations commissioning custom software. It is a proposed working approach, not a mandatory standard or a substitute for contract terms. Adapt it to the consequences of failure, the people who will use the system, and the scope of the release.
Distinguish acceptance from a product demonstration
A technical team checks system behavior against its design. Business users check whether the outcome supports their actual work. An order can save successfully while a salesperson cannot correct a returned order or a branch manager cannot obtain the right report.
Demonstrations usually follow a prepared route with clean data. Acceptance requires users to work under their own roles, follow defined scenarios, and compare actual outcomes with expectations. The official ISTQB overview of acceptance testing emphasizes collaboration among product owners, business analysts, and testers. The operational checklist below is an independent proposal for putting that collaboration into practice.
1. Name the version and scope
Record the release identifier, included capabilities, exclusions, and relevant configuration. If functionality changes during testing, identify which results need to be repeated. Otherwise the final approval may refer to several different versions without anyone noticing.
“The system must be complete” is not a useful acceptance criterion. Describe observable work: an authorized employee creates an order, the responsible person approves it, and the final status appears correctly in the report. Use a software RFP checklist to make those expectations explicit before comparing suppliers, rather than negotiating their meaning during handover.
2. Involve representatives of real roles
An executive's approval does not prove that each department can use the software. The person entering a request, the person approving it, and the person reconciling reports have different needs. Each important role needs representation. An administrator account is not a substitute because it can bypass restrictions that ordinary users encounter.
Separate recording a result from accepting a residual risk. A tester can report a failure; someone with appropriate business authority must own a decision to proceed despite it. Schedule user participation and escalation routes before the final week, so acceptance does not become an unowned activity squeezed between other duties.
3. Set entry conditions
Business users should not be the first people to discover a broken login or an unusable core form. The delivery team should have checked basic flows, prepared accounts and data, and supplied a short usage guide. Disclose known limitations instead of asking users to rediscover them.
The environment should resemble the target wherever configuration affects behavior. At the same time, prevent accidental real payments, customer notifications, or operational changes. Record simulated integrations clearly. A successful test against a simulated service is not evidence that the production connection works.
4. Write business scenarios, not button lists
“Click Save” describes an action, not an outcome. A better scenario is: a branch purchase request is rejected, corrected, and resubmitted for approval. Include the role, prerequisites, input data, steps, and expected result so another person can repeat it.
For important processes, cover the normal path and meaningful exceptions: missing information, cancellation, duplicate submission, interrupted connectivity, and resuming unfinished work. The goal is not a large test count. It is coverage of situations whose failure would matter to the business.
A usable scenario record
For a branch purchasing scenario, define a requester and approver belonging to the same branch. Create a request, reject it with a reason, change the quantity, and resubmit it. Expect the rejection history to remain, the new quantity to appear, and only the authorized approver to make the final decision.
Record the tested version, date, result, evidence, and defect reference. Use separate states for passed, failed, blocked, and not executed. Missing data that prevents a test from running must not be interpreted as a pass.
5. Use representative data
Short, tidy examples hide many problems. Include long names, mixed-language descriptions, boundary values, and records involving multiple departments. Use synthetic or appropriately de-identified information and restrict access according to sensitivity.
Where migration is involved, distinguish acceptance of workflow behavior from verification of transferred records. A form may work while balances or relationships are wrong. The data migration validation guide covers that separate evidence stream. Its result should inform the launch decision rather than disappear inside a generic testing status.
6. Check downstream outcomes and permissions
A success notification is not the end of a scenario. Confirm that the record can be found, that the next role sees the right state, and that reports include it correctly. Compare exports and printed output with the underlying input where those outputs are in scope. A polished report is not proof of correct totals or filtering.
Include negative permission checks: a user from another branch must not access a record simply by knowing its address. These checks do not replace specialist security testing, but they can reveal important mismatches with business expectations. Keep each type of assurance visible rather than claiming one replaces the other.
7. Agree on impact and priority
Severity describes the effect of a problem; priority describes when it should be addressed. A blocked core process, unauthorized disclosure, and damaged records are not equivalent to a minor spacing issue. Agree on categories before the release deadline, when schedule pressure can distort judgments.
For each defect, record reproduction steps, expected and actual results, version, and sufficient evidence. If a workaround exists, name its owner, workload, limitations, and intended duration. “We will do it manually for now” is not a dependable plan on its own.
8. Retest the correction
“The developer fixed it” and “the user verified the fix” are different states. Repeat the affected scenario on the corrected version. If the change touches shared calculations, authentication, or permissions, include related routes in regression checks.
Preserve the earlier result. A traceable history shows the original problem, the correction, and the evidence used to accept it. This is useful when an issue returns and avoids reopening arguments that have already been resolved with evidence.
9. Define exit criteria before time runs out
Reaching a deadline is not an acceptance criterion. Identify essential scenarios, release-blocking failures, and the conditions under which a remaining limitation can be accepted. A generic pass percentage is misleading if it treats a critical failed flow as equivalent to many cosmetic checks.
Summarize role coverage, critical scenarios, unexecuted tests, and open risks. If the launch is staged, define acceptance for that specific scope. Our phased software delivery guide discusses how to choose meaningful release boundaries; UAT provides evidence about whether the selected boundary is ready.
10. Combine business acceptance with operational readiness
Successful user testing alone does not prove deployment readiness. Training, support ownership, actual integrations, launch coordination, and a workable recovery approach need their own checks. They complement UAT rather than being silently assumed to have passed.
The final record should identify the accepted version and scope, critical results, limitations, outstanding owners, and release decision. Make conditional approval explicit and testable. Interpret payment or contractual consequences under the actual agreement; this checklist is not legal advice.
Example: an internal service-request system
Employees report equipment faults, supervisors assign priority, and technicians record outcomes. Test the complete normal journey, then rejection, reopening, reassignment, and unauthorized access. Reports must classify states correctly, not merely show the right total number of records.
Suppose a reopened request does not appear in the technician's queue. In an organization that relies on reopening, this blocks essential work and should not be dismissed as a small reporting issue. After correction, repeat the reopening scenario and the relevant queue filters. This is an illustrative scenario, not a claimed result from a customer deployment.
Decide from evidence
Useful acceptance connects a real role, a known version, an agreed task, and an observable result. Prepare critical scenarios early, classify problems by business impact, and verify corrections before closing them. Make the final decision understandable to all parties.
Discuss acceptance as early as features and timelines. With EasySaz custom software development, bring the workflow and intended delivery criteria into the initial project conversation so the expected outcome can be evaluated from the start.