UAT is all the T

Twenty-five years of running dev teams taught me that User Acceptance Testing is a three-letter acronym where two of the letters are a polite fiction.

The users, in theory, are the ones testing. In practice the users are three weeks behind on their day job and didn’t sign up to be QA. They get handed a spreadsheet of “test scenarios” on a Friday and asked to sign off by Monday. They open it, scroll, click a few things, and send back “looks good.” Nobody is testing. Nobody is even really looking. The word “user” in UAT is a label slapped on a stakeholder who wants the project done so the invoice can be paid.

The acceptance, in theory, is the decision. In practice the acceptance was made months earlier, when the contract was signed or the roadmap was locked. Every “finding” from UAT is a political event — raise a real issue and you’re the one delaying the release. So findings get filed as “phase two” and the project ships on the date someone already committed to.

What’s left, once the users aren’t testing and the acceptance was predetermined, is the T. And the T is the part that actually requires work. Writing the use cases. Writing the test plans. Walking through each flow with a checklist. Logging what happened versus what should have happened. The T is the labor that nobody’s bonus depends on, that doesn’t show up in a demo, that senior engineers consider beneath them and junior engineers consider above them.

For every team I ran, I asked for the T. Write the use cases. Plan the UAT against those use cases. Have a real acceptance gate. And for every team, the T got skipped, deferred, partial, performed, or outsourced to someone who didn’t know the product. Never actually done. The users signed off, the acceptance happened on the preordained date, and the T quietly didn’t.

I don’t think this was a talent problem. Every engineer I worked with could have done it. The T is not hard in any intellectual sense — it’s just tedious, uncelebrated, and politically inconvenient. It looked like clerical work, so nobody of sufficient seniority wanted to own it. It demanded completeness, so nobody of insufficient seniority was trusted to own it. It fell through the crack between.

What’s different now is that the labor part of the T doesn’t need a human anymore. Catalog the use cases: a machine does it in an afternoon. Write the Playwright suite: a machine does it overnight. Run the regression against the live product: scheduled cron. File a bug when something fails: automatic. The T — the part that always got skipped — is now the cheap part.

That changes what UAT actually is. The A can still be a political event if you want it to be. The U can still be a signature on a form. But the T is no longer a negotiation. The machine does it, every week, whether anyone asked. The question stops being “did the users test?” and becomes “what did the tests find, and is anyone going to look?”

Which, I’ll admit, is a different kind of problem. But it’s the problem I wanted to have.