What Is UAT? User Acceptance Testing Meaning, Process and Examples

User acceptance testing (UAT) is the final stage of testing before launch, where real users or stakeholders validate that a product works in real-world conditions. It helps teams catch workflow issues, unclear requirements, user experience challenges, and last-minute blockers before they affect customers.

In this guide, you’ll learn what UAT is, who should be involved, and how to run it effectively.

What is user acceptance testing?

User acceptance testing is the final check that a product is ready for the real world.

Instead of focusing on bugs alone, UAT validates whether users can complete real tasks successfully, whether the product meets business requirements, and whether stakeholders are comfortable approving it for launch.

That’s why UAT matters: software can pass QA and still fall short in practice. A workflow might be confusing, an approval step might be missing, or a feature might technically work without meeting the user’s actual needs.

By testing realistic scenarios before release, teams can catch those issues early and launch with more confidence.

What is the purpose of UAT?

The purpose of user acceptance testing is to validate two critical aspects:

1. User requirements. Does the app meet user expectations? Is it easy to navigate and use?
2. Business requirements. Can the app handle real use cases efficiently and effectively?

In other words, the software should help users accomplish real-world tasks without hurdles.

Validation of these requirements usually comes in the form of stakeholder sign-off or approval (the "acceptance criteria").

For example, when your client is satisfied with the final version of the app or website.

UAT vs QA: what’s the difference?

Internal QA focuses on technical issue resolution and is executed by the QA team, whereas user acceptance testing is performed by end-users or stakeholders to ensure the software meets real-world expectations.

Here’s a table outlining the key differences between UAT, QA, and other common testing phases:

Both QA and UAT contribute to software quality, but they occur at different stages of the lifecycle and answer different questions. QA checks whether the software functions correctly, while UAT confirms that it supports real-world user and business requirements. Put simply: QA ensures a functional product, and UAT ensures a viable one. At the end of the day, though, user acceptance testing is still a form of quality assurance.

Here's a diagram of the development lifecycle to visualize QA and UAT's position in it.

To further understand the difference between the two, let’s take a standard sign-up flow as an example.

Typical test cases in the internal QA phase for a sign-up flow might include:

• Are all input fields and buttons usable?
• Does the email verification function run properly?
• Are there any unexpected bugs at any point in the workflow?

UAT test cases, however, aim to answer user-centric questions such as:

• Are testers filling out the correct information?
• Do they understand what’s happening when being redirected to the login page?
• Are they opening their email and going through the verification steps

Read more in our blog comparing QA vs. UAT.

What are the benefits of user acceptance testing?

There are plenty of benefits to running UAT, primarily that it reduces the risk of you releasing websites, web pages, apps, products, and features that are not of a high enough quality. If you're still on the fence, here are some more reasons you should be running UAT processes:

1. Early issue detection. While developers can catch many technical issues during code reviews, user acceptance testing brings the perspective of an end-user to identify potential confusion.
2. Fresh perspective. Developers can sometimes miss overarching usability or flow issues. First-time users provide fresh insights. If they find any aspect of the app unintuitive, they'll raise it.
3. Real-world environment. UAT offers a production-like setting for testing. By mirroring your production database, you get to observe genuine user interactions and behaviors, rather than just hypothetical or "expected" use scenarios.
4. Broad testing scope. With multiple testers, you amplify the chances of spotting even the most obscure issues and bugs.
5. Mitigate risks pre-launch. Identify and rectify significant issues, such as confusing user interfaces, security vulnerabilities, or critical bugs, before the software reaches the broader audience. Successful user acceptance testing ensures your app is robust, secure, and user-friendly when it goes live.
6. Objective feedback. UAT often involves users who are new to your software and lack any biases. They don’t have prior notions about its functionalities or design, and so their feedback is candid and impartial.

Who performs UAT?

User acceptance testing is performed by the end-users: the people who will actually use, approve, or rely on the product in real-world conditions.

That usually includes end users, clients, business stakeholders, product owners, or subject matter experts. Their role is to validate that the product supports real workflows, meets business requirements, and is ready for release.

The QA team may help organize the process, but they are not usually the people who perform UAT. In most organizations, QA is responsible for preparing the test plan, setting up a UAT environment that closely mirrors production, writing or reviewing test cases, and making sure issues are documented clearly.

