Guide
UAT checklist
User acceptance testing (UAT) answers one question: does the site actually work for the people who'll use it, not just for the people who built it? That means testing with real tasks, on real devices, by people who weren't in the build meetings.
Before testing starts
- The build is feature-complete, or everyone testing knows exactly what's still missing.
- Test accounts exist for every role (admin, member, guest, logged-out visitor).
- Testers have real tasks to complete, not "click around and see." A task is "find the pricing page and sign up for the yearly plan," not "test the pricing page."
- A place to log what's found is agreed before anyone starts, so bugs don't end up in five different Slack threads.
Core tasks to test
- Sign up, sign in, sign out, and reset a forgotten password.
- Every primary call to action: the main thing you want a visitor to do, start to finish.
- Every form: submit it with valid data, then with missing required fields, then with obviously wrong input (an email with no @, a negative price).
- Checkout or payment, including what happens when a card is declined.
- Search, if the site has it, with a query that matches and one that doesn't.
- Navigation: every top-level menu item leads somewhere real, and the back button behaves.
Cross-device and cross-browser
- Desktop Chrome, Safari and Firefox, at minimum.
- A real phone, not just a resized browser window: touch targets, the keyboard covering a form, orientation changes.
- A slow connection: throttle it, or test on actual mobile data once.
- Zoomed text (150–200%) doesn't break the layout.
Content and edge cases
- Real content, not lorem ipsum: long names, long product titles, empty states (no results, no items yet).
- Dates, currencies and numbers format correctly for the audience.
- Error messages are readable and say what to do next, not just "an error occurred."
- Browser back/forward and refresh don't lose form data or break the flow mid-process.
Accessibility basics
- Every interactive element is reachable and usable by keyboard alone (Tab, Enter, Esc).
- Images have alt text; form fields have labels.
- Colour isn't the only way information is conveyed (an error isn't shown by red text alone).
Tracking what's found
- Every bug has steps to reproduce, not just "this is broken" (see the bug report template).
- Bugs are triaged by severity: what blocks sign-off, what can ship and get fixed after.
- Someone owns the final sign-off decision, so testing doesn't quietly drag on forever.
Do it in StiqNote
Give every tester a guest link to the staging site, no account or install required for them. They pin each issue to the exact element, with a screenshot, and on Pro their report also brings console errors and a replay of what led up to it. You see every tester's findings in one place, assign them, and track which are resolved. When the list is clear, you have a dated record that UAT actually happened and what it covered.
See StiqNote for QA and UAT for more on running a testing round this way.
Stop sending screenshots in Slack
Pin the feedback where it belongs. Free to start, with 14 days of Agency for your first team.