>_ UAT Test Cases: Examples and a Reusable Template

Short answer

UAT test cases are repeatable checks that business users perform to confirm that a system supports an agreed business requirement. Each case identifies the user role, starting conditions, test data, actions, and observable business result needed to make an acceptance decision.

A useful case goes beyond "the button works." For example, a manager approves a request, the request moves to the agreed status, and the employee receives the correct decision. The result must be specific enough for another participant to repeat the test and reach the same conclusion.

This guide provides a reusable UAT test case template and 10 filled examples. For organizing the whole acceptance phase, use the User Acceptance Testing Checklist. For deciding whether the phase can start or close, use the UAT Entry and Exit Criteria Checklist.

Acceptance criteria, UAT scenarios, and test cases

These describe different levels of the same business requirement:

• Acceptance criterion: A condition the solution must satisfy, such as "a submitted leave request appears in the assigned manager's pending queue."
• UAT scenario: A business task to investigate, such as "an employee requests leave and receives a manager's decision."
• UAT test case: One repeatable example with a named role, known data, steps, and expected results, such as submitting a three-day request and checking the assigned manager's queue.

A scenario can need several cases. Submitting, approving, rejecting, and correcting a leave request each exercise a different outcome. A single happy-path case does not establish that every acceptance criterion for the scenario is satisfied.

The ISTQB Acceptance Testing syllabus describes deriving acceptance tests from acceptance criteria and maintaining traceability between requirements and tests. In practice, give each case a criterion ID or a requirement link so the business reviewer can see what its result establishes.

When to prepare UAT test cases

Prepare cases when stakeholders need to accept a changed business workflow: a CRM rollout, an approval process, a reporting feature, a customer portal, or a migration that affects daily work.

Draft them while the business rules are being agreed. Review the expected results with someone who owns the workflow before asking participants to execute them. Run them when the relevant build, environment, users, and data meet the agreed entry criteria.

Revisit affected cases when a requirement changes. Keep the case version used for each run so a later result can be interpreted against the correct business rule.

Quick UAT test case readiness checklist

Before handing cases to participants, check that:

• every critical acceptance criterion is covered by at least one case;
• each case names the business role that performs the task;
• the required starting status and configuration are available;
• participants can find or create the specified test records;
• test data includes the boundary or exception the case is intended to exercise;
• steps can be followed without undocumented help from the author;
• the expected result names a business state, record, value, or recipient that can be checked;
• multi-person workflows identify who performs the handoff and the next action;
• the assigned business reviewer has agreed with the expected result;
• participants have a place to record actual results and supporting evidence;
• each case can be repeated with fresh or restored data;
• a blocked test can be recorded separately from an observed failure.

Reusable UAT test case template

Copy the following field structure into your test management tool, ticket, document, or spreadsheet. Replace the field guidance with the values for one concrete case.

• Case ID and title: Give the case a stable ID and name the business outcome being tested.
• Requirement or acceptance criterion: Link the rule this case verifies, including its version when it has changed.
• Business role and reviewer: Identify the participant who performs the task and the business owner who reviews the result.
• Preconditions: Specify the starting record status, user setup, and dependencies needed before the first action.
• Test data: Name the records, values, and expected recipients needed to repeat the case.
• Steps: Write the actions in execution order; separate actions performed by different roles.
• Expected result: State the observable result and the business rule used to judge it.
• Actual result: Record what happened, including the value or state that differed from the expectation.
• Status: Use agreed labels such as Not run, Passed, Failed, or Blocked.
• Evidence and issue link: Attach the record ID, screenshot, output, or defect needed to review the result.
• Run context: Record the participant, execution date, environment, build, and case version.

The Microsoft Learn guidance on defining test cases identifies requirements, prerequisites, reproduction steps, and expected outcomes as core elements for Dynamics 365 implementation tests. The template above adds execution fields so a business reviewer can understand the result of a particular run.

Include a timing target only when it is part of an agreed criterion. "The notification arrives within the agreed five-minute window" can be evaluated; "the notification arrives quickly" cannot.

How to turn an acceptance criterion into a test case

Start with one rule, then choose data that makes its outcome unambiguous.

