Smoke, sanity, UAT: who runs what, and when

Three terms, used interchangeably by most teams, meaning different things to each person in the room.

Smoke testing answers one question: is this build worth testing at all? A handful of checks on the most important paths. If the application will not start or nobody can log in, you stop and save everybody an afternoon. Some teams call it a build verification test, or BVT.

Sanity testing is a narrow check after a change: does the thing that was just fixed actually work, and did the area around it survive? Smaller than a regression pack, aimed at one area.

User acceptance testing (UAT) is the customer or business representative confirming the software does what they need, in their language, before they accept it. It is not a second round of your testing, and it is not a bug hunt.

The distinction matters because each one has a different owner. When the words blur, so does the ownership, and a release ends up signed off by nobody.

The terms you will hear

• Smoke test. A short set of checks proving the build is usable. The name comes from electronics: switch it on and see whether it smokes.
• Build verification test (BVT). The same thing, usually automated and run by the pipeline.
• Sanity test. A focused check after a change or a fix. Narrow and quick.
• Regression testing. Re-running a wider pack to check that what worked still works.
• User acceptance testing (UAT). Business or customer confirmation against their own needs.
• Alpha and beta testing. Acceptance testing done internally, then with real users, before general release.

Why it matters

Because when the words are vague, the responsibility is too.

For example, a project manager asks whether UAT is done. The tester says yes, meaning they ran the release pack. The business sponsor has never opened the feature. Two weeks after launch, the sponsor sees it, hates the wording on the confirmation email, and asks why nobody checked. Everybody in that chain behaved reasonably, and the release still had no business sign-off.

Getting the three definitions agreed removes that whole failure mode.

How to use them properly

1. Automate the smoke test and run it on every deploy. Five to ten checks: the app loads, login works, one core journey completes, the health endpoint answers.
2. Run smoke before anything else in a cycle. It is step two of the regression cycle for exactly this reason.
3. Use sanity checks after each fix. Re-test the fix, plus whatever shares code with it. Do not re-run the whole pack for a one-line change.
4. Give UAT to the business, with support. Prepare the environment and the data, write the scenarios in their language, then let them use it. Sitting beside them and watching is the most valuable hour in the release.
5. Never call your own testing UAT. If QA runs it, it is acceptance-style testing rather than user acceptance testing. The distinction protects you.
6. Write down who signs what. UAT sign-off is a business signature. The QA recommendation is separate, and belongs in the summary report.

A worked set

Here is what the three look like written down for one small team, with times attached.

Look at the UAT findings. Neither is a defect, and both would have shipped without a business pair of eyes. The vocabulary mattered: had QA called their own pack "UAT", nobody would have run those four scenarios.

How to show you know it

• A three-line definition your team agreed. It is a small artefact that ends a recurring argument.
• An automated smoke test that blocks a deploy. The most useful ten checks you will ever write.
• A UAT session you prepared but did not run. Preparing the data and scenarios, then letting the business use it, is the professional version.
• A finding that only UAT could produce. The wording mismatch above is a perfect example, and it is why the practice exists.