The demo went well. The screens looked clean, the colours matched the brand, and your developer walked through the main journey without a hitch. Everyone in the room nodded. You signed off on the build and booked the go-live date.
Three weeks after launch, your operations manager calls to say the system crashes every time someone enters a partial postcode. Your top sales rep can't approve a quote on her phone. And a customer received an invoice with a £0.00 total because the system didn't handle a discount applied at the line-item level.
None of those failures appeared in the demo because nobody tested them. The developer tested what the software was designed to do. Nobody tested whether the design reflected real work — the messy, exception-filled, human work your business actually does every day.
That gap is what User Acceptance Testing exists to close. And it's the business's job to close it.
Why visual approval is not testing
Looking at screens and confirming they appear correct is not testing. It is reviewing. There is an important difference.
A review answers: does this look right? A test answers: does this work correctly when real people use it under real conditions? Reviewing catches obvious errors in layout, wording, and navigation. It does not catch what happens when a user enters a customer name with an apostrophe, submits a form twice, leaves a required field empty, or tries to access a page they shouldn't.
Developers can test whether the software behaves as designed. Only the business can test whether the design reflects real work.
Developers are expert at testing the happy path — the sequence of actions that leads cleanly from start to finish when everything goes as planned. They are also good at unit tests, integration checks, and load testing. What they cannot reliably replicate is the full variety of human behaviour that your staff and customers bring to software on an ordinary Tuesday morning.
That is not a criticism of developers. It is simply a recognition that the people who know your business processes, your unusual customers, your edge cases, and your operational pressure points are on your side of the table.
How to write test scenarios from real business work
The most effective UAT scenarios are not invented — they are borrowed from last week's work.
Ask your team: what did you actually do in the old system (or in the spreadsheet, or on the phone) last Monday? Walk through those activities one by one. A test case has three parts: a starting condition, a sequence of steps, and a clear expected result.
For example: Starting condition — a new customer with no purchase history. Steps — create enquiry, add three line items, apply a 10% trade discount, convert to a quote, receive approval, convert to an invoice, mark as paid. Expected result — the invoice shows discounted totals, payment is recorded, account balance is zero.
You need five to ten scenarios covering your most common journeys, written in plain language. Google Sheets works perfectly: one row per scenario, columns for steps, expected outcome, actual outcome, and pass/fail. A useful prompt for your team: 'Tell me about a transaction last week that was slightly unusual.' Those stories become your most valuable test cases.
Testing exceptions, wrong inputs, permissions, and mobile use
Once you have your happy-path scenarios, introduce deliberate friction. Real users make mistakes; real data is imperfect; real workflows get interrupted. Focus on four areas:
- Wrong inputs. Future date where a past date is required, letters in a number field, a very long name, a blank required field. The system should return a clear error — not a crash or a blank page.
- Boundary conditions. Zero items in an order. A quantity of 10,000. A discount that takes the price below zero. An invoice date on a bank holiday.
- Permissions and roles. Can a junior staff member see data they shouldn't, or approve above their limit? Can a customer reach another customer's records by tweaking a URL?
- Mobile use. Test on an actual phone or tablet — not a resized browser window. Focus on dropdown menus, date pickers, and multi-step forms.
None of this requires technical knowledge — only curiosity, a willingness to be awkward on purpose, and authority to insist that exceptions matter.
Recording bugs clearly: what happened, what was expected, and evidence
Finding a problem is only half the work. Reporting it so that a developer can reproduce and fix it is the other half — and this is where many UAT sessions stall.
A bug report that says 'the discount didn't work' is almost useless. A bug report that says 'I applied a 10% discount to line item 3 of order #0042, and the invoice total showed £110 instead of the expected £99' gives a developer something to act on.
Every bug report should contain:
- What you were doing. The exact steps, in order, from the starting point.
- What you expected to happen. The correct outcome described in plain terms.
- What actually happened. The incorrect outcome, including any error messages verbatim.
- Evidence. A screenshot, or better, a short screen recording. Loom's free tier is ideal for this — you record your screen for up to five minutes, share a link, and the developer can watch exactly what you did and what went wrong.
- Environment. The device, browser, and (if you know it) your user account or role.
Decide in advance how you will track bugs. A shared Google Sheet, a simple Trello board, or whatever project tool your developer uses all work. The important thing is a single, shared list — not a mixture of emails, Teams messages, and verbal conversations that are impossible to track to resolution.
Why testing protects customer experience
UAT is the last line of defence between your customers and a poor experience they will not easily forgive. Software failures visible to customers carry a different weight to internal inefficiencies. A staff member who encounters a confusing screen will grumble and find a workaround. A customer who receives a broken confirmation email, an incorrect invoice, or a booking that disappears overnight will lose confidence in your business — and may not return.
This is particularly acute if your software handles financial transactions, appointments, customer data, or communications on your behalf. In those contexts, the software is the customer experience. Testing it rigorously is not a technical obligation — it is a commercial one.
UAT should be run by the people who will actually use the system — your most experienced operators, not the person who commissioned it. Give them protected time: UAT squeezed between other work produces superficial results. Build it into the project plan early enough that what you find can actually be fixed before launch.
Practical steps to run a proper UAT session
- Write scenarios before opening the system. Document five to ten test cases drawn from last week's real transactions — starting condition, step sequence, expected outcome. Borrow from actual work, not hypotheticals.
- Use realistic data. Real customer names, actual product codes, genuine price points. Systems that pass with dummy data sometimes fail with real data because of character lengths or formatting edge cases.
- Assign one bug-reporter. One person captures every issue in the agreed format and shared tool. Bugs that live in email threads or Teams messages get lost.
- Spend a third of testing time on exceptions. Wrong inputs, boundary values, permission checks, interrupted workflows, mobile devices. The happy path is not enough.
- Agree what 'done' means before you start. With your developer, classify bugs: critical (blocks core work — must fix before launch), major (painful workaround exists — fix or schedule), minor (cosmetic, rare — post-launch is fine). This prevents a very uncomfortable conversation on go-live eve.
- Record short videos for complex bugs. A 90-second Loom beats a paragraph of description. It shows exactly what happened and under what conditions.
- Sign off in writing. When critical issues are resolved, confirm acceptance in writing. It protects both parties and marks a clean milestone.
UAT is not a tick-box before launch. It is the moment when your business takes responsibility for whether the software reflects the work it was built to support.
Getting started this week
If you have a system in UAT right now, or approaching that stage, open a blank Google Sheet today and write five test scenarios based on real transactions from last week. Not invented ones — actual work your team did. For each scenario, walk through the system step by step, exactly as a real user would, and write down what happened versus what you expected.
If even one of those five scenarios reveals a gap between designed behaviour and real-world need, you will have justified the entire testing exercise before the week is out. And you will have found it before your customers did.