Suppose the agreed rule is: "A purchase request with a total above 500 requires finance approval after line-manager approval. A total of 500 or below requires only line-manager approval."

1. Identify the participating roles: requester, line manager, and finance approver.
2. Choose one value on each side of the rule and one at the boundary: 499, 500, and 501.
3. Create a separate request for each value, with all other routing conditions held constant.
4. Describe the submission and approval steps for each role.
5. State the required next status and approval queue for each value.
6. Link the cases to the rule and agree on evidence with the reviewer.

Do not copy the threshold into another project without confirming its policy. The test design can be reused; the business values and expected outcomes belong to the system being accepted.

UAT test case examples for business workflows

The following cases are illustrative examples using synthetic records and explicitly defined business rules. Adapt the rules, role names, data, and evidence to your approved requirements. Run each case in the agreed UAT environment with fresh or restored records.

1. Create and assign a sales lead

• Case ID: UAT-01.
• Acceptance criterion: A lead for the West region is assigned to the West sales queue and can be picked up by a regional sales representative.
• Business role: Sales coordinator; West sales representative. Reviewer: Sales operations owner.
• Preconditions: West routing is configured and the regional representative belongs to the West sales queue.
• Test data: A new synthetic lead named West Demo Lead, with region West and no existing matching record.
• Steps: The coordinator creates and saves the lead. The representative opens the West queue, finds the lead, claims it, and moves it to Qualified.
• Expected result: One lead exists, it reaches the West queue, and the representative becomes its owner. The saved status is Qualified and remains so after reopening the record.
• Evidence: Lead ID, queue assignment, final owner, and final status.

2. Return an incomplete request for correction

• Case ID: UAT-02.
• Acceptance criterion: A service request needs a service category before submission. Correcting the missing category allows the same draft to be submitted without losing entered details.
• Business role: Service requester. Reviewer: Service operations owner.
• Preconditions: A requester can create a draft and the category is required by the agreed submission rule.
• Test data: A draft titled Demo equipment issue, with a description and location entered but no category selected.
• Steps: Attempt to submit the draft. Read the reported problem, choose Equipment as the category, and submit again. Reopen the submitted request.
• Expected result: The first attempt leaves the request in Draft and identifies the missing category. The second attempt creates one submitted request containing the original description and location plus the selected category.
• Evidence: The validation message, request ID, submitted status, and retained field values.

3. Approve a leave request

• Case ID: UAT-03.
• Acceptance criterion: A submitted leave request is sent to the employee's assigned manager. Approval updates the request to Approved and shows that decision to the employee.
• Business role: Employee; assigned manager. Reviewer: HR process owner.
• Preconditions: The employee has an assigned manager and sufficient leave balance under the configured policy.
• Test data: A fresh three-working-day request in a period without conflicting leave or holidays in the test calendar.
• Steps: The employee submits the request. The manager opens the pending queue and approves it. The employee reopens the request.
• Expected result: The request reaches the assigned manager, disappears from the pending queue after approval, and appears as Approved for the employee with the chosen dates intact.
• Evidence: Request ID, requested dates, assigned manager, and final status visible to both participants.

4. Route a request at an approval threshold

• Case ID: UAT-04.
• Acceptance criterion: A purchase total above 500 needs finance approval after line-manager approval; a total of 500 or below does not. Both values use the same configured currency.
• Business role: Requester; line manager; finance approver. Reviewer: Procurement owner.
• Preconditions: The agreed threshold is configured and no other approval condition applies to these requests.
• Test data: Two fresh requests with final totals of 500 and 501, created for the same requester and cost center.
• Steps: Submit both requests and have the line manager approve each. Inspect the resulting statuses and finance queue. Have the finance approver approve the 501 request.
• Expected result: The 500 request becomes Approved after line-manager approval and creates no finance approval task. The 501 request waits for finance approval, then becomes Approved after that decision.
• Evidence: Both request IDs, totals, approval history, intermediate statuses, and final decisions.

5. Reject, revise, and resubmit a request