In other words, QA facilitates UAT, while users and stakeholders provide the final validation.

Who participates can vary depending on the project. For example, a client may handle sign-off in an agency project, while internal business teams may run UAT for an enterprise rollout. For a website launch, UAT often involves marketers, content and design teams, regional stakeholders, legal reviewers, or anyone responsible for checking that the site works as expected before go-live.

The most important rule is simple: the people performing UAT should be close enough to the real use case to judge whether the product is actually ready.

Types of user acceptance testing

There are several different types of user acceptance testing, depending on what you need to validate before launch.

Some types focus on whether the product works for real users. Others focus on whether it meets operational, contractual, or legal requirements.

The main types of UAT include:

• Alpha testing involves testing the product internally before it is exposed to a wider group of users.
• Beta testing involves releasing the product to a limited group of real users to gather feedback in real-world conditions.
• Contract acceptance testing validates that the software meets pre-agreed specifications and deliverables.
• Operational acceptance testing checks whether the product is ready for day-to-day use, support, maintenance, and handover.
• Regulation acceptance testing verifies compliance with legal, regulatory, or industry-specific requirements.‍

It's also worth clearing up a common point of confusion: unit testing, integration testing, system testing, regression testing, and functional testing are not subcategories of UAT. They are separate software testing phases that happen earlier in the software development lifecycle.

Meanwhile, black box testing, though not a type of UAT specifically, is a testing approach that can be used during different stages of the software testing process, including UAT.

Read more: 6 Types of User Acceptance Testing Explained

In this guide, we'll focus on two of the most common and practical UAT types: alpha testing and beta testing.

Alpha testing vs. beta testing

Alpha testing and beta testing are two distinct testing phases, but they're both valuable parts of the UAT process. Alpha testing usually happens first and helps teams catch major issues before the product reaches real users. Beta testing comes later and focuses on validating the experience with a limited group of actual users.

Here's how the two compare:

With a combined UAT, website feedback, QA, and bug tracker tool like Marker.io, you can manage UAT testing throughout the entire process.

In alpha testing:

• Your testing team is usually internal. That may include QA, product, support, business analysts, or other stakeholders.
• Critical issues may still exist. Broken workflows, missing functionality, and major usability problems can still appear at this stage.
• It is usually more controlled than beta testing. The goal is to test in a safe environment and fix the biggest issues quickly.
• Your main objective is to prepare the product for broader exposure by improving stability, usability, and overall readiness.

In beta testing:

• A limited group of real users becomes your testing team. These beta testers should reflect your target audience and intended users as closely as possible.
• The product is usually more stable by this point. The most serious issues should already have been addressed during alpha testing.
• This phase is often shorter and less controlled. The goal is to observe how the software behaves in more realistic conditions.
• Your main objective is to collect feedback, confirm that the product meets user expectations, and validate whether it is ready for the final stage before launch.

One important note: not every team runs both phases formally. Some products move straight into a lighter beta program, while others keep alpha testing entirely internal. But the logic stays the same: alpha testing helps you stabilize the product, and beta testing helps you validate it with real users.

How to conduct user acceptance testing: A step-by-step guide

In this section, we'll delve into a real-world example of UAT when we released our domain join feature.

However, it's important to start with step zero: making sure you're ready for UAT in the first place.

UAT prerequisites: when is software ready for UAT?

‍Before starting UAT, make sure:

• Requirements and acceptance criteria have been approved.
• Development is functionally complete.
• Unit, integration, system, and regression testing are complete.
• No unresolved release-blocking defects remain.
• The UAT environment is stable and production-like.
• Representative test data and user accounts are available.
• Testers, roles, and timelines have been agreed.
• Defect-reporting and sign-off processes are ready.

These prerequisites are often formalized as entry criteria: the conditions that must be met before UAT begins. The flip side is exit criteria: the conditions that must be met before UAT can end and the software gets sign-off. Here's how the two compare:

Now, let's break down the key steps:

1. Define project scope and acceptance criteria

The first step is to clearly define the project scope and objectives and document them.

Throughout the user acceptance testing process, you should consistently go back to your documentation to verify scope, customer needs, and others.

With this documentation, you can verify at any point that:

1. ‍Technical objectives have been met.
2. ‍The pain point is gone.

All in all, defining your project scope saves a ton of headaches.

