What Is User Acceptance Testing? How Is It Planned and Executed?
User acceptance testing (UAT) is the ultimate decider of how your target audience will react to your product. Although a type of functional testing, the point at which UAT testing is performed makes it an imperative in the SDLC.
Why? Because it is done right before software deployment. It is important to understand how user acceptance testing is carried out, as is understanding what user acceptance testing is. To successfully perform it, you will need a user acceptance testing checklist with all essential steps documented.
Why not wing it and forego the checklist? Because a documented testing process will help you develop better software and will save you money in the long run. Don’t worry -- we’ve got you covered with the checklist!
In this article, we will answer the following questions:
- What are the prerequisites for performing user acceptance testing?
- What are the common steps in the user acceptance testing checklist?
Ready? Let’s dig in!
Prerequisites for Performing User Acceptance Testing
To perform this user acceptance testing effectively, you should need to make sure that:
- Business requirements are available.
- The application code is completely developed.
- All other types of functional testing (unit, integration, and system) have been performed.
- There are no major errors found in the stages prior to user acceptance.
- No major issues have been found in the regression cycle.
- The user acceptance testing environment is stable and ready
- You have a sign-off from the team that performed the system testing cycle that UAT can proceed.
User Acceptance Testing Checklist
A user acceptance testing cycle starts with a thorough analysis of business requirements and defines exit criteria for user acceptance. The steps performed in the whole process include:
- Analyzing business requirements
- Creating a plan for UAT
- Identification of test case scenarios
- Data masking to prepare production-like test data
- Execution of test cases
- Confirmation that the business objectives are met
How Are Business Requirements Analyzed?
This is perhaps the most important component of the user acceptance testing checklist. This is because a misinterpretation at this stage can disrupt the whole process.
Analysis of business requirements ensures that the developed software solves the problem at hand. The business goals must be clearly defined at this stage. Only then can the user move towards testing the product against them. This stage is handled by the business team as they document all functional as well as non-functional requirements of the product, using:
- Software Requirement Specifications (SRS) document
- Business Requirement Document (BRD)
- Process Flow Diagrams
To understand this better, let’s look at an example.
If you are testing a website for business requirements, you should shortlist the basic purpose of the website. For instance, if an eCommerce website is under testing, the probable business requirements can be divided as follows:
- Successful signup
- Successful login
- Successful addition of items to the shopping cart
- The smooth functioning of the payment gateway
On the other hand, consider an example of an online banking application. The business requirements will be divided as:
- Successful signup
- Successful login
- Successful addition of a bank payee
- Successful transaction to the desired payee
Once the business requirements are analyzed, the creation of the user acceptance testing checklist template becomes a lot easier.
How Do You Plan for UAT?
In a UAT plan, a whole strategy is devised while outlining even the teeniest bits involved in the process. It outlines how the testing will be conducted, which test case scenarios and relevant approaches will be followed, the timeframe for each stage in the process, and the exit criteria for UAT.
A UAT plan created for a website or a mobile application would be quite the same. The reason behind that is this plan highlights the high-level requirements of the product. Therefore, an ideal UAT plan can be divided into three parts that include:
Entry Gates to UAT
This section highlights the pre-requisites of UAT. As mentioned earlier, this stage ensures that all basics required before entry into UAT are covered. For instance, the stages like unit, integration, and system testing have been done. In addition, the UI validations have been completed.
End to End UAT Validation
As the name suggests, end-to-end validation is a complete cycle of testing every aspect of the application. This stage tries to answer the following questions:
- Are all modules of the application functional as well as stable?
- Are crucial business purposes addressed as per the expectations?
- Is the performance of the application meeting the defined standards (response time, peak hours, etc.)?
- Is data integrity maintained throughout the application?
Exit Criteria for UAT
Exit criteria for UAT are the criteria that, when met, will allow the user to exit the UAT cycle. For any working website or a mobile application, the exit criteria on UAT will be the execution of a satisfactory cycle in which all functions are working as expected.
Therefore, the exit criteria for a shopping website UAT cycle would be the successful transactions from signup to checkout, whereas for a mobile application, they would be the smooth execution from signup to a successful financial transaction.
A well-formed UAT plan takes you to the next step on the checklist, i.e., identifying test case scenarios.
How Are the Test Case Scenarios Identified?
The success of this step is largely dependent on the first two. This is because business requirements are what translate into the test case scenarios. This can be better understood by considering an example.
We defined the business requirements for the online shopping website as successful signup, successful login, successful addition to the shopping cart, and smooth functioning of the payment gateway. Now, the test cases will be created around these requirements.
For instance, a test case scenario around successful signup would be the acceptance of digits in the username field. A test case will be created that the website should generate an error message if the user enters digits in the username field while signing up. In Gherkin, it would be created as:
GIVEN I am on the signup page
WHEN I navigate to the username field
AND I enter digits in the username field
AND I click the Signup button
THEN I should see an error message that says, “only alphabetical characters can be entered in this field.”
The same can be used for the signup page on the online banking application. Other test cases can be formed around the rest of the business cases.
How Is the Test Data Prepared?
What follows the identification of test case scenarios is the preparation of production-like test data. Typically, we recommend that live data should be used for UAT cycles.
However, some cases involve sensitive data. For instance, if you are running a test cycle on a product related to healthcare, it would involve public health information (PHI). To address the security concerns around it, techniques like data scrambling and data masking are used in order to prepare test data.
How Are the Test Cases Executed?
Once the test data is prepared, you execute the identified scenarios. Various tools are available that ease the automation of the prepared test cases.
Test management tools like JIRA provide interactive results of the execution of all test cases. The reports displayed include the count of passed and failed test cases for each enhancement made in the application. These reports also makes the user acceptance testing checklist template more elaborate.
How Can You Confirm That the Business Requirements Are Met?
Once the test cases are executed, reports for the results are prepared. They include defect logs and each result identifying where the test case failed.
Based on these results, the issues found are resolved. As the engineering team resolves the found bugs, the test cases are re-run.
This is done to make sure that nothing has been left to assumption. The product can be launched once the test cases pass. Business requirements are compared with the results found in these reports.
This aids in ensuring that critical functions of the product are working as expected and the product is stable. Successful execution of this step takes you to the exit criteria of user acceptance testing.
Wrapping Things Up
User acceptance testing is the last pillar in the pyramid on which functional testing stands. Therefore, it is an integral part of the testing process. This article took a deeper look into how a user acceptance testing checklist is prepared.
This checklist can be regarded as the reference for this testing type. This type of testing focuses solely on the realistic business flows of the application. This is why apart from the testing team, the end-user is involved in user acceptance testing.
How the test cases are prepared, and their execution is dependent on the nature of the product, you are testing and the test management tool being used.
This article was an extension of functional testing and its relevant types. New to functional testing? Visit the Diffy blog to learn more about functional and non functional testing before you start implementing them.
Already familiar with functional and non functional testing? Excellent! Then you can skip to the good part! Take Diffy for a test drive to see how it can help you perform faster and more accurate non functional testing!