• Case ID: UAT-05.
• Acceptance criterion: An approver can return a request with a reason. The requester can edit and resubmit the same record, and the previous decision remains available in its history.
• Business role: Requester; approver. Reviewer: Workflow owner.
• Preconditions: A submitted request is awaiting the approver's decision and the workflow supports revision after return.
• Test data: A request with a missing business justification; return reason: Add the project justification.
• Steps: The approver returns the request with the reason. The requester reads it, adds the justification, and resubmits. The approver opens the revised request.
• Expected result: The requester sees the return reason and can update the request. Resubmission keeps the original record ID, sends the revised version for approval, and preserves the earlier return decision in history.
• Evidence: Request ID, return reason, updated justification, approval queue entry, and decision history.

6. Filter a business report

• Case ID: UAT-06.
• Acceptance criterion: An operations report filtered by region and status includes only records matching both selections, and its total is calculated from that filtered set.
• Business role: Operations analyst. Reviewer: Reporting owner.
• Preconditions: The four test records are saved and available in the report; no other records match the chosen test scope.
• Test data: West/Open records valued at 100 and 200, a West/Closed record valued at 300, and an East/Open record valued at 400.
• Steps: Open the report and set region to West and status to Open. Inspect the record list, count, and total.
• Expected result: Only the two West/Open records appear. The count is 2 and the total is 300; the other two records contribute neither rows nor value.
• Evidence: Active filters, displayed record IDs, count, and total.

7. Export the filtered report

• Case ID: UAT-07.
• Acceptance criterion: CSV export contains all records in the filtered result, including records beyond the visible page, and uses the agreed column order.
• Business role: Operations analyst. Reviewer: Reporting owner.
• Preconditions: The report displays 20 rows per page, the test scope contains exactly 25 matching records, and the export rule covers the full filtered result.
• Test data: Twenty-five West/Open records and five East/Open records; required columns: Record ID, Region, Status, Amount.
• Steps: Filter to West and Open. Confirm the result count, export from the first page, and open the CSV in the tool the business uses.
• Expected result: The export has the four agreed columns and 25 data rows, with every matching record appearing once. No East record appears, and amounts match the source records.
• Evidence: Filters, result count, export file, and comparison of exported IDs and amounts with the source records.

8. Handle a report with no matching records

• Case ID: UAT-08.
• Acceptance criterion: An empty report identifies the active filters, shows a zero count and total, and lets the analyst change the filters to continue working.
• Business role: Operations analyst. Reviewer: Reporting owner.
• Preconditions: West records exist in the test scope, but no North records exist.
• Test data: Region North with status Open for the empty result; region West with status Open for recovery.
• Steps: Filter to North and Open. Review the result, then change the region to West.
• Expected result: The North result clearly shows no matches, count 0, and total 0 rather than values retained from a previous query. Changing to West displays the matching records without restarting the report.
• Evidence: The empty-state message and totals, followed by the active West filters and returned records.

9. Notify the requester of an approval decision

• Case ID: UAT-09.
• Acceptance criterion: Approval sends one decision notification to the requester within the agreed five-minute window. It includes the request reference, decision, and a link to that request.
• Business role: Approver; requester. Reviewer: Workflow owner.
• Preconditions: A fresh request is pending approval, the configured notification channel is available, and the requester can read its test inbox.
• Test data: A pending request with a known reference and a designated test recipient.
• Steps: Approve the request and record the decision time. The requester checks the test inbox within five minutes, reads the message, and follows the request link.
• Expected result: One notification reaches the designated requester within the agreed window. The reference and Approved decision match the saved record, and the link opens that same request for the requester.
• Evidence: Request reference, decision time, received time, recipient, message content, and link destination.

10. Recover after an interrupted submission

• Case ID: UAT-10.
• Acceptance criterion: After a submission is accepted but its confirmation is interrupted, the requester can recover and find exactly one submitted request with the entered details.
• Business role: Service requester. Reviewer: Service operations owner.
• Preconditions: The UAT team has a controlled way to interrupt confirmation after saving, and the agreed recovery instructions tell the requester how to check the outcome before retrying.
• Test data: A fresh draft with a unique reference Demo recovery request and complete required fields.
• Steps: Submit the draft while the facilitator triggers the agreed interruption. Follow the recovery instructions, reopen the request list, and check the record. If the instructions require retrying, perform that retry and inspect the list again.
• Expected result: The requester can identify the submission outcome and continue working. Exactly one request exists with the correct data and Submitted status, including after any prescribed retry.
• Evidence: Draft reference, saved request ID, interruption observed by the participant, recovery actions, and final record count.