• The whole team is aligned: “This is what we’re trying to achieve, and this is how we’re going to do it.”
• All information is centralized: If there's ever uncertainty about the software’s behavior during testing, you can refer back to this foundational document.‍
• You don’t go over (or under) scope: Avoiding unplanned features during testing is crucial.

2. Set up a UAT environment

The ideal way to observe real users testing your app would be in production, right?

But you can’t push a new version of your software to prod and “see what happens” just like that... for obvious reasons.

The next best thing is a staging environment. A UAT environment is usually a staging or pre-production environment that closely mirrors production and is used for user acceptance testing.

A staging environment lets you test in-production-like conditions. Teams typically use masked or synthetic test data rather than real customer data to avoid privacy and compliance risks.

For example, at Marker.io, we test changes on staging.marker.io, a password-protected version of our app. Stakeholders can then easily log on and start identifying UAT issues.

The same logic applies when you run UAT tests on a larger scale. Send a URL and login credentials to your beta testers (via e-mail or otherwise) and tell them to try and break your app!

There are a couple of other added benefits:

• Save time. When your product is in staging, you can push changes and fixes immediately – it doesn’t matter if the whole app breaks.
• Protect live data. Beta user inadvertently caused a crash? Your production database is safe.
• Better overview. Locally testing your components is great for seeing what they do independently. But it's only through staging that you can truly see how they integrate within the full software.
• Easier testing. Suppose you forgot to update a package in production, or a function working completely fine in local suddenly breaks. These issues will show up in staging already.

For UAT, it is paramount that your staging settings mirror your production settings.

Don’t fall into thinking, “Well, this is just another testing environment. It doesn’t need to be perfect.” Your staging environment should be an (almost) exact copy of production.

With an accurate clone, if something doesn’t work in staging, it won’t work in production either.

3. Pre-organize feedback

You will also need a system to categorize and manage user feedback.

We suggest categorizing feedback into two main categories:‍

1. ‍Feedback that requires discussion. Complex usability issues and the odd challenging bug that’s slipped through. All issues that will require a meeting with several team members.‍
2. Instant action feedback. Wrong color, wrong copy, missing elements – one-man job problems.

4. Decide how testers will record and manage feedback

Quality reporting during the software testing process is tedious.

For every usability issue, you have to:

1. Open the screenshot tool, capture the issue.
2. Open the software to annotate the screenshots and add a few comments.
3. Log into a project management tool.
4. Create a new issue.
5. Document the issue.
6. Add technical information.
7. Attach a screenshot.
8. Share with the right colleague or team

For a seasoned QA expert, this is a walk in the park. But this is a user acceptance testing guide and when you do UAT, you are bound to involve non-technical, novice QA testers – or actual software users.

Teams may use a dedicated UAT tool, a test management platform, or an issue tracker. For website projects, we've found it easiest to install a website feedback widget like Marker.io on the staging site.

A UAT tool enables your testing team to report issues and send feedback straight from the website, without constantly alt-tabbing to email or PM tool. It’s faster and more accurate for all parties involved.

On the tester side, it’s a three-step process:

1. Go to staging, find a problem.
2. Create a report and input details.
3. Click on “Create issue” – done!

5. Create scenarios and test cases

In user acceptance testing, test scenarios and test cases should reflect real business processes, user requirements, and real world scenarios. By this point in the software development lifecycle, earlier testing phases like unit testing, integration testing, system testing, and functional testing should already be complete. The goal of UAT is different: to confirm the software meets business objectives and user expectations.

Start with broad user scenarios, then turn them into specific UAT test cases.

For example, a website UAT testing process might include scenarios like:

• A first-time visitor signs up for an account
• A returning user resets their password and logs back in
• A customer completes a checkout flow
• A marketer publishes a new landing page in the CMS
• A regional stakeholder reviews localized content
• A legal reviewer checks cookie consent and policy links before launch

Each acceptance test should connect back to a requirement, user story, or workflow in your UAT test plan. Include the goal, steps, expected result, actual result, and any test data needed.

A complete UAT test plan should include:

• Objectives and scope
• Business requirements and acceptance criteria
• Features and workflows included or excluded
• Roles and responsibilities
• Entry and exit criteria
• Environment and test data requirements
• Test scenarios and cases
• Testing schedule
• Defect severity and prioritization rules
• Retesting and regression process
• Reporting and sign-off authority

