User Acceptance Testing (UAT) is the final testing stage before deployment, during which future users and business representatives verify whether the finished software meets the organization’s real needs. Unlike technical testing, it does not answer the question “does the system work correctly?”, but rather “did we build the right product?”. It is performed not by programmers or the QA team, but by end users, business process owners, and product owners — the people who will use the system every day.

What is acceptance testing (UAT)

UAT is a formal verification of whether the delivered software is ready to be handed over to users. These tests focus on compliance with business requirements and real-world usage scenarios, not on the correctness of the implementation. It is the moment when the documentation, requirements, and promises from the analysis phase meet the daily work of the people who are actually supposed to use the system.

The key feature of UAT is its perspective. The earlier stages — unit, integration, or system testing — look at the product “from the inside”, through the eyes of engineers. Acceptance testing looks at the product “from the outside”, through the eyes of the business. That is why UAT scenarios are written in the language of processes, not technical functions: “register a new customer and issue an invoice”, not “check the validation of the tax ID field”. This distinction is the foundation of effective software acceptance and part of the broader software verification process, in which UAT is the final link.

UAT vs. system testing — what is the difference

System testing and acceptance testing are often confused, even though they have different goals, different performers, and a different moment in the project cycle.

System testing is performed by the QA team. It verifies whether the complete system works in accordance with the technical specification — from performance and security to integrations and error handling. This is verification: “are we building the product correctly?”.

Acceptance testing is performed by the business side. It verifies whether the system solves a real problem and is fit for work. This is validation: “are we building the right product?”.

The relationship between them is sequential. Completed and accepted system testing is the entry condition for UAT — there is no point in involving business users until the product has successfully passed technical verification. Put briefly: system testing filters out implementation errors, and UAT confirms business value. You will find a broader treatment of all testing levels in the guide on types of software testing.

Types of acceptance testing

Under the heading “acceptance testing” lie several distinct types, which differ in their goal and in who carries them out.

Alpha and beta testing. Alpha testing takes place internally, in the vendor’s controlled environment, before the product reaches the customer. Beta testing is performed by a limited group of real users in their natural environment — the final check before broad deployment, providing feedback from real-world use.

Business Acceptance Testing (BAT). This verifies whether the system carries out business processes and delivers the expected value. It is the most common form of UAT in enterprise projects — it answers the question of whether the software supports the daily work of a department or the organization.

Contract Acceptance Testing (CAT). This verifies whether the delivered solution complies with the terms of the contract and the agreed specification. It has direct formal and financial consequences — a positive result often triggers acceptance and payment.

Operational Acceptance Testing (OAT). This focuses on operational readiness: backups, recovery procedures, monitoring, updates, and security. It verifies whether the maintenance team is able to support the system in the production environment. Here UAT often intersects with software security testing, which verifies the system’s resilience before it is approved for operation.

Regulatory acceptance testing. In industries such as finance, healthcare, or public administration, it confirms compliance with the regulations and standards in force in a given sector.

Who participates in UAT

The composition of the UAT team determines its credibility. The key principle is this: acceptance testing is led by the commissioning party, not by the team that built the system.

  • End users — the people who will actually work with the system; their opinion is the most valuable, because it stems from daily practice.
  • Business process owners — responsible for ensuring that the system reflects the actual flow of processes in the organization.
  • Product owner / project sponsor — makes the acceptance decision and bears responsibility for the sign-off.
  • Business analysts — help translate requirements into test scenarios and interpret discrepancies.
  • UAT coordinator — organizes the course of the tests, collects reports, and keeps the schedule on track.

The development and QA teams remain in a supporting role: they prepare the environment, explain how features work, and handle reported defects. They should not, however, perform the acceptance tests themselves — that would undermine their independence.

The UAT process step by step

Effective acceptance testing is a process, not a single event. In practice, it runs through six stages.

  1. Planning. Defining the scope, goals, schedule, and responsibilities. At this stage, the UAT plan and the definition of entry and exit criteria are created.
  2. Scenario design. Preparing test cases based on real business processes and requirements. Every scenario should have a clearly described expected result.
  3. Environment and data preparation. Ensuring an environment close to production and representative test data. Testing on unrealistic data is one of the most common reasons errors are overlooked.
  4. Test execution. Users walk through the scenarios, recording the results and any deviations from expectations.
  5. Defect management. Reported issues are classified by priority, passed to the team and fixed, and then verified again (retests).
  6. Acceptance decision. Once the exit criteria are met, the sponsor formally accepts the software (sign-off), which opens the way to production deployment.

