Igor
A UAT test case is one thing a business user does at work and the result they expect. The twelve examples below cover an online checkout, an invoicing system and a customer onboarding flow, four of each. Copy them, change the wording to match your product, and keep the habit that matters most: every set should include cases where the system is meant to say no.
How to write a UAT test case
A QA test case checks a function against a specification. A UAT test case checks that a person can finish a piece of their work. Four rules keep them useful:
- Start from a task, not a screen. "Refund a customer who returned an item" is a task. "Test the refund button" is not.
- Name the role. A clerk and a manager see different things. The tester should log in as the role the case is written for.
- State the expected result in business terms. "The customer's balance drops by the refund amount" beats "the API returns 200".
- Keep steps short. Five or six at most. If a case needs more, split it.
Cases sit inside a plan: see the UAT test plan template for where they go, and how to run UAT with testers who are not technical for how to hand them over.
Checkout (4 cases)
| ID | Scenario and role | Steps | Expected result |
|---|---|---|---|
| CHK-01 | Buy one item with a card. Role: shopper. | Add an item to the basket. Go to checkout. Enter the test card. Pay. | The order confirmation shows the correct total. A confirmation email arrives. The stock count drops by one. |
| CHK-02 | Use a discount code. Role: shopper. | Add items worth more than the code's minimum. Enter the code at checkout. | The discount is shown on its own line and the total is reduced by the right amount. The code cannot be used twice on the same order. |
| CHK-03 | Change delivery country. Role: shopper. | Start checkout with a UK address. Switch to an address in another country. | Delivery options and tax update to match, and the total recalculates. |
| CHK-04 | Should fail: pay with a declined card. Role: shopper. | Enter the test card that is set to decline. Pay. | A clear message says the payment failed. No order is created and the basket is still full. |
Invoicing (4 cases)
| ID | Scenario and role | Steps | Expected result |
|---|---|---|---|
| INV-01 | Create and send an invoice. Role: accounts clerk. | Choose an existing customer. Add two lines. Save. Send. | The total matches the lines plus tax. The customer receives the email with the PDF attached. |
| INV-02 | Apply a credit note. Role: accounts clerk. | Open an unpaid invoice. Create a credit note for part of it. Apply it. | The balance drops by the credit amount, and the invoice and credit note link to each other. |
| INV-03 | Record a part payment. Role: accounts clerk. | Open an unpaid invoice. Record a payment for half the amount. | The status changes to part paid and the remaining balance is correct. |
| INV-04 | Should fail: approve your own invoice. Role: accounts clerk. | Create an invoice over the approval limit. Try to approve it. | The system refuses and says a manager must approve. The invoice stays in draft. |
Onboarding (4 cases)
| ID | Scenario and role | Steps | Expected result |
|---|---|---|---|
| ONB-01 | Sign up and verify email. Role: new customer. | Fill in the sign-up form. Open the email. Click the verification link. | The account is active and the customer lands on the welcome page, logged in. |
| ONB-02 | Complete the profile. Role: new customer. | Add a name, company and phone number. Upload a logo. Save. | The details appear on the profile page and in the account menu after a refresh. |
| ONB-03 | Invite a colleague. Role: account owner. | Open team settings. Enter a colleague's email. Send the invitation. | The colleague receives the email, can join, and appears in the team list with the chosen role. |
| ONB-04 | Should fail: sign up with an email already in use. Role: new customer. | Submit the sign-up form with an address that has an account. | A message says an account exists and offers password reset. No second account is created and nothing leaks about the existing one. |
Why the "should fail" cases matter
Each set above ends with a case where the right outcome is a refusal. Business testers find the most useful defects there, because they know what a real mistake looks like: a card that declines, a duplicate sign-up, a clerk who approves their own work. Developers tend to build and test the happy path, so the unhappy path is where the surprises are. Add at least one for every three or four cases you write.
Running them
Give each tester the cases for their role, a login that matches the role and a single place to report a failure. When a case fails, the defect needs the case ID, what happened and what they expected, plus the evidence: the page, the error and the steps. If testers have to write that by hand, many will skip it. SnagRelay is the reporting part: the tester clicks Report on the page where the case failed, points at the element and writes what they expected, and the console errors, the failing requests and the steps are attached, then sent to your tracker or inbox. SnagRelay does not store test cases or track pass and fail; keep the cases in your own sheet or test tool and put the case ID in the report. For the full set-up see UAT testing with SnagRelay.
FAQ
What is a UAT test case?
A description of one business task, the role that does it, the steps and the result the user expects. It is written so that a business user, not a developer, can run it.
How many UAT test cases do I need?
Enough to cover the main business processes and the riskiest exceptions, and few enough that testers finish. A small project may have twenty to forty. Quality of coverage matters more than the count.
What is the difference between a test case and a test scenario?
A scenario is the situation ("a customer returns an item"). A case is the detailed version with the steps and the expected result. In UAT the two words are often used interchangeably, and it is fine as long as your team uses them consistently.
Should UAT test cases be written by QA?
QA can draft them, but the business testers should review and own them. They know the real tasks, and a case they wrote is one they will run.