Client-side software acceptance and UAT

How UAT differs from technical testing

The vendor checks features, integrations and code. UAT asks whether a business user can complete a real process from start to finish and achieve the intended outcome.

It is not enough that a form saves data. Users must understand the fields, information must reach the right person, exceptions must be handled, notifications delivered and reports accurate.

What UAT preparation covers

• Review requirements, acceptance criteria and contract terms.
• Identify processes and features critical to launch.
• Prepare test scenarios and data.
• Assign users and responsibilities.
• Agree the environment, schedule and results-recording process.
• Classify defects, gaps and new requests.
• Verify fixes and regression-test critical processes.
• Recommend acceptance, conditional acceptance or rejection.

Not every comment is a defect

Users raise different issues during testing: gaps against agreed scope, technical defects and new ideas triggered by seeing the system.

Without classification, everything lands in one queue. Vendors may call defects changes, while clients may try to block acceptance over features never commissioned. Each issue should be linked to a requirement, described and assessed for impact.

Conditional acceptance

A minor issue need not delay launch. Conditional acceptance can be appropriate when the system is safe to use and remaining fixes have clear owners and deadlines.

The conditions must be measurable. A general promise to “fix it after launch” gives little control. You need an issue list, priorities, dates, verification methods and consequences for non-delivery.

Acceptance includes handover

A project does not end when the application works. Check that the client has received everything agreed for operating, maintaining and developing the system.

• Administrative access and service accounts.
• User, technical and operational documentation.
• Source code or repository access as agreed.
• Licences, configuration and third-party component information.
• Backup, recovery and monitoring instructions.
• Support, warranty and incident-reporting procedures.
• Known limitations and a plan for remaining work.
• Data export and recovery capabilities.

When independent support helps

• Acceptance criteria are vague or undocumented.
• Users lack experience in running UAT.
• The vendor wants sign-off before testing is complete.
• Issues are growing and the parties disagree on classification.
• Launch is tied to final payment or a warranty deadline.
• The system handles critical processes or data.