User acceptance testing (UAT)
Last Updated: November 3, 2025
What is UAT?
During user acceptance testing (UAT), actual users test the service/tool/feature to make sure it can handle required tasks in real-world scenarios in the production environment. This helps us eliminate potential risks.
Goals of UAT
Conduct UAT if you need to:
Confirm all features exist as expected
Confirm the interface works as expected
Confirm data works as expected in relation to the new service/tool/feature, e.g.,
Production data from the API contains the expected content
When the user saves data in the new service/tool/feature, the data is saved and displays in the expected locations
Confirm that a user's production account works as expected in relation to the new service/tool/feature, e.g.,
The new dashboard shows the user's correct home address
NOTE: User actions in UAT should not have a permanent or lasting impact on users' accounts or access to benefits.
If you're working with another back-end system, figure out if you can back out, delete, or otherwise flag UAT test applications and accounts.
There are circumstances where it is not possible to conduct UAT without affecting a back-end system and the change or update made during UAT becomes a permanent action on the user's account. Please be sure to identify if this situation pertains to your UAT and if so, inform the user that the "test" becomes real once the action is complete.
In the Conversation Guide, include instructions for participants to back out or delete temporary data during the UAT session.
UAT logistics
Here are some key steps and tips to help you run a smooth User Acceptance Testing (UAT) process. These will make sure the team works well together and that you're well prepared for effective testing.
Team
The entire team should be involved in this process, including design, research, engineering, and product.
Designers and Product Managers should work together to create the UAT Conversation Guide.
Make sure your developers are sitting in the actual sessions so they can help troubleshoot and see what's going on
Scheduling
Schedule a UAT after you've fully tested the service/tool/feature in lower environments and are confident that it will work as intended in the production environment.
Plan in advance! And have a plan if your service/tool/feature doesn't pass the UAT.
Preparation
Consider creating a spreadsheet with tasks for each row and partcipant numbers for columns, to quickly keep track of what worked and didn't work in the session.
Considerations
Identify what you need to test and what type of user you need.
How many users are you looking to test with?
What scenarios do you need to cover?
How and where are you going to test?
Is it in person?
Is it remote and will you be able to record?
How long will it take?
Does the user need to do anything before the test? (Like create an account?)
Is there anything you need to tell the user upfront? (Like they will have to enter their SSN, see PII, confidential information, etc.)
Recruiting
VFS teams are responsible for their own recruiting. UAT is designed to test functionality in the production environment. It is not a usability test, so testing with Veterans is not always required.
Here are some examples to help you understand when you should test with Veterans vs when you might choose to test with a general (non-Veteran) audience.
Example 1 - Add new dataset to Facility Locator
The Facility Locator can be used without logging in.
It does not make use of user data (other than computer IP address).
The map view, list view, and detail view are features where being a Veteran does not change their usage, e.g., being a Veteran is not a trait that makes "Veteran map user" different from "general map user."
You can use a general audience for UAT.
Example 2 - Add personalization to Dashboard
The Dashboard can only be used by logging in to vets/va.gov.
Some acceptance criteria are "Show the user's applications in progress, prescription refills, claims and appeals, and secure messages on the Dashboard."
You should use a Veteran audience for UAT. And recruit people who have at least 1 of the above 4 items.
Example 3 - Add new 4142 form into the 526 claim flow
The 4142 is part of a larger user flow to create a 526 claim.
Your team is only working on, and testing, the 4142 form.
Some acceptance criteria are "Carry user data over from 526 fields into the 4142 form" and "Send new user data from 4142 to 526 form."
But asking participants to fill out the 526 form that surrounds the 4142 is tedious and does not help your team's work on the 4142 form.
You design the UAT so that the UAT moderator completes the surrounding 526 form for the participant. And passes control to the participant at the point where the 4142 form is triggered (and again at the point when the 4142 returns to the 526).
You can use a General or Veteran audience for UAT.
How many people should I recruit for UAT?
It depends on how many test cases you need and how specific those cases are. You're trying to validate that what is supposed to show up shows up, what is supposed to go through goes through.
A rule of thumb is ask for 3-5 per test case - if your thing works as intended for 3-5 people you have some increased confidence that your thing is working. If it doesn't work on P1 but your engineers can troubleshoot on the session and see what's wrong and fix it by P2, that's good too. Assume some attrition, so you also need to ask for enough participants that you actually get to cover every case.
And finding unicorn test cases is harder for our recruiters, so make sure you're specific in your test cases in your recruiting plan and that you allow for enough time for them to find the right people to match your needs. You may want to write your own screener questions that you give the recruiters to make sure you get the correct participants.
Process
To ensure a successful User Acceptance Testing (UAT) process, follow these key steps for recruiting participants, preparing your environment, and addressing issues uncovered during testing.
Work with your OCTO Lead to recruit participants. To recruit Veterans suited to test your product, you can try the following methods:
VA or contracting employees This list of Veterans willing to help with UAT testing can get you started. You could also put out a call within contracting companies as there might be folks who haven’t added their name to this list.
Stakeholders Ask the business owner or main stakeholder on the project to help recruit.
To recruit for a general audience, you can try the following method:
VA or contracting employees You can recruit any VA or contracting company employee who suits your non-Veteran requirements.
Start recruiting at least 2 weeks before you plan to run the research sessions.
Your code needs to be in the production environment for UAT, but not visible to users who are not part of your UAT.
You should be using feature toggles to hide your code when you push to staging.
Your code can be made visible in the production environment to a limited set of users via a password. You can reach out in the #vfs-platform-support Slack channel if you need help setting this up -- explain that you're planning a UAT in production and want to put your service/tool/feature behind a password.
When the UAT is completed, consolidate all the problems the UAT found.
Create Github issues for each problem found.
Fix all issues related to acceptance criteria.
Add any remaining issues to your backlog and prioritize them.