Review coverage and record execution results

Use the cases as a starting structure, then map them to your own requirements. Ten examples do not establish coverage for an unrelated system.

Before execution, review that:

• each in-scope critical criterion has a named case and business reviewer;
• boundary values come from the actual policy being accepted;
• positive, rejection, empty, and recovery outcomes are covered where the workflow needs them;
• participants and downstream users can perform the required handoffs;
• expected values can be calculated independently of the output under test;
• each case identifies how to reset its data or create a fresh record for retesting.

During execution, record the actual outcome before assigning a status. A screenshot of an open report does not establish that its filters or total are correct.

For a mismatch, record the affected case, expected value, actual value, and business impact. For a blocked case, name the missing prerequisite. Keep suggestions for new behavior separate from failures against an agreed criterion.

After a fix, repeat the affected case with suitable data and retain the earlier result. Case results become evidence for the agreed exit review; a collection of Passed labels does not itself replace the business acceptance decision.

Common mistakes

1. Copying examples without adapting the business rules

An approval threshold, notification deadline, or report total from another system can produce a convincing but irrelevant test. Confirm the rule and data with the workflow owner before execution.

2. Naming a scenario but omitting an expected result

"Test the approval workflow" gives participants a task but no basis for acceptance. State the required approver, next status, and information visible to the requester.

3. Checking only the first participant's screen

A request can look submitted while never reaching the approver. Include the handoff and the downstream business result when they are part of the criterion.

4. Using the application to calculate its own expected value

Copying a report's displayed total into the expected result can hide the defect being tested. Calculate the expectation from known records or another agreed source.

5. Reusing records that no longer meet the preconditions

An already approved request cannot establish whether initial submission routes correctly. Restore the starting state or create a fresh record, and record the new ID.

6. Treating a blocked case as passed or failed

An unavailable test inbox may prevent a participant from checking a notification. Record the blocker and resolve it; do not infer the notification outcome without evidence.

FAQ

What should a UAT test case include?

Include the business requirement, participant role, preconditions, data, actions, and expected result. For an executed case, also record the actual result, status, evidence, environment, build, and execution date. Add fields that help the reviewer understand the outcome rather than copying every field from a technical test template.

Who writes and reviews UAT test cases?

QA or a business analyst can draft and organize the cases. Business users and process owners should review the rules, terminology, and expected outcomes. The people performing the test need enough context to execute it; the person accepting the result needs the authority agreed for that business area.

How many UAT test cases are needed?

There is no useful fixed count for every project. Start with critical requirements, roles, and end-to-end workflows, then add cases for materially different rules, boundaries, and exception outcomes. Review uncovered criteria and business risks instead of treating the number of cases as evidence of completeness.

Can functional QA test cases be reused for UAT?

Yes, when they establish a relevant business outcome and a business participant can execute and judge them. Rewrite technical setup and expected results where needed. A field-validation case may support UAT, but it does not replace checking that the completed request reaches the next person and supports the agreed workflow.

Is Given, When, Then required for UAT test cases?

No. It is one possible way to structure a case: Given describes the starting conditions, When describes an action, and Then states an observable result. Plain steps and expected results are also usable. Choose a format participants can follow and reviewers can trace to the acceptance criterion.

What if the expected result is unclear or changes during UAT?

Ask the process owner to resolve the rule before judging the case. If it changes, record the agreed change, update the case version and expected data, and identify which earlier results need retesting. Record a new request for behavior separately from a defect against the previously agreed rule.

Does passing every UAT test case mean the release is approved?

Only when those cases and results satisfy the agreed acceptance process. The authorized reviewer still needs to assess coverage, unresolved issues, and remaining risks against the exit criteria. A test execution result and release approval answer different questions.