User Acceptance Testing (UAT) Phase of the Systems Development Lifecycle (SDLC)

Defines the IF4IT SDLC phase in which authorized business, Product, operational, and other intended-use stakeholders validate that the integrated Solution and Release are suitable for their approved purposes, workflows, users, outcomes, and operating context.

Purpose

The User Acceptance Testing phase validates that the Solution is fit for its intended enterprise use. It evaluates whether authorized stakeholders can accomplish the required outcomes under representative business and operational conditions and whether the Release is acceptable for subsequent training, staging, Production preparation, or rework.

Typical Inputs

Inputs may include the approved requirements and acceptance criteria, intended-use scenarios, stakeholder and acceptance authority assignments, SIT conclusion, accepted test candidate baseline, UAT Environment and data, role and access models, business rules, process definitions, operational and support expectations, known defects and limitations, Risks, exceptions, and the SDLC Utilization Profile.

Core Activities

Confirm UAT scope, authority, participants, Environment, data, and baseline; execute representative end-to-end business and operational scenarios; validate workflows, outputs, decisions, usability, accessibility, data meaning, controls, reports, integrations, exception paths, and role behavior; capture stakeholder observations and evidence; distinguish defects from requirement or training issues; govern changes and retesting; and record the formal acceptance conclusion, conditions, limitations, and unresolved matters.

Acceptance Authority and Independence

UAT participants should represent the people and functions authorized to judge intended use. The delivery team may facilitate and support testing but should not unilaterally declare business acceptance. A Product Owner, business owner, operational owner, Data Owner, regulatory authority, or other stakeholder may hold acceptance authority for different claims. UAT should preserve those distinct decision rights and disclose conflicts or limitations.

Outputs and Evidence

Outputs may include executed UAT scenarios, observations, acceptance results, defects, requirement clarifications, usability and accessibility findings, data and report validation, updated training and operational needs, conditions, limitations, residual Risks, retest evidence, and an explicit acceptance decision linked to the evaluated baseline and authorized stakeholder.

Decision and Exit Criteria

Exit requires adequate intended-use coverage, authorized stakeholder participation, an identifiable evaluated baseline, governed findings, acceptable residual Risk and uncertainty, updated requirements and technical data where needed, and an explicit outcome such as accepted, accepted with conditions, partially accepted, not accepted, or unable to conclude. UAT completion by schedule or attendance is not acceptance.

Application Across Solution Types and Methods

For Custom-Built Solutions, UAT validates that the developed capability satisfies intended business and operational use. For Acquired Solutions, it validates the configured and integrated enterprise Solution rather than the supplier Product in the abstract. Composite Solutions require end-to-end user and operational scenarios across components. Waterfall may conduct a concentrated UAT stage, Agile may validate increments continuously, and Hybrid may combine iterative stakeholder review with formal Release-level acceptance. Sprint Review is not automatically UAT unless its scope, participants, evidence, baseline, and authority satisfy UAT needs.

Crawl-Walk-Run Maturity

At Crawl maturity, define acceptance authority, representative scenarios, controlled results, defect ownership, and an explicit decision. At Walk maturity, integrate requirements, traceability, test-data management, workflow evidence, stakeholder scheduling, and conditional acceptance. At Run maturity, use production-like scenario simulation, analytics from real workflows, automated evidence capture, accessibility and usability instrumentation, and generative AI support for scenario design and evidence analysis while preserving human acceptance authority.

Common Antipatterns

Enterprises should avoid treating Sprint Review as automatic User Acceptance Testing. A demonstration to the delivery team’s own stakeholders during a Sprint does not by itself establish the scope, evidence, and acceptance authority that formal UAT requires, and it should not be mistaken for a business acceptance decision.

Connections to Related IF4IT Practices and Inventories

Use the Capabilities Inventory and Attributes and the IF4IT Enterprise Model to evaluate whether delivered and operated outcomes actually improve the intended enterprise capabilities and value streams. Use Application Portfolio Management (APM) Best Practices and the Applications Inventory and Attributes to place this SDLC decision in the context of application ownership, portfolio value, lifecycle state, and dependencies.

Ground quality expectations in the Non-Functional Requirements (NFRs) Framework for Software Systems, connecting them to validation methods, test evidence, acceptance criteria, readiness gates, and Production assurance.

Connect this practice to Release Management guidance, IT Operating Environments Best Practices, and Agile, Waterfall, or Hybrid: An IF4IT Framework for Choosing Delivery Methodology, which together govern Release scope, environment progression, deployment evidence, cutover, rollback, and closure.