Skip to content

What is UAT, or user acceptance testing?

UAT (user acceptance testing) is the test in which a system's intended users try it on real cases to decide on acceptance, on which payment often depends.

UAT (user acceptance testing) is the test in which the people who will actually use a system try it on their own work and decide whether to accept it. The ISTQB glossary, from the international body that certifies software testers, defines it as a type of acceptance testing performed to determine if intended users accept the system; acceptance testing, in turn, is the test level that focuses on determining whether to accept the system. UAT does not hunt for code defects, which the supplier should have caught earlier: it yields a decision, a yes, a no or a yes with reservations, and go-live and payment usually depend on that outcome. Italians often call it collaudo, but in Italian public procurement collaudo applies to public works, while for services and supplies, IT projects included, the law speaks of verifica di conformità (conformity check).

See also: Evals (model evaluation) · Evals are systematic test suites that measure an LLM system's quality on known cases, instead of trusting the impression of whoever tries it.

Collaudo and verifica di conformità

Italy's Public Contracts Code (article 116 of Legislative Decree 36/2023) subjects service and supply contracts to a conformity check that certifies compliance with the agreed features, goals and deadlines. The RUP, the authority's official accountable for the contract, or the execution manager carries it out; for high-technology, complex or innovative contracts the authority may appoint separate verifiers. Methods and timing go in the capitolato, the public counterpart of an SOW, and Annex II.14 requires the check to start within thirty days of completion, unless the contract sets another deadline. Between private parties collaudo remains the everyday word, and for a contract to deliver a work (appalto) the Civil Code gives the client the right to inspect the work before delivery, and treats it as accepted if received without reservations (article 1665, covered in the entry on T&M and turnkey).

Accepting an AI system

In traditional software, UAT comes after the supplier's own tests, many of them automated and arranged along the test automation pyramid, and every test has an expected result written in advance. The technical report ISO/IEC TR 29119-11 notes that AI systems can be non-deterministic, giving different answers to the same input, and that setting their acceptance criteria is hard: testers struggle to determine the expected result. The NIST AI Risk Management Framework calls for measuring performance under conditions similar to real use (MEASURE 2.3) and documenting the system's limits beyond its development conditions (MEASURE 2.5). That is why I write statistical criteria: a minimum share of correct cases on an agreed sample of real data. Measuring model quality is the job of evals; UAT uses those numbers to decide whether to sign off.

An enterprise example

An insurer buys an assistant that reads claim reports and proposes a classification to the claims adjuster. The contract sets the criteria before development: on 400 claims from the last quarter, picked by the staff who handle them daily, the classification must match that of a senior adjuster in at least nine cases out of ten, and no claim involving bodily injury may land in the low-priority queue. The test uses the real production formats, crooked scans included. In the first round the system clears the threshold but downgrades two injury claims: the insurer withholds acceptance and documents the two cases, the supplier fixes the errors and the second round closes UAT.

Why it matters for decision makers

UAT is the moment when the buyer decides with data in hand, and payment usually depends on it. The criteria belong in the contract before development, with the sample, the threshold and who runs the test, and the outcome belongs in writing, reservations included, because in an appalto between private parties, taking delivery without reservations counts as acceptance. In Italian public procurement, Annex II.14 (article 37) keeps the supplier liable for flaws or defects, including in parts or functions that could not be tested during the conformity check.

This entry is informational and does not constitute legal advice: to set up acceptance for a specific contract, involve your legal counsel.

Frequently asked questions

Between private parties, often yes: Italians use collaudo for accepting what the supplier delivers. In public procurement, Italy's Public Contracts Code (Legislative Decree 36/2023, article 116) reserves collaudo for public works and uses verifica di conformità for the check on services and supplies, IT projects included. UAT is the hands-on test with users that acceptance rests on.

The people who will use the system: according to the ISTQB glossary, UAT determines whether the system's intended users accept it. The supplier prepares the environment and fixes issues, but does not judge its own work. In Italian public procurement of services and supplies, the conformity check falls to the RUP or the contract's execution manager; for high-technology, complex or innovative contracts the authority may appoint separate verifiers.

With statistical thresholds instead of exact expected results, because an AI system can give different answers to the same input. You need an agreed sample of real cases, a minimum share of correct answers, the cases that must never fail and a test under conditions similar to production, as the NIST AI Risk Management Framework asks.
  • Evals (model evaluation) · Evals are systematic test suites that measure an LLM system's quality on known cases, instead of trusting the impression of whoever tries it.
  • Definition of Done (DoD) · The Definition of Done (DoD) is the quality bar a development team commits to meeting on every deliverable before declaring the work finished to the client.
  • Statement of Work (SOW) · A statement of work (SOW) is the document that sets out what a supplier must deliver: the outcome, data, acceptance criteria, change process and exclusions.
  • Time & Material vs Turnkey (T&M vs TK) · T&M (time and material) and TK (turnkey) are the basic ways to buy an IT project: days billed at a rate with the client in charge, or an outcome at a set price.
  • Test automation pyramid · A model that spreads testing effort across many unit tests, fewer integration tests, few end-to-end tests.

See it in the universe

If it is a technical decision you keep postponing, that is the decision I help you make.

SEE CUSTOM TOOLS AND GOVERNANCE

Or write to me.