An example of user acceptance testing (UAT): before Trello ships its archive-card feature, a few real users follow a written scenario. They open a board, archive a card, find it in the archive and restore it. Each step has an expected result. If every step passes and the business owner signs off, the feature goes live.
The principle of UAT is simple: real users check that the software does the job it was built for.
Running it well is harder, especially when several teams, testers and sign-off owners are involved.
In this article, we will guide you through a practical user acceptance testing example, illustrated by testing a Trello feature.
Towards the end of the article you’ll find this full test plan as a Word and PDF file, plus templates you can reuse for your own UAT.
These UAT testing templates give you a starting point for each step of the process.
UAT tests usually have the goal to check if the client’s needs are met with the developed solution. Usually, this is done by checking the contract between the customer and the supplier.
Therefore, User Acceptance Tests are necessarily undertaken at the end of the software development or software development life cycle.
This means that the developed software (e.g. web app or mobile app) must be largely feature-complete.
While the project team defines a UAT plan right at the beginning of a project (usually during the requirement definition), it executes the UAT test cases after development.
(source: sfsu.edu)
Before looking at examples, it helps to separate two terms that often get mixed up in UAT plans.
The first key difference in any UAT test plan is between validation and verification:
Basically, the system testing phase is verification while acceptance testing is validation.
In a UAT plan, a test scenario is a prescribed collection of test procedures or scripts that are conducted in a predetermined order to complete a significant functional process.
The test scenario is based on your workflow procedures and is performed by multiple test team members and can take a few days to complete.
Depending on what you are evaluating, there can be different UAT test scripts that may require a variety of UAT templates.
A UAT scenario template is where testers record what they did and what happened, so the team can act on the results.
Some of the UAT tool plan examples are given below.
When the team wants to test a particular aspect of the product, a single-purpose UAT template is the best option.
It outlines the test and its description along with the criteria and different parameters.
When there is a multitude of aspects to evaluate and assess, it is a much better idea to rely on a template that provides the option to prioritize different testing criteria.
This lets the team handle critical issues first and leave minor bugs for later.
Use this UAT template when you want customers or end users to take part in the testing.
This enables them to engage the target audience and collect relevant data when it comes to addressing customer-oriented issues.
When you need to test several applications or areas at once, an Excel-based user acceptance testing template keeps everything in one sheet.
This provides them with flexibility and enables them to accumulate data regarding their product.
A detailed UAT scenario template holds everything about a test in one place: the test description, expected results, specs and any attachments.
Testers use these templates to collect feedback for different systems such as desktop and mobile.
Writing effective test scripts is essential for successful user acceptance testing (UAT). Prior to writing UAT scripts, it is important to develop detailed user stories along with user acceptance criteria first.
These steps will provide the basic information you need to write effective scripts.
If you want UAT scripts to be user-oriented, it is important to make them the central part of the conversation.
Define real-world use cases (stories) across different user roles during the development process.
In Agile software development, user stories are simplified versions of the objectives that highlight how a particular feature is valuable to the end user.
Since user stories only form a part of the entire puzzle, you will also need to develop acceptance criteria to write effective UAT scripts.
There should be a set of brief acceptance criteria for each story. On one hand, stories highlight the requirements of a feature while on the other, acceptance criteria outline the conditions that need to be met for that feature to be classified as satisfactory.
In the Agile development framework, developers often use a scenario-oriented approach to create acceptance criteria which use GIVEN > WHEN > THEN format.
Once you have developed user stories and corresponding user acceptance testing templates and criteria, you are in a position to write effective UAT scripts.
The scripts should be written by involving the users who ensure that each script covers all the necessary requirements.
This also means that the required steps are also followed to test every condition. It is highly recommended that UAT scripts are reviewed by business users to avoid any bugs and errors.
User Acceptance Testing (UAT) scripts or test cases are typically written by Quality Assurance (QA) professionals, test analysts, or testing teams in collaboration with business analysts, developers, and end-users.
The goal is to create comprehensive scenarios that mimic real-world usage and cover various aspects of the software to ensure its functionality, usability, and alignment with user expectations.
Key contributors to UAT script and test case creation include:
The collaborative effort of these stakeholders ensures that UAT scripts comprehensively cover various scenarios, ensuring that the software is thoroughly tested before release.
User Acceptance Testing (UAT) is the stage where real users check that the software meets their functional requirements and the business needs behind them.
Unlike other testing phases, UAT looks at the end user’s experience and answers one question: is the software ready for a live environment? A UAT test plan keeps the tests in order and makes that answer easy to check.
A UAT test plan starts with scope and objectives.
That means naming the features to be tested and the stakeholders involved. Next come the acceptance criteria, which say what a passing test looks like. A UAT test plan template keeps this documentation consistent across scenarios.
Most teams work from a UAT test plan template in Word or a UAT test plan template in Excel. Both list the test cases, steps, preconditions, expected results and post-conditions, which makes progress and open issues easy to track. Adapt the user acceptance testing templates to the project, not the other way round.
If you’re new to UAT, start from sample UAT test plans. They show how to structure the plan, define test cases and set acceptance criteria. Good ones bring end users in early, so their input shapes the plan before testing starts. The Trello UAT test plan example below follows the same structure.
Your UAT plan template should include a high-level UAT plan which is fundamentally a master test plan that outlines why the testing is required for a large project.
The high-level UAT plan can include other UAT test plans across different levels featuring different objectives.
Having a UAT test plan template can help your development and testing team to ensure they are on the right track.
As the name suggests, detailed UAT planning is all about getting into the nitty-gritty of the software being developed.
Cause-and-effect test templates help here. They link each input to the result you expect, so wrong turns show up before they cost you a release.
This approach plans system testing and UAT in parallel. The test plan sets the approach, resources, scope and schedule for both.
Let’s assume Atlassian hired us to run a UAT test in Trello. Their development team wants to know whether the new archiving feature for Trello cards actually works for users.
It’s a simple feature, but we still want a proper UAT setup.
We’ll follow the UAT template from San Francisco State University.
First of all, we need to define the UAT scope of our particular test case.
As we are in charge to test the newly developed Archive feature of Trello cards, we define the list of features that we want to test, and the ones that are not being tested.
As seen below, this test case example focuses on Desktop tests only, while mobile tests are not included in this UAT test case.
After the definition of our UAT scope, we need to be aware of the assumptions and constraints of the test.
These assumptions and constraints include timing and available resources, as well as test documentation processes.
For our test case example of testing Trello’s archiving feature on desktop, constraints could be the operating system to be used and specific browser versions.
In addition, we must also clearly state the defined assumptions, such as how our test environment looks like, or how a tester should handle the error reporting.
UAT is the last check before release, so we look at the risks while planning, running and analyzing the test case.
In our example we could face some of the following risks during UAT:
The members of a UAT team vary from project to project. Together, the team coordinates the preparation and execution of all test cases.
Our UAT team will ensure …
The entry criteria ensure that everything is in place that allows the conduction of a user acceptance test. In order to start a UAT test for archiving feature of Trello, the following main entry and exit criteria must be available:
While all previous steps aim to ensure a well-executable test case, it’s now time to describe the actual test case itself to be successfully conducted by the UAT testers.
As User Acceptance Tests aim to verify if the business objectives and user requirements are met, a test case procedure could look like this:
Expected result:
In order to execute a test case, testers follow the described test cases step by step. Ideally, the tester can successfully execute the test.
However, one important part of UAT testing is to report unexpected behaviors of the software, or even real bugs.
Here’s the UAT example of Trello demonstrated with Usersnap:
With Usersnap, testers can report the planned UAT scenarios and anything unexpected they run into.
They capture a bug with Usersnap’s visual feedback widget, which works on any website.
Nobody has to leave the page to log a result, and the annotation toolbar shows exactly where the problem is.
After successfully completing the UAT test cases, every tester must provide their test results.
A well-documented UAT test case enables the product or project team to conclude the next steps and define the next actions depending on the test results.
Last, but not least, both the service owner and project manager, need to sign the conducted test cases.
After sign-off, the tested feature is good to go and available for production.
As with system testing, UAT governance keeps quality consistent across the project through clear entry and exit criteria and QA parameters.
This often includes end-to-end UAT validation to make sure critical business processes, stability, integration, data flow, and other technical functions are operational.
All in all, we’ve shown you all the relevant steps for conducting a UAT test case.
You can find the Word template document fully conducted UAT test case example for Trello here (and as a PDF version here).
From identifying the UAT scope and risks to describing and executing the particular test cases, this user acceptance testing example walks through every UAT task you need.
User Acceptance Testing (UAT) is a critical phase in software development, ensuring your product meets user needs and expectations.
To facilitate a smooth UAT process, here are some essential UAT documents, along with examples and templates, to guide you:
Adapt the examples and templates to your own project.
Usersnap offers these resources for the UAT process:
The Usersnap templates also run inside the product, so testers fill in the same structure every time.
Usersnap is a product evidence platform used by teams at Canva, WPEngine, Instacart, Microsoft and Hawaiian Airlines. In UAT, testers report what they find with a screenshot or a screen recording, and the browser, OS and page URL are attached automatically.
Every report lands in one project. Your team triages it there and sends it to Jira, Azure DevOps or another tracker. On Jira Cloud, statuses sync both ways, so testers and the business owner can see what was fixed before they sign off. If you run UAT across several teams, the triage and status updates you’d otherwise chase by hand happen in one place.
UAT is one stage where evidence comes from, not the whole picture. The same workspace also holds what happens before and after it: survey answers, in-app feedback and, with Channels (included from the Growth plan), support conversations and call transcripts. So what testers flag before launch sits next to what customers say once the feature is live, and the team decides on both.
For enterprise releases, that trail is the evidence behind the sign-off. When the same issue keeps coming back across UAT rounds, the Hypothesis Generator drafts what might be causing it from the reports themselves (included on Professional plans and above, available as an add-on on Starter and Growth). When someone asks why a feature shipped, you can point to each UAT report and what happened to it.
Start a free trial, no credit card needed.
User Acceptance Testing is the final major phase before launch. Real users try out the nearly complete product to check if it actually meets their needs. It’s not so much about finding technical glitches, but about making sure the product works for real users. If users approve, the product is set to go live.
UAT starts once the product is done, stable, and most major bugs are resolved. You plan for UAT early, but actual testing begins only after QA signs off and the right environment is ready.
A good UAT test case mirrors what an actual user would do. It’s straightforward, connects to a real business goal, uses realistic data, and clearly states the expected outcome.
With Usersnap, testers can report issues by taking screenshots, recording their screens, and automatically sending technical details. All feedback is collected in one place and connects with tools like Jira or Slack, so nothing gets missed and teams don’t waste time tracking down information.
Usersnap’s AI labels incoming feedback by topic and sentiment, groups similar reports and surfaces trends, so teams spot patterns before launch. Sentiment Sensor is included on Professional plans and above, and available as an add-on on Starter and Growth.
Every PM is being told to become an AI PM right now. Building got radically…
Imagine this: you're a Product Manager who has just shipped a feature you spent a…
Eighty percent of businesses believe they deliver a great customer experience. Eight percent of their…
Customer feedback analysis software turns scattered customer feedback (surveys, in-app messages, support tickets, reviews, and…
A voice of customer survey asks customers what they think, in their own words. Run…
If you are a product manager or SaaS founder, your hardest question isn't whether to…