User Acceptance Testing

Engineers test whether the code runs. User acceptance testing is the later question: does this slice do the job the buyer described, in a setting that resembles use?

The sequence is ordinary. The build is placed in a separate environment, often called staging, so practice data does not corrupt the live store. The buyer runs scenarios. A sign-off, or a failure log, decides whether a milestone is earned and whether risk has moved.

Where the disputes are

Acceptance criteria have to be measurable before anyone is angry. “The system must let a vendor upload a 50MB PDF and return a timestamped receipt within five seconds” can be failed in public. “Successful testing of the platform” cannot. The supplier will say the login works. The buyer will say the colour of a button is wrong. Both will be describing the same sentence.

Buyers also stall. The build sits in staging. Nobody files a defect list. Payment waits because the contract says payment follows acceptance, and acceptance never comes. A deemed-acceptance clause answers that stall with a clock: if no written rejection, in an agreed form, arrives within a stated number of business days, the slice is accepted and the milestone falls due. The clock is only as good as the form of the defect log. A clause that deems acceptance of a system nobody could log into is a different instrument from a clause that deems acceptance when the buyer stays silent after a real test window.