In short
- UAT is done by future users on company data - the vendor's testing does not replace it.
- You test scenarios from daily work, not individual buttons.
- Every defect needs a description: what was done, what happened, what was expected, a screenshot and severity.
- Agree up front which defects block acceptance and which can be fixed after launch.
- The result goes into the acceptance protocol: accepted, accepted with reservations or refused.
Who tests
The people who will use the system every day, plus someone who knows the process from the business side. The vendor tests earlier and supports UAT, but the client judges whether the system is fit for work.
Plan these people's time - UAT done "on the side" usually ends with a few screens clicked through quickly.
Test scenarios
Instead of testing single features, describe scenarios from real work, e.g. "a sales rep takes an order from a customer, a manager approves it, the order reaches the ERP". For each scenario add variants:
- the typical case,
- wrong data and empty fields,
- rejection and correction,
- the approver being away,
- a large amount of data.
Test data
Test on data similar to the real thing: real item names, accented characters, long descriptions, unusual cases. If testing uses a copy of production data, take care of personal data - it may need anonymising.
Reporting defects
A good report saves days of back-and-forth. Each one should include:
- what was done (steps),
- what happened,
- what was expected,
- a screenshot or a recording,
- severity: critical (blocks work), major (hinders work), minor (does not get in the way).
The acceptance decision
Agree before testing which defects block acceptance. Usually: critical - yes, major - depends on how many and the workarounds, minor - no, but they go into the protocol with a fix date. The result is recorded in the acceptance protocol: accepted, accepted with reservations or refused with reasons.