Every new website, app or business system goes through testing before launch. Developers test that the code does what it’s supposed to. But there’s a second kind of testing that only you can do: checking that the system actually works for your business, your staff and your customers. That’s user acceptance testing, and it’s worth doing properly.
You’ll also hear it called UAT. It sounds formal. In practice, it means real people trying to do real tasks and writing down what goes wrong. It’s one of the most valuable things you can do before go-live, and one of the most often rushed.
Here’s how to do it properly without a technical background.
Why user acceptance testing matters
A developer can check that a form saves data. They can’t easily know that your office always needs a second contact name for commercial customers, or that engineers need to record parts used before they can close a job. You know the edge cases, the exceptions and the “oh, but on Fridays we do it differently” moments.
Problems found before launch are cheaper and less stressful to fix than problems found by customers.
Prepare your testing
Step 1: write test scenarios from real life
A test scenario is simply a task someone needs to complete, written in plain English. Base them on what actually happens in your business.
- “A new customer calls, asks for a quote for two services and wants to pay a deposit by card.”
- “An existing customer changes their booking to next week and adds a note about access.”
- “A job is cancelled after the invoice has been sent.”
Include the everyday tasks and the awkward ones. The awkward ones are where most problems hide. Aim for a list covering everything each role does regularly, plus the exceptions people groan about.
Test the way your business actually works, not the way the demo shows it working.
Step 2: choose the right testers
Use the people who’ll use the system. Someone who’s new to the business will spot confusing wording. Someone who’s been there for years will spot the missing exceptions. A mix is ideal.
Give testers proper time for it. Testing squeezed in between phone calls tends to be shallow. A few focused sessions are better than a vague instruction to “have a play when you can”.
Run the tests
Step 3: test on real devices
Test on what people will actually use: the office computers, staff phones, the tablets in the vans. Check different browsers too. If customers will use the system, try it on an older phone and on a slower connection. Things that look fine on a large office monitor can be awkward on a small screen.
If accessibility matters to your users, and it usually does, include checks like using the keyboard only and reading text at larger sizes.
Step 4: record problems clearly
Good bug reports save everyone time. For each issue, note:
- What you were trying to do
- The steps you took
- What you expected to happen
- What actually happened
- The device and browser you were using
- A screenshot, if possible
“The booking page is broken” is hard to act on. “On an iPhone in Safari, choosing a date in December shows no available times, although the calendar has free slots” can usually be fixed quickly.
Keep all issues in one shared list, and agree with your developer how they’ll be tracked.
Fix and sign off
Step 5: sort issues by importance
Not every issue needs fixing before launch. Sort them into three groups:
- Blockers. The system can’t go live until these are fixed. For example, payments failing or data saving to the wrong customer.
- Important. Should be fixed soon, but there’s a workaround for now.
- Nice to have. Improvements or preferences that can go on a list for later.
It’s worth being clear with your developer about which items are bugs (it doesn’t work as agreed) and which are new requests (you’d like it to work differently). Both are valid, but they’re usually handled and charged differently.
Step 6: retest before you sign off
When fixes come back, check them. Then run through your main scenarios once more, because fixes can occasionally affect other areas. Only sign off when the blockers are gone and you’re confident the core tasks work end to end.
A quick pre-launch checklist
- Every key task has been tested by someone who does it for real.
- Testing has covered phones and desktops.
- All blockers are fixed and retested.
- Emails and notifications go to the right people with the right wording.
- Data imported from the old system has been spot-checked.
- Someone knows who to call if something breaks on launch day.
After testing
Careful user acceptance testing makes launch day much calmer, but a few things will still surface once real customers arrive. That’s normal, and it’s why the weeks after go-live need cover too. Our system and app support covers that period and beyond, and for projects still at the planning stage, testing is built into our custom development process from the start.
