“We clicked through it and it seemed fine” is a weak acceptance record for software that will run orders, approvals or customer accounts. User acceptance testing asks a more specific question: can the people who operate the business complete the agreed work, using realistic data and the permissions they will actually have?
Keep the business decision separate from the technical tests
Developers should test components, integrations, validation and error handling. Business users should not become a substitute for that work. Their acceptance testing checks whether the delivered workflow meets the agreed operational requirement.
Microsoft's overview of test types distinguishes user acceptance from functional, integration and regression testing. Its product context is Dynamics 365; the distinction is also useful when writing an acceptance plan for a bespoke system.
A sample acceptance record
The following example concerns an invented ordering portal. It is a template for specifying expected behaviour, not a claim about a particular client or a completed test.
| Requirement | An order above the agreed limit needs manager approval before fulfilment. |
|---|---|
| Starting state | An active customer, available stock and a staff account without approval rights. |
| Action | The staff member submits an order above the limit. |
| Expected result | The order is pending, stock treatment matches the agreed rule, and no fulfilment request is sent yet. |
| Next action | An authorised manager approves it. |
| Evidence | Order ID, recorded status changes, approval actor and the expected downstream event. |
The boundary matters: test an amount below the limit, exactly at it and above it. Confirm which currency and tax basis the rule uses. Those details often expose different interpretations before release.
Choose scenarios from a real working day
The ordinary path
Begin with the common task from start to finish, including handoffs. For an order, that may include entry, approval, allocation, notification and reporting. A collection of attractive screens is not evidence that the complete process works.
The exception people already know about
Ask staff what causes rework today. Test an unavailable item, duplicate request, missing reference, cancellation or interrupted connection. Decide what the user should see and who owns recovery. Use safe test data and sandbox integrations; do not send real customer notifications to prove a test case.
The permission boundary
Repeat important actions with different roles. Can a staff user approve their own restricted action? Can one customer open another customer's record by changing a URL? Authorisation needs technical tests as well as business review; a menu item being hidden is not sufficient evidence.
Record the outcome while it is reproducible
For a failure, capture the environment, build or release version, account role, starting data, steps, expected result and actual result. Screenshots can help, but keep private information out of broadly shared tickets. Record an identifier that an authorised developer can use to inspect the right test record.
Separate severity from inconvenience. A cosmetic spacing issue differs from duplicate billing, lost records or cross-customer access. Agree release blockers before testing so the go/no-go meeting does not become a negotiation about what “finished” means.
Retest the fix and its neighbours
When a defect is corrected, rerun the failed case against the new version. Then check nearby workflows that share the changed rule. Fixing the approval threshold might affect refunds or reporting; the relevant regression checks should follow the dependency.
Keep an acceptance log with passed cases, open defects, agreed exclusions and named sign-off. Approval should describe the tested scope. It should not silently expand to features, data imports or integrations nobody exercised.
Separate acceptance from a specialist assurance claim
Passing these business scenarios does not certify security, accessibility, load capacity or legal compliance. Assign those checks separately where required. At sign-off, record the release version, environments, tested roles and any accepted limitation so approval cannot be mistaken for assurance about untested areas.
Bring the proposed cases into software discovery before development starts. They make a written scope testable, and they give the first release a more useful boundary than an unqualified promise to “test everything”.
