UAT Roadmap: Do’s and Don’ts

By Editorial Team on November 15, 2023

Part 3 – Do’s & Don’ts for Effective and Efficient UAT

User Acceptance Testing (UAT) is one of the final checkpoints before a study database goes live and is ready for data collection. Its purpose is to ensure that the study data collection system meets regulatory requirements and that the study design/build meets specifications set in the protocol.  

During UAT, test that the methods described within the protocol can be completed and that critical data points are captured in a manner that satisfies regulatory requirements.   

To help you navigate the UAT process effectively, we have compiled a list of UAT do’s and don’ts. Whether you’re a seasoned tester or new to the world of UAT, these guidelines will help you streamline the testing process and better ensure a successful outcome. 


1. DO Ensure Protocol <> Study Design Consistency 

Ensure that the study design/build mirrors the narrative of the protocol – that the correct data points are being collected at the right time, that the outputs of any calculations are correct, etc. Consistency between the two is paramount for regulatory compliance and accurate data collection. 

2. DO Work Off a Reusable Test Framework 

Some test scripts can be used across studies and within a study across forms. For example, a future date is not allowed in a visit date field, while a future date is permitted in an expiration date field. Craft or edit existing test scripts in a way that can be utilized in future testing. This reusability reduces redundancy and increases testing efficiency. 

3. DO Create a Generalized Testing Document 

If you do not already have one, develop a standardized testing document as a foundational UAT framework. This standardized testing document will include your reusable testing scripts. So, for each new study, start with your standardized testing document and then add the study-specific testing scripts as you design and build your new study database. Each study has its own set of unique specifications and requirements that will call for these unique testing scripts. 

4. DO Document and Track UAT Findings 

Thoroughly document your testing process. Detailed documentation makes it easier to recall the whats and whys – a clear record of actions and results, such as study build change request submissions, approvals (if needed), and records of implementation and verification by another party (i.e., not the person who implemented the requested update).  

5. DO Familiarize Yourself with Expected Behavior 

Acquaint yourself with the specifications and expected behavior of the study design. For example, if I enter the height and weight of the patient, I should get this dosing calculation value; or if I mark the patient eligible for the study, I should be able to see the forms for future visits. Understanding these parameters is crucial for practical testing. 


1. DO NOT Have Your Builder Perform UAT 

Refrain from having the study builder perform UAT. Builders are too close to the study design/build to be objective testers – they are very, very familiar with the study design, build, and workflow and may overlook issues. However, because they are most familiar with the study build and how it relates to the study protocol, a study builder may assist in creating testing scripts to be used during UAT (see Do #3). They should also ensure that study build change requests made during UAT are documented (see Do #4).  

2. DO NOT Ask “Friends” to Test 

Opt for testers not closely involved in the study build’s development. And while friends can provide valuable feedback, UAT should be conducted by impartial professionals who can evaluate the study design/build without personal bias. Unbiased testing from individuals unfamiliar with the study design/build but familiar with the protocol and organization processes is essential for uncovering any hidden issues. 

3. DO NOT Be Afraid to Break the Build 

Don’t be afraid to rigorously test the study build, including edge cases and boundary scenarios. Identifying weaknesses and breaking points is a critical part of the testing process. 

4. DO NOT Write Vague Tests 

Avoid creating tests that lack clarity or specificity. Tests should be descriptive enough to pinpoint issues precisely. Vague tests can lead to ambiguous results and hinder the troubleshooting process. 

5. DO NOT Run Unproductive Tests 

Don’t waste time on tests that cannot be completed or yield no meaningful results. Inefficient tests only add complexity, mental fatigue, and confusion to the testing process. 


Good vs Bad Design 

Now, let’s examine real-world examples of good and bad design practices in User Acceptance Testing (UAT) to better understand how design choices can significantly influence the testing process. 

Bad Script Design  

The observation date field on Visit 1’s Physical Exam form must not be in the future.  

Why Bad?  

If you require that all observation dates in the study cannot have future dates entered, you’ll need to create a testing script for every form/field that holds an observation date.  

Caveat (AKA Why Good?):  

In theory, this is a far more conservative approach, as the user will test each data point per the script. However, it’s arduous for the test writer and testers due to factors such as mental fatigue. Additionally, observation dates on new forms added after testing began might be missed.  

Good Script Design  

All observation dates have “not future” edit checks applied (i.e., they cannot happen on a date that follows the current day).  

Why Good? 

This covers every observation date within the study and does not require fine-tuning for each study build. This can be added to a generalized testing document and applied to every observation date field in any form going forward. 

Caveat (AKA Why Bad?): 

Without a specific testing script, the user must know that they must perform this test whenever they encounter an observation date, and it does not apply to all dates (e.g., an expiration date). 

One More Thing… 

Document general UAT requirements in a UAT SOP (Standard Operating Procedure) – a document detailing overarching UAT procedure (e.g., a tester should not be involved in study building, but should be familiar with your study) and requirements of regulatory authorities. 

The Do’s and Don’ts we discussed are your guiding principles for effective and efficient UAT. These help you navigate the process, whether you’re a seasoned tester or new to this domain. 

Learn More About UAT

Navigating User Acceptance Testing (UAT)

Looking to learn more about User Acceptance Testing (UAT)? Explore our collection of resources to understand how UAT ensures that your study database meets study requirements and expectations of end-users and complies with applicable regulations.