Acceptance criteria written after development is finished are not acceptance criteria. They are an opinion formed while looking at the result, and they cannot settle anything.
Writing criteria before the build
Acceptance criteria describe how you will decide a feature is done, and they have to exist before the feature is built for two reasons: the developer needs to know what they are building toward, and the client needs a standard that was not influenced by the outcome.
A usable criterion is specific and testable:
- Weak: "The search should work well."
- Usable: "Searching by customer name returns matching records within two seconds, matches partial names, and is case-insensitive."
The second can be tested by anyone. The first cannot be tested at all.
Running a UAT that finds real problems
User acceptance testing done as "have a look and tell us what you think" finds cosmetic issues and misses the ones that matter. Structure improves it enormously.
- Test by workflow, not by screen. Walk through complete tasks a real user performs end to end. Bugs live at the joins between screens, not on the screens.
- Use realistic data. Long names, accented characters, empty optional fields, large quantities, dates at month and year boundaries. Clean test data hides most input handling problems.
- Test the failure paths deliberately. Submit the form twice. Enter a wrong password five times. Lose the connection halfway through. These paths are where real users end up and where testing rarely goes.
- Have the actual users test it. The person who will use the system daily finds problems the sponsor never will, because they know what the work really involves.
- Record every finding in one place, with steps to reproduce and a screenshot. A finding that cannot be reproduced cannot be fixed.
Defect or change
Every UAT produces findings that are not defects, and classifying them fairly is what keeps the process from becoming adversarial.
A defect is a difference between what was agreed and what was built. Fixed at the developer's cost.
A change is something that works as agreed but is not what the client now wants. Quoted separately.
Clients frequently experience the second as a defect, because the software does something they did not expect. The honest response is not to argue about the label but to point at the agreed criterion and then ask whether the change is worth making. Many turn out not to be.
Severity, which decides what blocks launch
Not every defect has to be fixed before go-live, and treating them all as blocking delays launches for no benefit. A simple three-level classification agreed in advance:
- Blocking — a core workflow cannot be completed, data is lost or corrupted, or a security issue exists. Must be fixed before launch.
- Major — a feature works incorrectly but a workaround exists. Fixed before launch if time allows, otherwise scheduled with a date.
- Minor — cosmetic issues, wording, small inconsistencies. Batched into a post-launch release.
Agreeing this classification before UAT starts converts an argument about urgency into a shared assessment.
What sign-off commits both sides to
Sign-off should mean something specific: the agreed criteria are met, outstanding minor items are listed with dates, and the payment milestone is released. It starts the warranty period, during which defects found later are fixed at no charge.
It does not mean the client can never report a problem again, and a contract implying that is unreasonable. The warranty period is what covers defects that a reasonable UAT would not have found.
Time to allow
UAT is consistently under-planned. For a small project, allow one to two weeks — enough for real users to test around their actual jobs, for findings to be fixed, and for a retest.
Compressing it to two days produces a sign-off that means nothing, and the problems surface in the first week of live use instead, when they cost more and are far more visible.
Related Manboo Services
- Flutter App Development for iOS and Android MVPs.
- Business Software Development for CRM, booking, inventory and workflow systems.
- Admin Panel Development for operations dashboards and backend management.
- AI API Integration when your product is ready for smart search, chat or automation.
- Request a scope review and project estimate when you are ready to plan the first version.