In this post you will learn what is Acceptance Testing and types of User Acceptance Testing.Acceptance testing is the final level of testing usually performed after the system testing. Its purpose is to determine the acceptability of the software developed and evaluate it against the market standards. Finally concluding if it is fit for delivery.

This test can be pretty much automated for mobile and even for the web apps. In case of mobile which can be a big advantage as the updates are more frequent for both iOS and Android.

During UAT, actual software users test the software to make sure it can handle required tasks in real-world scenarios, according to specifications. UAT is one of the final and critical software project procedures that must occur before newly developed software is rolled out to the market.

User acceptance testing (UAT), otherwise known as Beta, Application, or End-User Testing, is often considered the last phase in the web development process, the one before final installation of the software on the client site, or final distribution of it.

Now you’re probably wondering about the differences between User Acceptance Testing and functional testing.

User Acceptance Tests consist of a set of test steps, which verify if specific requirements are working for the user. If the customer and the supplier agree on the product, the software development is done. Legally. And practically.

Functional testing, on the other hand, tests specific requirements and specifications of the software. It lacks the user component. A functional test could conclude that the software meets its specifications. However, it doesn’t verify if it actually works for the user. The functional dimension is only one of many.

Let me give you an example: A certain feature – let’s say, your in-app search feature – has some performance issues, and the loading time of the results page is pretty bad. Technically, it works. Every tester can use it – but because of the bad performance no one will want to. Functional tests would go well, usability tests would go fine as well, but the performance problems would probably lead to a failed acceptance test.

Now that we’ve clearly separated functional testing from User Acceptance Testing, we can look at the various types of User Acceptance Testing. The following User Acceptance Testing Types exist

Alpha Testing normally takes place in the development environment and is usually done by internal staff – long before the product is even released to external testers or customers. Alpha Testing can also be done by potential user groups, but the important thing here is that it takes place in the development environment.

 The feedback – collected from the alpha testers – is then used to fix certain issues or bugs and improve the usability of the product.

Beta Testing, also known as “field testing”, takes place in the customer’s environment and involves some extensive testing by a group of customers who use the system in their environment. These beta testers then provide feedback, which in turn leads to improvements of the product.

Alpha and Beta Testing are done before the software is released to all customers.

Contract Acceptance Testing means that a developed software is tested against certain criteria and specifications which are predefined and agreed upon in a contract. The relevant criteria and specifications for acceptance must be defined when the contract itself is defined and agreed upon.

Regulation Acceptance Testing, also known as Compliance Acceptance Testing, examines whether the software complies with the regulations. This includes governmental and legal regulations.

Also known as Operational Readiness Testing or Production Acceptance Testing, these test cases ensure there are workflows in place to allow the software or system to be used.

 This should include workflows for backup plans, user training, and various maintenance processes and security checks.

Black Box Testing is often categorised as functional testing, but can, to some extent, be seen as a type of User Acceptance Testing. It’s, basically, a method of software testing which analyzes certain functionalities without letting the tester see the internal code structure of the software. Therefore, Black Box Testing can also be applied to User Acceptance Testing, because Black Box Tests do share the same principles as User Acceptance Tests. During Black Box Tests the user isn’t aware of any code base, but only about the requirements which the software should meet.

No specific knowledge about the application or any of its features is required by the tester. The tester conducting Black Box Tests is only aware of what the software is supposed to do, but they don’t know how it should be done.

 From a practical point of view Black Box Testing is one of the most commonly used UAT techniques.