Testing 101: Smoke Tests, Regression Tests, and Sanity Checks
A clear introduction to smoke tests, regression tests, and sanity checks, what each one means, and when teams typically use them.
Smoke tests, regression tests, and sanity checks are three terms that come up constantly in software testing conversations.
They are also three terms that are often mixed up.
It isn't difficult to understand why because they all relate to confidence, risk, and deciding what to test after a change. The difference is mainly in scope and purpose.
One quick caveat before getting into it: these terms are not used perfectly consistently across the industry. In some teams, what one person calls a sanity check might be described elsewhere as a smoke test. The distinctions in this post reflect a common way of separating them, but it is always worth understanding how your own team uses the language in practice.
Smoke Tests
A smoke test is a small set of high-level checks used to confirm that a build is stable enough for deeper testing.
It is not meant to test everything. It is meant to answer a simple question quickly: is the application healthy enough for the team to continue?
Typical smoke checks might include:
- can the application load?
- can a user log in?
- can the main dashboard or homepage be reached?
- do the most critical user journeys appear to be working at a basic level?
If a smoke test fails, it usually means there is little value in doing more detailed testing until the bigger issue is resolved.
Sanity Checks
A sanity check is a focused check carried out after a specific change or fix.
It is narrower than regression testing and is usually used to confirm that the thing that was just changed behaves as expected.
For example, if a developer fixes a bug in password reset, a sanity check might focus mainly on that password reset flow rather than on the entire application.
That is why sanity checks are often quick and targeted. They are there to answer: did this particular change make sense, and does it appear to work?
Regression Tests
Regression testing is the process of checking that existing functionality still works after changes have been made.
This is broader than a sanity check. The goal is not only to validate the new or changed area, but also to confirm that the change has not caused unintended problems elsewhere.
Regression testing can be:
- fully manual
- fully automated
- or, most commonly, a sensible combination of both
The size of a regression pass will depend on the product, the risk of the change, and the confidence the team already has in its automated coverage.
The Difference at a Glance
| Test Type | Main Question | Scope | Typical Use |
|---|---|---|---|
| Smoke Test | Is the build basically stable? | Small and high-level | Early confidence check on a new build |
| Sanity Check | Does this specific change seem OK? | Narrow and targeted | Quick validation after a bug fix or small change |
| Regression Test | Did we break anything else? | Broader and more systematic | Confidence after changes across existing functionality |
Why the Difference Matters
These terms matter because they help teams talk clearly about what kind of confidence they are looking for.
If a team says it needs a regression pass, that means something different from saying it only needs a sanity check. And if a build has not passed smoke testing, then running a full regression is often a poor use of time.
“The better a team is at naming the kind of testing it needs, the easier it becomes to choose the right level of effort and the right level of confidence.”
Final Thought
Smoke tests, sanity checks, and regression tests are all useful. None of them are interchangeable, and none of them exist to sound impressive.
They are simply different ways of managing risk.
The more clearly a team understands those differences, the easier it becomes to test efficiently and communicate accurately about quality.