Good test data matters. If your testing environment uses unrealistic content or permissions, your test results will be less useful. The closer your separate testing environment is to the production environment, the more accurate your UAT testing process will be.

You may also need broader checks like operational acceptance testing, contract acceptance testing, or regulation acceptance testing, depending on the release.

6. Recruit, onboard, and brief testers

The people who perform UAT should represent the product’s real users.

That usually means end users, clients, business stakeholders, subject matter experts, or business analysts who understand the product’s workflows and business requirements. The right UAT team depends on the project, but the goal is always the same: involve people close enough to the real use case to judge whether the software meets user needs.

For a website launch, that might include marketers, content editors, legal reviewers, regional teams, or support leads. Some teams also use alpha testing internally first, then expand into beta testing with customers or beta testers who reflect the target audience.

Once you’ve selected testers, onboard and brief them properly. Share the test plan, timeline, defined acceptance criteria, login details for the UAT environment, required test data, and instructions on how to provide feedback.

Some testers should follow structured test cases. Others should have room to explore naturally. That balance usually leads to better end-user testing and more useful feedback.

7. Run tests and capture feedback

This is the point where UAT execution begins.

Ask testers to work through the defined scenarios in realistic conditions, using realistic data. The aim is not just to check whether the software works, but whether it supports real users, real workflows, and the needs of the final release.

During UAT testing, encourage testers to flag anything that blocks a task, creates confusion, breaks content or journeys, or falls short of user expectations. That includes usability problems, broken links, missing content, inconsistent messaging, and cross-browser issues.

To keep the testing process efficient, every report should include:

• What was tested
• The steps taken
• The expected result
• The actual result
• Screenshots or video where needed
• Browser, device, and environment details

Many UAT tools like Marker.io offer session replay as standard, while browser, device, and environment details are shared automatically with issues

Clear reporting helps the development team and quality assurance team act faster. It also makes the software testing process easier to manage across the full UAT cycle.

The goal is not to collect the most tickets, it’s to gather actionable feedback that shows whether the software meets business requirements and is ready for production.

8. Triage defects, retest, and sign off

Once feedback comes in, the next step is defect management.

Not every issue found during user acceptance testing UAT has the same impact. Some defects block release. Others can wait until later. A strong UAT process means triaging issues based on severity, business impact, and whether they break the agreed acceptance criteria.

Most teams group findings into blockers, high priority, medium priority, and post-launch improvements. From there, the development team fixes the most important issues, and the UAT team coordinates retesting.

Retesting matters. A fix is only complete once the original scenario has been tested again and the team confirms the software behaves as expected in the UAT phase.

Sign-off should happen only when key business objectives and user requirements have been validated, critical defects have been resolved or accepted, and stakeholders are confident in the release.

A successful UAT does not mean finding zero issues. It means the team understands the remaining risk, confirms operational readiness, and completes the final quality check before go-live.

9. Document everything for future UAT requirements

Following your UAT process, do a retro to understand exactly what worked and what didn’t.

Record those learnings with the other UAT documentation you’ve created so that you can come back to it for future user acceptance testing work.

User acceptance testing best practices

This checklist is a recap of everything we’ve discussed in this post and contains all the best practices for user acceptance testing.

1. Design project scope and objectives. Have a clear plan for the new feature or software that you are releasing. During UAT, come back to this document to ensure pain points have been properly addressed.
2. Set up a UAT environment. Run tests in a safe environment. Staging is a perfect copy of your production, the ideal playground for alpha and beta testers.
3. Plan for the feedback you want. Categorize expected feedback into issues that can be handled quickly, by one person, and those that require more consideration.
4. Select a user acceptance testing tool. Find a solution that enables end-users to simply and intuitively record issues and share them with your team.
5. Create relevant scenarios. Identify what broad scenarios users may encounter that you can then run through during the UAT process.
6. Recruit and brief testers. In alpha testing, tell testers about the new feature you’ve built in detail. Make it clear what the business objective is, and what you expect to discover from this testing.
7. Run user acceptance tests. Have testers run through the scenarios you’ve defined in realistic conditions, so you can capture issues that could occur in a real-world environment. Encourage testers to flag anything that they see as an issue.
8. Triage defects, retest, and sign off. This stage is the purpose of the entire UAT process: Actually fixing what doesn’t work.
9. Document all steps. Keep tabs on what was fixed, what needs working on, expected challenges in the next iteration, and how the process can be improved.

