Types of User Acceptance Testing
The methodology
of User Acceptance
Testing (UAT) is pretty straight-forward. The implementation
itself requires some in-depth knowledge on the available types of User
Acceptance Testing, though.
User Acceptance
Testing is the process of verifying that a created solution/software works
for ‘the user’. This might sound easy enough but, in practice, it isn’t.
To make your journey
into User Acceptance Testing a bit easier, we researched the 5 most
common types of User Acceptance Testing you have to consider.
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 UAT 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 client 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
client.
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.
When looking at the
process of software development, we can see that UAT is utilized to identify
& verify client
needs.
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 starts. 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: Let’s say, Facebook launches a new feature, allowing Facebook users to
send postcards to family & friends. Technically the implemented solution
works. Testers also can use it – however due to lack of interest and need, no
one will want to send printed postcards. Functional tests would go well,
usability tests would go fine too, but the user acceptance test
would probably fail as Facebook users do not demand to send postcards
within Facebook.
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. Also potential user groups might conduct Alpha Tests, but
the important thing here is that it takes place in the development environment.
Based on the feedback
– collected from the alpha testers – development teams then fix certain issues
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.
Is there a tool for
that?
Did you email me the spreadsheet
with the beta test results?
Asking testers via
email to provide their test results is still a popular way to conduct and run
alpha/beta tests. And yet you’re probably wondering, “but isn’t there a better
solution for that?” Luckily, there is.
User snap – Your
testers will love it
User snap is
a great solution for asking alpha and beta testers for feedback.
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 project
team defines the relevant criteria and specifications for acceptance at the
same time when the team agrees on the contract itself.
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.
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 categorized as functional testing, but can, to some extent, be seen as a
type of User Acceptance Testing.
It’s a method of
software testing which analyzes certain functionalities without letting testers
see the internal code structure. Black Box Testing is part of User Acceptance
Testing, because Black Box Tests share the same principles as UAT.
During Black Box Tests the user isn’t aware of any code base, but only about the requirements which the software should meet.
Testers do not require
any specific knowledge about the application or any of its features. The tester
conducting Black Box Tests is only aware of what the software is supposed to
do. They don’t know how it should be done.
Many QA and development teams use Black Box Testing for their UAT efforts pretty frequently.
Comments
Post a Comment