QUICK ANSWER
What is the difference between UAT and QA?
UAT is a specific acceptance-testing activity in which intended users or business representatives evaluate a named product boundary against agreed needs and acceptance criteria. QA is broader, process-oriented work that builds confidence in quality throughout development and testing. UAT can support a business acceptance decision; QA supplies wider process and product evidence. Neither automatically authorizes release.
UAT and QA are related, but they are not parallel names for two test teams. User acceptance testing is a bounded acceptance-testing activity: intended users or business representatives evaluate whether a named product boundary satisfies agreed needs and acceptance criteria. Quality assurance is the broader, process-oriented work used to build confidence that quality requirements will be fulfilled.
In workplace shorthand, “QA” often means the people who perform technical testing. That team may contribute system, regression, exploratory, and other evidence, but standards terminology still separates testing as product-oriented quality control from QA as preventive process work. The useful comparison is therefore scope, actors, evidence, and decision rights, not which team tests last.
The fictional Cedar Permit Review workflow below applies both tracks to the same release candidate. QA begins with requirements and process review and continues through technical and specialist evidence. UAT uses representative business journeys against four acceptance criteria. Neither track alone authorizes production release or certifies security, accessibility, performance, operations, or legal readiness.
Compare UAT and QA without turning them into rival gates
Use formal meanings first, acknowledge local job-title shorthand, and map both tracks to the same release so their inputs, outputs, and authority can be reviewed together.
Define testing, QA, and UAT before assigning work
ISTQB CTFL says testing and QA are not the same: testing is product-oriented quality control, while QA is process-oriented and preventive, applies to development and testing processes, and belongs to everyone on the project. ISO 9000 defines QA as the part of quality management focused on confidence that quality requirements will be fulfilled. UAT is one form of acceptance testing, not a synonym for the wider QA system.
Sources: [istqb-ctfl-401], [iso-9000-2026]
Build both tracks from shared requirements and risk
The ISTQB Acceptance Testing syllabus recommends collaborative work among product owners, business analysts, testers, and other stakeholders on measurable acceptance criteria and acceptance tests. ISO/IEC 25010 supplies a current product-quality model that can inform requirements, testing objectives, quality-control criteria, and acceptance criteria across the lifecycle. Shared inputs reduce silos without merging decision ownership.
Sources: [istqb-acceptance-testing], [iso-25010-2023]
Run QA throughout the lifecycle and UAT at its bounded point
GOV.UK advises thinking about service quality from discovery, testing during development, automating useful checks, reviewing the testing process, and selecting different test types for different quality questions. Its service-team guidance says quality belongs to the entire team and final responsibility lies with the service owner. The Ministry of Justice technology radar describes UAT as end-user verification of actual business requirements at the final testing phase in that practice context.
Sources: [govuk-quality-assurance], [govuk-service-roles], [justice-uat]
Keep evidence tied to its test basis and version
For the fictional CPR-2026.08-RC2 release, QA records review findings, coverage, technical results, defects, specialist references, and process actions. UAT records four business criteria, representative journeys, observations, discrepancies, retests, risks, and acknowledgement. Both histories remain useful, but neither can be silently reused after a material release, environment, criterion, or process change.
Sources: [istqb-ctfl-401], [istqb-acceptance-testing]
Route the final release decision to local governance
The updated GOV.UK reliable-service standard requires regular QA oversight by the service team rather than leaving it to automated tools. The service owner has overall responsibility and decision authority for the service. A local release owner should combine the bounded UAT result with QA, security, accessibility, performance, operations, legal, migration, and change evidence instead of treating either label as a universal go-live verdict.
What this UAT vs QA comparison covers
Use the matrix to assign a bounded business-acceptance track and a broader lifecycle quality track. Follow the template owners when the team needs an operational record.
Included
- Standards-aligned definitions plus a plain-language note about the common “QA team” shorthand
- Purpose, lifecycle scope, timing, actors, accountability, test basis, environment, activities, evidence, outcomes, and authority limits
- One paired fictional permit-review workflow with four business acceptance criteria, QA practices, UAT journeys, and a separate release owner
- Decision rules for planning UAT, release-specific technical testing, durable test strategy, and combined release review
Not included
- The release scope, representative participants, business scenarios, execution evidence, defects, risks, and sign-off owned by the user acceptance testing plan
- The exact release test scope, environments, suites, schedule, runs, evidence, defects, retests, and technical completion state owned by the test plan template
- The durable quality objectives, risk and coverage models, test levels, automation, data policy, and governance owned by the test strategy template
- Broad software-testing tutorials, quality-engineering maturity models, QA careers, certifications, interview questions, jobs, salaries, tools, or vendor rankings
- A reverse or long-form alias route, an artifact, download, checklist, test pack, benchmark, certification, or training course
- A claim that UAT replaces system, regression, exploratory, accessibility, security, performance, resilience, migration, or operational testing
- A claim that QA, a passing test suite, UAT acknowledgement, or defect count alone authorizes release or proves comprehensive quality
Nine differences that define the UAT and QA boundary
Read both columns for each criterion. UAT contributes evidence inside the quality system, while QA practices improve how UAT and the rest of development and testing are designed and reviewed.
Core decision
Separates stakeholder acceptance of a product boundary from confidence in the processes used to achieve quality.
Scope
Shows why UAT is one acceptance activity while QA spans development, testing, and improvement practices.
Timing and cadence
Prevents teams from delaying every quality activity until a release candidate reaches stakeholders.
Actors and accountability
Names who supplies expertise, who performs the work, and who owns each bounded decision.
Basis and criteria
Distinguishes business acceptance criteria from the broader requirements, risks, standards, models, and process goals used by QA.
Environment and data
Keeps a realistic UAT context from being confused with all environments and evidence needed for quality work.
Activities and techniques
Makes the specific stakeholder journeys and the larger preventive, review, test, and improvement system visible.
Evidence and outcome
Prevents a test result, defect count, or stakeholder acknowledgement from carrying more authority than it has.
Release authority and limits
Preserves security, accessibility, performance, operations, legal, change, and service-owner decisions outside either shorthand label.
UAT vs QA comparison matrix
Both columns use the fictional Cedar Permit Review release CPR-2026.08-RC2. The example contains no real system, users, execution, defect, acceptance, or release decision.
User acceptance testing (UAT)
Best for: Determining whether representative users or business stakeholders accept a named product boundary against agreed needs and measurable acceptance criteria.
On CPR-2026.08-RC2, representative requester, reviewer, and operator roles perform the permit journey in a synthetic pre-production environment. They record observations against four business criteria and send a version-bound accept, accept-with-risk, or reject outcome to the release owner.
| Criterion | Finding |
|---|---|
| Core decision | Asks whether the named product boundary fulfills intended-user and business needs well enough for the authorized stakeholder to accept, conditionally accept, or reject that boundary. Sources: [istqb-ctfl-401], [justice-uat] |
| Scope | Is one form of acceptance testing. It focuses on validation and business readiness rather than every development process, test level, quality characteristic, or operational gate. Sources: [istqb-ctfl-401], [istqb-acceptance-testing] |
| Timing and cadence | Acceptance criteria and test design should begin early, while execution usually occurs when a sufficiently complete named build and representative environment can support the business journeys. Sources: [istqb-acceptance-testing], [justice-uat] |
| Actors and accountability | Ideally involves intended users or business representatives, with product owners, business analysts, testers, and the authorized decision owner collaborating on criteria, evidence, discrepancies, and implications. Sources: [istqb-ctfl-401], [istqb-acceptance-testing] |
| Basis and criteria | Uses business requirements, user needs, processes, rules, risks, and measurable acceptance criteria. In Cedar, four criteria define the requester, reviewer, resubmission, and operator outcomes. Sources: [istqb-acceptance-testing], [iso-25010-2023] |
| Environment and data | Uses an actual or simulated operational context suitable for intended-user journeys, with approved data and a release identifier. Similarity to production does not prove production behavior or operational readiness. Sources: [istqb-ctfl-401] |
| Activities and techniques | Executes representative end-to-end business scenarios, compares actual and expected outcomes, records discrepancies, retests affected criteria, and reports in language the business audience can use. Sources: [istqb-acceptance-testing] |
| Evidence and outcome | Produces criterion traceability, scenario results, business-language evidence, discrepancies, retests, known risks, and stakeholder acknowledgement for a bounded acceptance outcome. Sources: [istqb-acceptance-testing] |
| Release authority and limits | Can support acceptance of the recorded business-use boundary. It does not certify defect absence or replace the service or release owner, specialist assurance, operational acceptance, legal review, or change authorization. Sources: [govuk-service-roles], [govuk-reliable-service] |
Tradeoffs
- Direct business participation improves relevance to intended use, but participant coverage and scenario coverage remain bounded and can miss technical or specialist risks.
- A clear acceptance outcome supports stakeholder governance, but it applies only to the recorded release, environment, criteria, evidence, risks, and authority.
Quality assurance (QA)
Best for: Providing confidence that quality requirements will be fulfilled by improving and reviewing development and testing processes across the lifecycle.
For Cedar, the whole service team reviews requirements and criteria, chooses risk-based coverage, applies static and dynamic checks, coordinates specialist evidence, manages defects, and uses results to improve both product and process. The quality lead supports the system; the service owner retains final responsibility.
| Criterion | Finding |
|---|---|
| Core decision | Asks whether the processes for development and testing provide justified confidence that quality requirements will be fulfilled and where those processes should improve. Sources: [istqb-ctfl-401], [iso-9000-2026] |
| Scope | Applies to development and testing processes across the product lifecycle. Testing is a major form of quality control inside that larger system, not the complete definition of QA. Sources: [istqb-ctfl-401], [iso-25010-2023] |
| Timing and cadence | Starts with quality goals, requirements, risk, process design, and early review; continues through implementation, automated and manual testing, release evidence, live operation, and process improvement. Sources: [govuk-quality-assurance], [govuk-reliable-service] |
| Actors and accountability | Quality is the whole team’s responsibility. A quality specialist can help build capability and provide independent skill, while the service owner retains overall and final responsibility. Sources: [istqb-ctfl-401], [govuk-service-roles] |
| Basis and criteria | Uses quality requirements, product and project risks, standards, process goals, product models, technical and business requirements, and criteria across multiple test levels and types. Sources: [iso-25010-2023], [govuk-quality-assurance] |
| Environment and data | Uses the environments and data appropriate to each review and test objective, from static work products and component fakes to integration, system, staging, specialist, and operational evidence. Sources: [istqb-ctfl-401], [govuk-quality-assurance] |
| Activities and techniques | Includes preventive process design and improvement plus reviews, traceability, static analysis, automated checks, functional, regression, exploratory, accessibility, security, performance, and other risk-selected work. Sources: [istqb-ctfl-401], [govuk-quality-assurance] |
| Evidence and outcome | Produces process-review findings, risk and coverage records, test results, defects, specialist references, trends, limitations, and improvement actions that support bounded confidence rather than one universal pass. Sources: [istqb-ctfl-401], [govuk-quality-assurance] |
| Release authority and limits | Provides evidence and process confidence but does not automatically accept the product for its users or authorize release. Human oversight and the service owner’s local decision rights remain necessary. Sources: [govuk-reliable-service], [govuk-service-roles] |
Tradeoffs
- Lifecycle breadth can prevent and expose more classes of problems, but “QA passed” is too vague unless each scope, criterion, result, limitation, and owner is named.
- Automation and specialist testing provide repeatable evidence, but tools and test teams cannot replace intended-user acceptance or accountable human governance.
Choose the next record, not a winning acronym
Most delivery work needs both a broader quality system and a bounded acceptance decision. The next document depends on which evidence must become operational.
A named release needs representative business roles, end-to-end scenarios, measurable criteria, evidence, defects, risks, and a version-bound acceptance outcome.
Choose: Use the user acceptance testing plan.
Tradeoff: The plan makes business acceptance reviewable, but it cannot replace the technical and specialist evidence supplied by the broader quality system.
One release or product version needs technical targets, environments, suites, schedule, execution, evidence, defects, retests, and completion reporting.
Choose: Use the test plan template.
Tradeoff: The plan coordinates technical testing for that boundary, but it does not create durable strategy or stakeholder business acceptance.
The organization needs durable quality objectives, risk and coverage rules, test levels and types, automation, data policy, and governance across releases.
Choose: Use the test strategy template.
Tradeoff: The strategy improves consistent selection, but each release still needs an executable plan and its own evidence.
UAT and planned QA evidence are both reviewable, but security, accessibility, performance, operations, legal, migration, or change evidence is missing.
Choose: Hold the universal release verdict and route each missing decision to its qualified owner before the service or release owner decides.
Tradeoff: The evidence graph stays honest even when a schedule would benefit from collapsing several decisions into one sign-off.
A team uses “QA” as a job title for testers and that local shorthand is already established.
Choose: Keep the title, but name the actual test levels, scopes, evidence, process responsibilities, and decision rights in every plan and report.
Tradeoff: People can keep familiar language without allowing one label to hide missing quality work or authority.
MOVE FROM COMPARISON TO BUSINESS ACCEPTANCE
Give the named release a bounded UAT decision
Use the UAT plan to define representative roles, business scenarios, measurable criteria, evidence, discrepancies, risks, and authority without absorbing the wider quality system.
Open the UAT plan templateThe UAT template is a separate operational owner. This comparison contains no artifact or completed test evidence.
Use the test plan for one release’s technical QA execution and evidence.Use the test strategy separately when the quality rules must persist across releases.
What this comparison cannot decide
Terminology helps only when the real roles, scopes, criteria, environments, evidence, and authority are named. Local governance and product risk still control the work.
- Organizations use QA, tester, quality engineer, product owner, business representative, and acceptance authority differently. Map local roles before assigning accountability.
- The fictional Cedar Permit Review release contains no real product, user, environment, run, result, defect, acceptance, specialist assessment, or release authorization.
- A passing UAT scenario demonstrates the recorded observation for its release and criteria; it does not prove comprehensive user representation, technical quality, accessibility, security, performance, resilience, or production behavior.
- A mature QA process can improve confidence and prevention without guaranteeing a defect-free product, complete coverage, correct requirements, business acceptance, compliance, or successful release.
- Automation can supply fast repeatable evidence but cannot own service outcomes, intended-user acceptance, process judgment, risk acceptance, or release authority.
- ISTQB, ISO, and government guidance use different scopes and contexts. Recheck the current source, contract, regulation, product risk, and local decision rights before adopting terminology as policy.
Primary standards and government guidance
These current standards, official syllabi, and government sources were checked together on August 1, 2026. Their scopes differ, so the article attributes each claim narrowly instead of presenting a universal process.
[istqb-ctfl-401] International Software Testing Qualifications Board:Certified Tester Foundation Level Syllabus v4.0.1
Checked August 1, 2026. Supports: Testing as product-oriented quality control; QA as process-oriented, preventive, lifecycle work; whole-project responsibility; test levels; business representatives in acceptance testing; and UAT as a main acceptance form.
[istqb-acceptance-testing] International Software Testing Qualifications Board:Certified Tester Acceptance Testing syllabus v1.0
Checked August 1, 2026. Supports: Collaboration among product owners, business analysts, testers, and stakeholders; measurable acceptance criteria; business processes and rules; traceability; discrepancies; reporting; QA review of acceptance artifacts; and decision-support outcomes.
[iso-9000-2026] International Organization for Standardization:ISO 9000:2026 Quality management fundamentals and vocabulary
Checked August 1, 2026. Supports: The current quality-management vocabulary and the definition of quality assurance as focused on confidence that quality requirements will be fulfilled.
[iso-25010-2023] International Organization for Standardization:ISO/IEC 25010:2023 product quality model
Checked August 1, 2026. Supports: A nine-characteristic product-quality model for requirements and evaluation across the lifecycle, including testing objectives, quality-control criteria within QA, acceptance criteria, and multiple stakeholder perspectives.
[govuk-quality-assurance] GOV.UK Service Manual:Quality assurance: testing your service regularly
Checked August 1, 2026. Supports: Quality thinking from discovery, whole-team goals and risk work, automated feedback, process review, and distinct functional, exploratory, accessibility, security, capacity, and performance testing needs.
[govuk-service-roles] GOV.UK Service Manual:What each role does in a service team
Checked August 1, 2026. Supports: Whole-team quality responsibility, the quality specialist’s capability-building role, and the service owner’s overall responsibility and decision authority.
[govuk-reliable-service] GOV.UK Service Manual:Service Standard point 14: Operate a reliable service
Checked August 1, 2026. Supports: Regular QA testing overseen by the service team rather than left to automated tools, production-like testing, monitoring, response planning, and attention to user outcomes.
[justice-uat] UK Ministry of Justice Technology Radar:User Acceptance Testing technique
Checked August 1, 2026. Supports: A current UK government practice description of UAT as end-user verification that software meets actual business requirements in the final testing phase.
UAT vs QA questions
Is UAT part of QA?
UAT is a type of acceptance testing and contributes evidence to the wider quality system. Formal terminology separates testing as product-oriented quality control from QA as process-oriented assurance. QA practices can improve UAT criteria, traceability, cases, reporting, and review, while UAT keeps its distinct intended-user and business-acceptance decision.
Who performs UAT and who performs QA?
UAT should involve intended users or representative business stakeholders, supported by product owners, business analysts, testers, and a named acceptance decision owner. QA belongs to the whole team; quality specialists can build capability, review processes, and coordinate evidence. Job titles vary, so record actual responsibilities instead of relying on the acronym.
Does QA happen before UAT?
Much QA and technical testing should begin before UAT, but QA does not simply end when UAT starts. Quality goals, requirements review, test strategy, automation, system testing, defects, and process improvement span the lifecycle. UAT execution usually waits for a suitable named build and entry evidence, while QA review continues through and after it.
Can QA testers execute UAT?
Testers can facilitate UAT, design evidence, manage environments, record discrepancies, and sometimes act as proxies when that limitation is explicit. The acceptance perspective should still come from authorized intended-user or business representation. A test team cannot silently create business authority merely by executing the same steps.
What evidence should UAT produce compared with QA?
UAT should produce release-bound scenario results, acceptance-criterion traceability, business-language observations, discrepancies, retests, risks, and acknowledgement. QA evidence is broader: process reviews, risk and coverage records, technical test results, defects, specialist references, trends, and improvement actions. Both need scope, version, environment, owner, and limitations.
Does UAT sign-off mean a release is ready for production?
Not by itself. UAT sign-off can accept a recorded business-use boundary for a named release. Production authorization may also require technical QA, security, accessibility, performance, resilience, operations, migration, legal, privacy, support, and change evidence. The service or release owner applies local governance to the complete evidence set.
What is the difference between a UAT plan, test plan, and test strategy?
A UAT plan owns representative business scenarios and version-bound acceptance. A test plan owns technical testing for one release or product version. A test strategy owns durable quality objectives, risk, coverage, levels, types, automation, data, evidence, and governance across releases. Link the three rather than combining their decisions into one document.
BUILD AROUND EXPLICIT QUALITY BOUNDARIES
Turn the reviewed workflow into a testable internal tool
Describe the business roles, acceptance criteria, technical test contracts, evidence links, defect states, specialist handoffs, and release authority before implementation begins.
Build the workflowThis informational comparison does not grant signup AI credits. The linked product page follows its own current eligibility rules.