A well-run UAT process is repeatable and documented — thanks to this, the deployment decision is based on facts, not on intuition.

It is also worth establishing in advance what happens when the tests do not end in full success. Not every defect blocks deployment — some can be accepted with a plan to fix them in the next iteration, while others require putting the acceptance on hold. A clear escalation path and an agreed defect classification (critical, major, minor, cosmetic) make it possible to make these decisions quickly and without emotion. It is also good practice to keep a short log of UAT sessions — a record of what was tested, who tested it, and what conclusions were drawn — which becomes supporting evidence at acceptance and a starting point for improving the process in subsequent projects.

Acceptance criteria — the foundation of objective acceptance

Acceptance criteria are unambiguous, measurable conditions that the software must meet in order to be accepted. Without them, UAT turns into a subjective “I like it / I don’t like it” discussion, and project acceptance gets stuck in endless negotiations.

Well-defined acceptance criteria are:

  • Concrete — they describe exactly what is supposed to happen, with no room for interpretation.
  • Measurable — they make it possible to state unambiguously whether a condition has been met (e.g., “form response time under 2 seconds”).
  • Set in advance — defined before testing begins, ideally already at the requirements-gathering stage.
  • Tied to business value — they reflect what really matters to the user and the organization.

In practice, acceptance criteria cover, among other things, coverage of key scenarios, acceptable defect thresholds (e.g., zero critical errors, a limited number of minor errors), performance requirements, and regulatory compliance. They are what turns “readiness” from a feeling into a data-based decision.

Common mistakes in acceptance testing

Even well-planned UAT can fail if the same pitfalls keep recurring:

  • Involving the wrong people. When the technical team performs the tests instead of the business, we lose the independent user perspective.
  • No acceptance criteria. Without them, it is impossible to objectively determine whether the project can be accepted.
  • Testing on unrealistic data. An environment that differs from production hides errors that will only surface after deployment.
  • Treating UAT as a formality. A hurried “rubber-stamp acceptance” under deadline pressure is asking for a production failure.
  • Confusing UAT with system testing. Repeating technical tests instead of business validation wastes users’ time and adds no value.
  • No defect management. Reports without prioritization, tracking, and retests blur accountability and delay acceptance.

Most of these problems stem not from technology, but from organization and communication — and that is precisely why experienced process support can reduce the risk so significantly.

UAT in IT projects and the staff augmentation model

In projects delivered by distributed teams or in the staff augmentation model, acceptance testing takes on added significance. When part of the competencies come from outside the organization, UAT becomes the point at which the commissioning party confirms that the delivered solution actually addresses its needs — regardless of who built it.

The challenge here is often a clear division of roles: who prepares the scenarios, who maintains the environment, who manages defects, and who makes the acceptance decision. Without this, accountability gets blurred and project acceptance drags on. That is why it is good practice to bring QA experts into the team as early as the UAT planning stage — not to perform the tests on behalf of the business, but to structure the process, prepare the scenarios and data, and professionally lead defect management.

An additional factor in distributed teams is communication around reports. When a business user and a developer work in different time zones, an ambiguously described defect can cost an entire day of fruitless message exchange. A simple reporting standard helps here: reproduction steps, the expected and actual result, the input data, and the priority. The fewer assumptions the fixing team has to make, the shorter the fix-and-retest cycle — and that directly shortens the time to acceptance.

How ARDURA Consulting supports the acceptance and QA process

At ARDURA Consulting, we treat acceptance testing as part of the broader discipline of quality assurance, not a one-off formality at the end of a project. We support organizations in designing the UAT process: from defining measurable acceptance criteria, through preparing scenarios based on real business processes, to defect management and final acceptance.

We have a team of more than 500 senior specialists, whom we onboard into projects in an average of 2 weeks. As a result, you can strengthen your own QA team exactly where it is needed, without the cost and time tied to permanent recruitment — with consultant retention at 99% and savings reaching 40% compared to building competencies in-house. Experience from more than 211 completed projects allows us to bring proven practices to the process, not theory.

You will find the full scope of our support in the quality area on the ARDURA Consulting testing services page. If you are planning a deployment and want acceptance testing to genuinely protect you from problems in production — let’s talk about how to set up this process at your organization.