A polished demo does not prove that your team can run the business with the new software. User acceptance testing, or UAT, asks a more specific question: can the intended users complete agreed business tasks using the release you are about to approve?
This checklist helps a small-business owner turn “looks good” into documented acceptance. The example is a hypothetical quote-request system, not a client case study. Adapt the scenarios to your own processes and the scope agreed with your development partner.
Write the outcome first. For a quote workflow, it might be: a customer submits a valid request, the right sales team receives it, an authorized employee updates its status, and another authorized employee can find the record later. A screen that loads is only one part of that outcome.
For each task, name the user role and the starting point. Write down the test data, expected result and proof to save. Atlassian’s UAT template provides a reference for organizing criteria and results. Your business still needs to define what a passing result actually means.
Do not send test payments, messages or exports to real customers. If a third-party service cannot be safely exercised in the test environment, record the limitation and the controlled production check required. An untested integration should not silently become a “pass.”
| Scenario | Expected business result | Evidence to retain |
|---|---|---|
| Valid quote request | One request stored with the supplied details and assigned to the agreed team | Request reference and assignment record |
| Missing required information | Clear correction guidance; incomplete request not treated as ready | Validation screenshot and storage check |
| Mobile submission | User completes the same task without inaccessible controls | Device/browser and observed outcome |
| Unauthorized user opens request | Access follows the agreed role policy | Role used and access result |
| Employee changes status | New state appears where the team expects and required history is retained | Before/after state and audit record |
| Notification fails | Request remains recoverable and the responsible person can identify the failure | Failure record and recovery action |
| User repeats submission | Behavior follows your agreed duplicate-submission rule | Record count and references |
Do not assume repeated submissions must always be merged. Your business may need two legitimate requests from the same customer. Agree the rule, then test that rule rather than asking a tester to improvise it.
“The form is broken” is difficult to act on. Give each defect a clear record. Include the test ID, release version, role and steps. Add the test data reference, expected result, actual result and effect on the business. Link screenshots without exposing private data.
Distinguish a blocked test from a failed test. A tester who cannot access the environment has not proven the feature fails; the result is blocked until access is resolved. Likewise, “not tested” should remain visible instead of being counted as accepted.
Prioritize by impact. A task that loses requests or exposes restricted records may block launch. A minor visual issue may be accepted with an owner and a target fix date. These are business decisions, not universal severity rules.
After a developer marks a defect fixed, rerun the original scenario on the new release. Keep the new evidence attached to the defect. Check connected steps as well: fixing assignment should not silently break notifications or permissions.
Ask your partner to explain the distinction between its technical testing and your business acceptance. Our custom software process guide gives broader project context; this worksheet is the final-use check, not a replacement for engineering tests.
Record the release and environment; scenarios passed, failed, blocked and not tested; unresolved defects; accepted limitations and their owners; any required production checks; and the name and date of the business decision owner.
Choose an explicit outcome: approved, approved with documented conditions, or not approved. Do not use silence as acceptance. If you approve with conditions, name the open issue and why you accept it. State the temporary workaround and when you will review the decision.
Keep the results where your team and partner can retrieve them after launch. Techfusion Gear can help define business workflows and acceptance checks during a software project discussion, without replacing the customer’s approval decision.
People who understand the real business tasks should test representative workflows. A coordinator can organize results, while a named business owner makes the acceptance decision.
No. Developer testing checks technical behavior; UAT checks agreed business use. Both are needed, and neither should be used to hide an untested release.