The short answer
A demonstration shows the path the supplier built and tested. Your acceptance testing is worth most where it covers the paths they did not think about.
That does not require technical knowledge, only deliberate awkwardness.
Test the awkward paths
- Enter wrong or unexpected input and see what happens.
- Stop halfway through and come back later.
- Use the back button, and refresh mid-process.
- Try to do something you should not be allowed to do.
- Do the whole thing on a phone.
Point four is the one most often untested. Trying an action with an account that should not have permission finds real problems surprisingly often.
Use real data and real people
| Test with | Finds |
|---|---|
| Your actual data | Format and volume problems |
| Your longest records | Layout breaking |
| Names with unusual characters | Encoding faults |
| The people who will use it | Workflow mismatches |
| Your slowest connection | Performance problems |
Unusual characters in names and addresses are a standard and frequently missed fault. It is worth a specific test every time.
Check what happens when things go wrong
- Error messages that say what to do
- Nothing lost when a process is interrupted
- The system is usable when a connected service is down
- Somebody is notified when something fails
- You can tell whether an action succeeded
The last point matters for enquiry forms and payments particularly. A user who cannot tell whether something worked will try again, and duplicates follow.
Write down what you tested
A list of what was tested and what the result was makes acceptance a conversation about specifics rather than a general impression.
It also means a fault found later can be checked against whether it was in scope, which is a much shorter conversation than an argument about expectations.