Recently we’ve shown you the basics of User Acceptance Testing (UAT). Let’s recap: User Acceptance Testing is, basically, the process of verifying that an installed solution works for the user. This might sound easy enough but, in practice, it isn’t.
To make getting into User Acceptance Testing a little easier, we’ve broken the process down into smaller chunks. Check out which 5 types of User Acceptance Testing you have to consider in order to be more successful.
Getting started with User Acceptance Testing
If you’re just getting started with User Acceptance Testing, we’ve prepared a UAT testing checklist you can download. It covers everything from preparing your team and your test environment to executing and then evaluating the test.
When & why User Acceptance Testing is needed?
An acceptance test can be understood as a way to check if a previously defined “contract” between the developer and the customer is still on track. Running those acceptance tests also ensures that no requirement change has happened in the meantime and that everything is as it should be to satisfy the customer.
Acceptance tests are useful, because:
- they capture user requirements in a directly verifiable way,
- they identify problems which unit or integration tests might have missed,
- and they provide an overview on how “done” the system is.
How is User Acceptance Testing (UAT) different from functional testing?
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.
Types of User Acceptance Testing
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 & Beta Testing
- Contract Acceptance Testing
- Regulation Acceptance Testing
- Operational Acceptance Testing
- Black Box Testing
Alpha & Beta Testing
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
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
Regulation Acceptance Testing, also known as Compliance Acceptance Testing, examines whether the software complies with the regulations. This includes governmental and legal regulations.
Operational acceptance testing
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
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.
Is there a tool for that?
When considering UAT, you’re probably thinking of some “old fashioned” methods – like email, attachments, powerpoint presentations, spreadsheets, etc. And you’re probably wondering, “but isn’t there a tool for that?” There is. In fact, there are a few.
engageuat is a tool which let’s you manage every aspect of User Acceptance Testing. From creating test cases to actually conducting the tests to analysing the results. With engageuat everything is stored in one place. Definitely give them a try.
QASymphony calls itself a testing software for an agile world. It’s a tool for testing your software and conducting various acceptance tests.
The great thing about QASymphony is that it also integrates with commonly used issue and testing software, such as JIRA.
I don’t want to sound too salesy here, but we do eat our own dog food. A simple and lean bug tracking tool – such as Usersnap – helps a lot when it comes to verifying if a certain solution works for the user. When it comes to User Acceptance Testing, it’s less about functional requirements and more about how the user perceives your product and if it works for the user.
By having a simple and easy-to-use feedback widget or any kind of feedback form, users can provide comprehensive feedback on your software.
Anything else? Get started with UAT.
Of course, there are many more types of and frameworks for User Acceptance Testing. I hope that, by providing you with our basic overview of 5 types of User Acceptance Testing, we shed some light into the darkness of UAT.
Make sure to check out our post on how to do user acceptance testing right!
Prefer a quick summary? No worries, we got you covered with this overview of how to get started with UAT.
I know, I just talked about User Acceptance Testing. Last but not least, I just wanted to give you a heads-up on Usersnap, which is our very own bug tracking and feedback tool, used by companies like Facebook, Oracle, and Google. Feel free to give it a try. It’s free for 15 days.
If user feedback and testing isn’t part of your business. No worries. That’s fine. However, you might enjoy our email list full of design tips, development tricks, and tech news.