User acceptance testing

What is user acceptance testing

User acceptance testing (UAT) is the final stage of testing in which customers or end users test the complete system, usually with their own real data, to decide whether it meets their requirements and is ready to be accepted and deployed. It is a validation activity: the question is "Is this the right system for us?", not just "Does it match the specification?". It is black-box and based on business scenarios.

Define acceptance criteria -> Plan acceptance testing
 -> Derive acceptance tests -> Run acceptance tests
 -> Negotiate test results -> Accept / reject system

Different types of testing in user acceptance testing

1. Alpha testing

   • Done by selected end users at the developer's site, with developers watching and recording problems.
   • Controlled environment; errors are fixed quickly.
   • Example: hospital staff try a new patient-record system in the developer's office.

2. Beta testing (field testing)

   • Done by real users at their own sites in the real environment, without developers present.
   • Users report problems and suggestions; used for products sold to many customers.
   • Example: a mobile app released to a limited group as a beta version.

3. Contract acceptance testing

   • The system is tested against the acceptance criteria written in the contract between customer and developer.
   • Payment or sign-off depends on passing these tests.
   • Example: a government payroll system must process 10,000 employees in under one hour, as stated in the contract.

4. Regulation (compliance) acceptance testing

   • Checks that the system follows laws, regulations and standards such as banking rules, tax rules, data protection or safety standards.
   • Example: a banking app checked against central bank (Nepal Rastra Bank) security guidelines.

5. Operational acceptance testing (OAT)

   • Done by system administrators or operations staff to check operational readiness: backup and restore, recovery after failure, installation, user management, security, and maintenance tasks.
   • Example: checking that the database can be restored from last night's backup within 30 minutes.

6. Business acceptance testing (BAT)

   • Checks that the system meets business goals and workflows, such as correct reports, billing rules and process flow, from the business owner's view.

A sample acceptance test case for a college fee system:

These may be informal (users "test drive" the system) or formal (planned test cases run against acceptance criteria). In agile development, acceptance tests are written with the customer for each user story and run in every iteration.

Why it is necessary

• Validates real needs: developers may misunderstand requirements; only users can confirm the system is fit for their work.
• Finds remaining defects in real data and real workflows that system testing missed.
• Basis for sign-off: it gives the customer an objective reason to accept the system and release payment.
• Reduces risk and cost: problems are found before going live, when they are cheaper to fix.
• Builds user confidence and makes training and adoption easier.