Build verification test

A build verification test (BVT), also called a build acceptance test, is a fixed set of checks run against every new build as soon as it is produced, usually by the pipeline itself, to decide whether the build is stable enough to hand to testers at all. It is the build-gating form of smoke testing: a failing BVT rejects the build before anyone spends time on it.

The longer version

The set is small and deliberately shallow. It confirms the build installs or deploys, the application starts, the main screens render, a user can sign in and the central transaction completes. Each check is automated and runs in the pipeline the moment a build exists, so the verdict arrives before a human has looked. The set is the same for every build, which is what makes it a verification of the build rather than a test of the change: it is looking for a broken build, not a broken feature.

Smoke testing and BVT describe the same idea from two directions and the terms are used interchangeably in many teams. Where a distinction is drawn, smoke testing is the wider practice, which can be manual and can be run by a tester on a deployed environment, while a BVT is the specific automated suite bound to build production and owned by whoever owns the pipeline. Sanity testing is different again: it is a narrow check after a fix, on a build that has already passed its BVT.

The set fails in practice by growing. A team adds a check for every regression that embarrassed it, until the BVT takes as long as the regression suite it was meant to precede and developers stop waiting for it. The other failure is a BVT that passes on a build which cannot be used, because the checks confirm the process started and nothing else; a set like that will never reject a build and is verifying nothing.

In the pipeline, the BVT sits between build and deployment to the first shared environment. A build that fails it is never deployed, and the failing check narrows the cause to the commits that arrived since the previous passing build. Builds that pass move on to the test environment, where the deeper functional and regression work begins on the assumption that the basics hold.

Common questions

Is a build verification test the same as a smoke test?

Build verification testing is a form of smoke testing, and many teams use the two names for the same suite. Where they differ, smoke testing is the broader practice, manual or automated, and a BVT is the automated set bound to the build pipeline that rejects a build automatically when it fails.

What should a build verification test include?

A build verification test covers the paths without which no other testing is possible: the build deploys, the application starts, the main pages render, a user can log in, and the core transaction completes. Anything beyond that belongs in the regression suite, or the BVT grows until nobody waits for it.

Who owns the build verification test?

The team that owns the build pipeline usually owns the BVT, because it runs as a stage of that pipeline and a failure blocks deployment. QA contributes the list of paths worth checking and reviews it when the product's critical paths change, but the suite runs without anyone triggering it.

When is a build verification test run?

Immediately after every build is produced and before it is deployed anywhere people test, as an automatic stage of the pipeline. Nobody triggers it and nobody waits to be asked; the verdict is attached to the build itself. A build that has passed goes on to the test environment, and a build that has not is never deployed at all.

What happens when a build verification test fails?

The build is rejected: the pipeline stops before deployment, the developers who committed since the last passing build are notified, and testers keep working on the previous good build. The failing check names the broken path, and the set of commits since the last pass narrows the cause. The next build is verified afresh rather than the failed one being patched in place.

Bug reports that arrive ready to triage.

Collect replay, console, network and browser context with the Free plan.

<script src="…/widget.js" data-key="pb_pub_…">