Great user acceptance testing starts with great organization, so here’s a downloadable version of the best practices checklist you can keep at hand for your next user acceptance testing project.

User acceptance testing checklist

Here's a simple checklist you can download and use to make sure you have completed every important UAT step.

Visit our dedicated blog for a more complete user acceptance testing checklist. Alternatively, you can use one of our user acceptance templates to start your own UAT planning. You can download the full test plan template in this Google Doc.

User acceptance testing examples for websites

Website UAT follows the same core principles as other forms of software testing, but the focus is often on cross-functional workflows, content, and user journeys.

Here are a few common user acceptance testing examples for websites:

1. Sign-up and login flows

Business requirement: New visitors must be able to create an account, verify it, and log back in without friction.

Tester: A business stakeholder or recruited beta tester acting as a first-time visitor.

Test steps:

1. Create a new account with realistic test data.
2. Open the verification email and complete verification.
3. Log out, then log back in.
4. Reset the password and log in with the new one.

Expected result: The full journey completes smoothly, with clear messaging at every step.

Possible UAT findings: Confusing verification emails, unclear error messages, broken redirects, or password reset failures.

2. Lead generation forms

Business requirement: Prospects must be able to request a demo, and the sales team must receive correctly attributed lead data.

Tester: A marketer or sales operations stakeholder.

Test steps:

1. Visit the website from a tracked campaign link.
2. Complete the demo request form with realistic test data.
3. Confirm the thank-you message appears.
4. Check that the contact appears in the CRM.
5. Verify source, campaign, and consent properties.

Expected result: The user receives confirmation, and the CRM contains a correctly attributed, compliant lead.

Possible UAT findings: Broken form routing, missing attribution data, incorrect confirmation copy, or failed CRM sync.

3. CMS publishing workflows

Business requirement: Editors must be able to create, review, and publish content without developer involvement, following the approval process.

Tester: A content editor or marketing stakeholder.

Test steps:

1. Log in to the CMS with editor permissions.
2. Create a new page using an approved template.
3. Submit it for review and approval.
4. Publish the approved page.
5. Check the live page renders correctly across devices.

Expected result: The page moves through the full approval workflow and publishes correctly, with the right permissions enforced at each step.

Possible UAT findings: Missing permissions, broken approval steps, template rendering issues, or unpublished assets.

4. Checkout or conversion journeys

Business requirement: Customers must be able to complete a purchase or upgrade from start to finish.

Tester: A business stakeholder or existing customer acting as a first-time buyer.

Test steps:

1. Browse to a product or plan page.
2. Add the item to the cart or select the plan.
3. Complete checkout with test payment details.
4. Confirm the order confirmation page and email.
5. Verify the order or subscription appears in the back office.

Expected result: The full path from browsing to confirmation works, with accurate pricing, tax, and messaging throughout.

Possible UAT findings: Payment errors, incorrect totals, missing confirmation emails, or orders not syncing to internal systems.

5. Localization and compliance checks

Business requirement: Regional versions of the site must display correct translated content, forms, and legally required messaging.

Tester: A regional stakeholder or legal reviewer.

Test steps:

1. Visit the site from (or switch to) a target market.
2. Review translated content, currency, and regional formatting.
3. Submit a localized form.
4. Check cookie consent, privacy links, and policy pages.

Expected result: Each market shows accurate localized content and compliant consent flows.

Possible UAT findings: Untranslated strings, wrong regional forms, missing consent banners, or outdated policy links. This may overlap with regulation acceptance testing or contract acceptance testing.

6. Launch readiness

Business requirement: The site must be operationally ready to go live, beyond visible content and features.

Tester: A WebOps, marketing ops, or technical stakeholder – though this overlaps with operational acceptance testing, stakeholders often validate it during the same UAT window.

Test steps:

1. Test key redirects from old URLs.
2. Verify analytics and tracking fire correctly.
3. Check search indexing settings and sitemaps.
4. Confirm support and sales handoffs work end-to-end.

Expected result: Everything behind the scenes is ready for launch, not just the visible pages.

Possible UAT findings: Broken redirects, missing analytics events, pages blocked from indexing, or handoffs failing silently. This is where website UAT can overlap with operational acceptance testing.

Common UAT challenges

