User Acceptance testing is the topic of the day. We will discuss all about UAT – its definition, types, steps, detailed process etc. in this tutorial.
What You Will Learn:
My rule number one when trying to understand a new concept is that: the name is always going to be relevant and mostly a literal meaning (in the technical context). Finding out what that is, will give me an initial understanding of it and gets me started.
Let us put this concept to test. UAT stands for User Acceptance Testing. We know what testing is, acceptance means approval or agreement. The user in the context of a software product is either the consumer of the software or the person who requested it to be built for him/her (client).
So, following my rule -UAT means testing a software by the user/client to determine whether it can be accepted or not – the definition. Give this method a try with other technical words too. Trust me, it works every single time. :)
When is it performed?
This is typically the last step before the product goes live or before the delivery of the product is accepted. UAT is after the product itself is thoroughly tested (i.e after system testing).
Who performs UAT?
Users or client – This could be either someone who is buying a product (in the case of commercial software) or someone who has had a software custom built through a software service provider or the end user if the software is made available to them ahead of time and when their feedback is sought.
The easiest way to understand this process is to think of UAT as an autonomous testing project – which means, it will have the plan, design and the execution phases.
The following are the pre-requisites before the planning phase begins:
#1. Gather the key acceptance criteria
Acceptance criteria- to simply put, this is a list of things that are going to get evaluated before accepting the product. These could be of 2 types:
A) Application functionality or business related
Ideally all key business functionality should get validated but due to various reasons, including time, it is not practical to do it all. Therefore, a meeting or two with the client or the users who are going to be involved in UAT can give us an idea on how much testing is going to be involved and what aspects are going to be tested.
B) Contractual – we are not going to go into this and the involvement of the QA team in all this is almost nothing. The initial contract that gets drawn up even before the SDLC begins is reviewed and an agreement is reached upon whether all the aspects of the contract have been delivered or not.
We are going to focus only on application functionality.
#2. Define the scope of QA involvement. QA team’s role is one of the following:
A) No involvement – This is very rare.
B) Assist in UAT – most common. In this case, our involvement could be training the UAT users in how to use the application and be on standby during the UAT to make sure we can help the users in case of any difficulty. Or in some cases, in addition to being on standby and assisting, we might share their responses and record the results or log bugs etc. while the users perform the actual testing.
C) Perform UAT and present results – If this is the case, the users will point the areas of the AUT that they want to evaluate and the evaluation itself is performed by the QA team. Once done, the results are presented to the clients/users and they will make a decision on whether the results that they have in hand are sufficient and in accordance with their expectations in order to accept the AUT. The decision is never that of the QA team.
Depending on the case on hand, we decide which approach is best.
The process is almost the same as with the regular test plan for the system phase. The most common approach followed in most of the projects is to plan for both system and UAT testing phases together. For more information on UAT test plan and a sample, check out the attached test plan document’s UAT sections.
User Acceptance Test Plan
(This is the same that you would find on our site for the QA training series as well).
Click on below image and scroll down to find the test plan document sample in various formats. In that template check the UAT section.
The dates, environment, actors(who), communication protocols, roles and responsibilities, templates, results and their analysis process, entry-exit criteria – all of this and anything else relevant will be found in the UAT test plan. Whether the QA team is participating, partially participating or not participating at all in the UAT, it is our job to plan this phase and make sure everything is taken into consideration.
The gathered acceptance criteria from the users are used in this step. Samples could look like the following:
(These are excerpts from CSTE CBOK. This is the one of the best of the few references available about UAT.)
User Acceptance Testing Template:
Based on the criteria, we (QA team) give them the users a list of UAT test cases. UAT test cases are not different from out regular system test cases. They are just a subset since we test all of the application as opposed to just the key functional areas.
In addition to these, the data, templates to record test results, administrative procedures, defect logging mechanism has to be in place before we move to the next phase.
Usually, when possible, UAT happens in a conference or war room sort of a set up where the users, PM, QA team representatives all sit together for a day or two and work our work through all the acceptance test cases.
Or in case of QA team performing the tests, we run the test cases on the AUT.
Once all the tests are run and the results are in hand, the Acceptance Decision is made. This is also called the Go/No-Go decision more colloquially. If the users are satisfied it’s a Go, or it’s a No-go.
The reaching of the acceptance decision is typically the end of UAT phase.
Important UAT points:
#1. UAT is not about the pages, fields or buttons. The underlying assumption before even the UAT begins is that all that basic stuff is tested and is working fine. God forbid, the users find a bug as basic as that – it is very bad news for the QA team. :(
#2. UAT is about the entity that is the primary element in the business.
Let me give you an example: If the AUT is a ticketing system, the UAT is not going to be about, searching, the menu that opens a page etc. It is about the tickets and their reservation, the states that it can take, its journey through the system. Another example, if the site is a car dealership site, the focus is on the “car and its sales” not the site really. So the core business is what is verified and validated and who better to do it than the business owners. That’s why UAT makes the most sense when the customer is involved to a major extent.
#3. UAT is also a form of testing at its core which means there is a good chance of identifying some bugs at this phase too. It sometimes happens. Aside from the fact that it is a major escalation on the QA team, the UAT bugs usually mean a meeting to sit and discuss how to handle them because following UAT there is usually no time to fix and retest.
The decision would be either to:
#4. UAT is classified as Alpha and Beta testing, but that classification is not so important in the context of typical software development projects in a service-based industry.
#5. Most of the times in a regular software development project, UAT is carried out in the QA environment if there is no staging or UAT environment.
About the Author: This article is written by STH team member Swati S. She is having 9+ years of experience in software testing.
What was your UAT experience? Were you on standby or did you test for your users? Did the users find any issues? If yes, how did you deal with them?
Share your experiences with us and let us know your comments and questions below.