What makes UAT different from other testing
Unit tests verify individual functions. Integration tests verify that components work together. UAT verifies that the system does what users actually need it to do.
The difference matters because the failure modes are different. A function can work perfectly while the user workflow it supports is broken. UAT catches workflow failures — the kind that only show up when a real human tries to accomplish a real goal.
The anatomy of a good test case
A test case that a tester can execute without guessing has five parts:
| Field | What it means | Example |
|---|---|---|
| Title | Short description of what's being tested | User can reset password via email link |
| URL hint | Where in the app this takes place | /account/password-reset |
| Instructions | Step-by-step actions the tester takes | 1. Navigate to /account/password-reset 2. Enter registered email 3. Click "Send reset link" 4. Open email and click link |
| Expected result | What success looks like | Redirected to /account/set-password, "Password updated" toast visible after form submission |
| Max score | Weight for scoring (optional) | 10 |
When any of these are missing, test results become ambiguous. "Does this pass?" becomes a judgment call instead of a verifiable outcome.
How to write instructions that don't leave gaps
The most common problem with test case instructions is assumed knowledge: "Sign in and go to the checkout page" skips the login flow entirely. A tester unfamiliar with the system will interpret each step differently.
Write instructions as if the tester has never used the application before. Start from the URL. Name every button exactly as it appears on screen. Specify both inputs and expected intermediate states.
Weak instruction (ambiguous)
"Add an item to the cart and check out."
This doesn't specify which item, what payment method to use, or what "checkout complete" looks like.
Strong instruction (specific)
"1. Navigate to /products. 2. Click 'Add to cart' on the first product. 3. Click the cart icon in the header. 4. Click 'Proceed to checkout'. 5. Enter test card 4242 4242 4242 4242 with any future expiry. 6. Click 'Place order'."
Structuring suites for repeatability
Group by user journey, not by feature
"Authentication" is a feature. "New user onboarding from signup to first purchase" is a journey. Journey-based suites catch integration failures between features; feature-based suites often don't.
Keep suites focused
A suite with 80 test cases takes half a day to run. By test case 40, testers lose focus and details get missed. Target 10–25 cases per suite for focused, reliable results.
Separate smoke suites from full regression
- Smoke suite (5–10 cases): Critical user paths only. Run before every staging deployment. Should pass in under 30 minutes.
- Regression suite (20–50 cases): Full coverage. Run weekly or before major releases. Takes 2–4 hours.
Scoring and rubric items
Not all test cases are equal. A broken checkout is worse than a misaligned label. Assigning max scores to cases lets you compute a quality score for each test run, making it easier to track quality trends over time and to justify release decisions.
Rubric items within a case let you score partial passes: a form might work functionally but display an incorrect error message. Score the functional part and the messaging separately.
Tracking results over multiple sprints
The value of a UAT suite compounds over time when you run the same suite across sprints. Iteration-over-iteration scores tell you whether quality is improving, degrading, or holding steady.
Keep suites versioned: when requirements change and a test case becomes invalid, retire the case rather than modify it. Your historical scores remain meaningful.
What to do when a test case fails
- File a bug report immediately — don't wait for the run to complete
- Include the URL, the exact step where it failed, and what you saw vs. what you expected
- Attach a screenshot with the problem annotated
- Include any console errors or unusual network requests
With Site Reviewer's guided test run mode, Pass/Fail/Skip verdict buttons are shown alongside each test case. Failing a case prompts for a problem description and opens a pre-filled bug report with the test case's URL hint, instructions, and expected result already in context.
"UAT finds the bugs your automated tests can't: the ones that require a human to notice that something feels wrong, even when nothing throws an error."
Importing your existing test plan
If you maintain your UAT checklist in a spreadsheet or Google Sheets, Site Reviewer can import it directly. Export to CSV with columns: position, title, instructions, expected_result, url_hint, max_score. Upload via the dashboard or POST /api/v1/uat/import.
Ready to structure your UAT?
Site Reviewer includes a full UAT runner: import test suites from CSV or JSON, run them step-by-step with pass/fail scoring, and track results across sprints. Bug reports from failed test cases flow automatically to GitHub Issues, Jira, or Linear.
Start free → — no credit card required.