User Acceptance Testing for Business Software: Acceptance Criteria and a Practical Sign-Off Framework
How to write acceptance criteria that prevent scope disputes and run user acceptance testing: entry and exit criteria, defect severity and sign-off.
How should businesses run acceptance testing?
Write acceptance criteria for each requirement before development, in testable form; turn them into UAT scenarios that real users run in a staging environment with realistic data; triage defects by severity and separate them from change requests; and sign off against agreed exit criteria. Tie acceptance to the contract so payment milestones and warranty periods follow clear evidence.
This guide is for product owners and operations leads accepting software from internal teams or suppliers.
Key takeaways
- Agree acceptance criteria before work starts.
- Test with real users, realistic data and real workflows.
- Define entry and exit criteria for UAT.
- Classify defects by severity; log changes separately.
- Record sign-off with scope, date and named approver.
Writing acceptance criteria
Good criteria describe behaviour, not implementation, and cover rules and exceptions.
- One behaviour per criterion; avoid vague words like fast or user-friendly without a measure.
- Include permissions, validation and error cases.
- Include non-functional criteria where they matter (performance, accessibility).
- Review criteria with the people who will test.
Requirement: Trade customers can reorder from past orders
Given a signed-in trade customer with at least one past order
When they choose "Reorder" on an order
Then the basket contains the same products and quantities
And products no longer sold are listed as unavailable, not added
And current contract prices apply, not the original pricesPlanning UAT
| Element | What to define |
|---|---|
| Scope | Features and workflows in this release; what is out |
| Entry criteria | QA complete, environment stable, test data ready, known issues listed |
| Scenarios | End-to-end business tasks built from the acceptance criteria |
| Testers and time | Named users with time blocked in calendars |
| Environment and data | Production-like staging, anonymised or synthetic data |
| Exit criteria | Scenarios passed; no open critical or high defects; workarounds agreed |
| Sign-off | Who approves, in what form, and what it triggers |
Defects versus change requests
| Severity | Meaning | Release impact |
|---|---|---|
| Critical | Blocks a core task or risks data loss or security | Must fix before go-live |
| High | Major function wrong, no reasonable workaround | Fix before go-live or agree a dated workaround |
| Medium | Function wrong with a workaround | Can go live with a fix plan |
| Low | Cosmetic or minor | Backlog |
| Change request | Works as agreed, but the business wants something different | Estimate and prioritise separately |
Linking acceptance to the contract
Contracts should define acceptance criteria per release, a testing window, how defects are classified, and what sign-off triggers (payment, warranty start, go-live). Deemed acceptance after a period without feedback protects suppliers; clear exit criteria protect buyers. See custom software development in the UK for other contract points.
Hypothetical example: a wholesaler's trade portal
This example is hypothetical. A wholesaler accepting a new trade portal wrote acceptance criteria with its sales and customer service teams during discovery. UAT ran for two weeks with six internal users and three friendly customers on staging with anonymised data. Of 41 issues logged, 9 were reclassified as change requests. Sign-off recorded two medium defects with fix dates, and go-live triggered the warranty period.
Common mistakes
- Writing criteria after development.
- UAT by the development team instead of users.
- Unrealistic or empty test data.
- Treating every request as a defect.
- Sign-off by email with no record of scope.
Conclusion
Acceptance criteria and a disciplined UAT turn go-live decisions into evidence rather than opinion, and keep scope discussions fair. Agree criteria early, test with real users, separate defects from changes and record sign-off. For automated checks between releases, see automated regression testing.
Preparing to accept a new system?
ZSpace Labs is a remote-first technology studio that works with clients globally on business applications and mobile apps, with acceptance criteria agreed up front. If it would help to plan acceptance for your project, we are happy to talk it through.
Common questions.
Testing by the business users or client, in a realistic environment, to confirm the software supports their work and meets the agreed acceptance criteria before it goes live. It complements developer and QA testing rather than replacing it.