Skip to content
steelabs

Glossary

User acceptance testing (UAT)

Definition

The final check, run by the people who asked for the software, that it does what they needed rather than what was specified.

User acceptance testing is the stage where the people who will live with the software decide whether it is fit to release. It is distinguished from every earlier stage by who holds the pen. System testing asks whether the build matches the specification, and a test team can answer that. Acceptance asks whether the specification captured the actual need, and only somebody who owns the process being automated can answer it. A finance lead running a month-end close against the new system is doing something no engineer can substitute for.

The stage fails predictably when it is treated as a rubber stamp scheduled two days before go-live. By then the only decisions available are to accept a known problem or to move a date that has already been announced, which is not a choice anybody wants to make on a Friday afternoon. Acceptance works when the criteria were written while the requirements were, when the participants are named and freed from their day job for the duration, and when there is an agreed route for a finding to become either a fix or a documented decision to ship anyway.

Conditions that make it worth running

  • Real business scenarios rather than feature checklists. The value of the stage is that somebody walks an end-to-end process they perform for a living and notices the step that has quietly become impossible.
  • Data that resembles production in shape and volume, because a workflow that behaves well against twelve invented records frequently does not survive four thousand real ones.
  • A written definition of what constitutes a blocker, agreed before anyone starts, so severity is not negotiated under deadline pressure by the people most invested in the answer.
  • A named decision-maker who can sign off. Acceptance by committee produces a list of opinions, not a release decision.

Acceptance testing is not a substitute for the testing that should already have happened: if participants are finding crashes, the build was handed over too early and the stage is being spent on the wrong defects.

Contact

Have a project in mind?

Tell us what you are building — or what keeps breaking. You will get a considered reply from an engineer, not an autoresponder.