When conducting user acceptance testing, companies can run into the following challenges:

• Poor UAT documentation. A lack of scope, undefined objectives, and no UAT testing plan will cause issues during testing. Getting your entire team (and testers) aligned is crucial for success with UAT.
• Not enough extensive internal QA. Development teams can save themselves a lot of admin time by getting rid of several bugs upstream, rather than leaving it for the user acceptance testing phase. Ideally, UAT testers should operate in a nearly bug-free environment.
• Lack of a strong testing team. Pre-screen your testers and ensure they are the right target audience for your software. Train them in the different tools and processes you use for testing, and align them with your goals.‍
• Not using the right tools. For large-scale projects in particular, asking your testers to use Excel, Google Docs, or emails for their reports is a recipe for disaster. Prepare solid bug tracking and reporting solutions to make it easier for everyone involved.

When to use UAT testing services vs. UAT tools

A tool gives you the system; a service gives you the people and process to run it. Use a UAT tool like Marker.io when you have a clear testing strategy, available testers, and someone internally to manage the process. Business users report issues directly from the website, developers get full context, and nothing gets lost in email or spreadsheets.

Consider a UAT service or agency when:

• You're launching across multiple markets or products.
• Your team doesn't have time to recruit, brief, and manage testers.
• You need neutral feedback from people who weren't involved in the build.
• You have complex compliance, localization, or approval requirements.

In short: use a tool when you can run UAT yourself. Use a service when you need extra capacity or independent validation.

Wrapping up...

UAT’s meaning, in short: User acceptance testing gauges how well your app or website meets customer needs and business requirements.

To conduct effective UAT, ensure you’re collecting that information in the best possible way. In other words, have a system.

The resources and ideas shared in this post are your guide toward building that system, with guidance to help you put together your next user acceptance testing session.

Frequently asked questions

When does UAT happen in the software development lifecycle?

User acceptance testing happens near the end of the software development lifecycle (SDLC), after the product has already passed the main internal software testing stages.

In a typical SDLC, teams move through requirements, design, development, and then several testing phases such as unit testing, integration testing, system testing, and quality assurance. Once those checks are complete and the product is stable enough to validate in real-world conditions, the UAT phase begins.

That makes UAT one of the last steps before launch.

How to build the right UAT team?

Ownership varies by organization, but a typical UAT team includes:

• A product owner or business sponsor who defines business outcomes and approves sign-off.
• A business analyst who converts requirements into scenarios and acceptance criteria.
• A QA or UAT lead who plans the cycle, environment, reporting, and defect workflow.
• Testers who execute realistic scenarios, usually end users, customers, or subject matter experts.
• Developers who resolve defects and support diagnosis.
• A project manager who coordinates timing, dependencies, and communication.

Smaller teams often combine several of these roles into one.

Can you automate user acceptance testing?

To an extent, yes. Instead of manual test scenarios, simply push releases to your test environment.

Then, run a couple of automated test cases that’ll test the functionality of your app.

However, we recommend having actual software users test your website. At the end of the day, testing with actual users is the most reliable way to confirm your website, app, or product meets real-world needs before release.

What is a user acceptance test? (with examples)

A user acceptance test is a type of testing run during UAT execution.

The goal is to find out if the end user has an easy time completing the test and if they run into any issues.

Here’s a user acceptance testing example:

• Sign up for the tool and upgrade to our “Standard” plan.
• Try to create a project and add a couple of tasks to this project.
• Attach a file to task #3.
• Invite your team to join you.

Who writes UAT test cases?

In most organizations, the QA team or a business analyst handles test management and writing test cases, though ownership varies by team.

They manage the entire process:

• Writing test scenarios that satisfy business requirements
• Setting up a staging environment
• Onboarding testers for user acceptance testing
• Analyzing results of test cases

What are some tools that help successfully perform UAT?

There are many tools that help assist your user acceptance testing process.

We recommend having:

• An error monitoring system like Sentry
• A user acceptance testing solution like Marker.io
• A test case management system or bug tracking tool like Jira, Trello, etc.

Looking for more UAT Tools? Check out our list of the best user acceptance testing tools out there – and get even more insights from your users.

What does UAT stand for?

UAT stands for user acceptance testing. It's the final validation phase where intended users or business stakeholders confirm that software supports real-world workflows and meets agreed business requirements before release.