Sanity Testing: What It Is and What to Check After a Fix

Sanity testing is the check you run right after a bug fix or a small change, on a build that has already proven itself stable. It is not a scaled-down version of a bigger test cycle, it is a deliberately narrow one: you look only at what just changed and whatever sits close enough to have been affected by it.

This guide covers what that check actually involves: what it verifies, what its real advantages and limits are, how it differs from regression testing, and the process to run one well.

What is sanity testing?

Sanity testing is a focused check performed after smoke testing, to confirm that a recent bug fix or small enhancement did what the ticket said it would, without introducing a new problem. It answers a narrow question: did this specific change work?

Also known as surface-level testing, sanity testing runs on a build that has already passed smoke testing, so the core system is known to be stable. You are not re-verifying the whole application, only the area a developer just touched and whatever sits close enough to it to have been affected.

Because it evaluates only part of the system, sanity testing is best understood as a narrow, targeted subset of regression testing, the broader process of confirming that recent changes have not broken existing functionality. Focusing on the fix itself is what lets a sanity check validate a change quickly, without running a full suite.

Characteristics of sanity testing

Targeted validation. A sanity check looks at the exact features touched by a recent update or fix, not the whole system. That narrow focus is what confirms the change works correctly without unintended side effects nearby.

Quick confirmation. The point is fast reassurance. A small number of checks confirm the updated feature is stable enough to move forward, catching obvious issues early without spending time on a deeper cycle.

Post-fix testing. Sanity testing only happens on a stable build carrying minor updates or fixes. Since the build already passed smoke testing, the core system is known to work. The job here is confirming the specific change behaves as expected before broader regression testing begins.

Stopgate mechanism. If a sanity check fails, testing stops immediately rather than continuing. The build is not ready, so it goes back to development with the details, which saves the team from testing further on something already known to be broken.

What sanity testing gets you, and its limits

The advantage is speed with focus. Because a sanity check only touches the modules affected by a specific change, a tester or the developer who made the fix can confirm it in minutes rather than waiting on a full test cycle. That focus also makes it a natural gatekeeper: a passing sanity check is what earns a fix the right to move into a broader regression run, so regression time is not spent on changes nobody has looked at yet.

Scoped this tightly, it typically costs less than running a fuller suite for the same fix, provided the scope stays genuinely narrow rather than becoming a stand-in for skipping regression altogether. And because it looks specifically at the area around a change, sanity testing is well placed to catch a failure mode that is easy to miss elsewhere: a bug that was fixed once and has quietly returned after a later change touched the same code.

The limits come from the same looseness that makes it fast. A sanity check is usually run without a script or documented steps, since its scope changes with every fix, so there is often no record of exactly what was checked once the ticket closes. And because that scoping work happens fresh every time, the real cost is not in any single check, it is in doing it repeatedly: a team running dozens of ad hoc sanity passes a month is spending real, uncounted time re-deciding what to look at, even though each individual pass feels quick.

How sanity testing differs from smoke testing

The two are often mentioned in the same breath, but they answer different questions. Smoke testing asks whether an entire build is stable enough to test at all: broad, shallow, and run on every build. Sanity testing asks whether one specific change worked: narrow, deeper, and run only after a targeted fix on a build that has already passed smoke.

If you need to work out which check a given change actually calls for, our guide to sanity testing vs. smoke testing works through the triggers case by case, with worked examples on the same application.

Sanity testing vs. regression testing

This is the comparison that matters most for this page, because the two are genuinely easy to blur. Both run after a change. The difference is scope: sanity testing targets the specific fix, while regression testing re-verifies the application more broadly to confirm nothing else was disturbed.

Sanity testing is like checking the one button that was just fixed. You look only at the area that changed, to confirm the fix works and did not create an obvious new issue nearby. It is quick, narrow, and meant to build enough confidence to move forward. Regression testing is like checking the whole control panel, because changing one part of a system always carries some chance that an unrelated feature broke without anyone noticing. It looks back across previously working functionality to confirm it still behaves correctly, which makes it broader, slower, and better suited to catching side effects across the full system.

A sanity check is best thought of as a narrow, targeted subset of regression testing rather than a small regression run in its own right. It answers "did this specific fix work," not "is the application still sound overall," which is the question regression testing exists to answer.

The sanity testing process

Five steps, in order, cover most sanity checks:

1. Review what changed. Read the change log, the Jira ticket, or the commit notes so you know exactly what was updated or fixed. This is what keeps the check scoped to the right area instead of drifting into unrelated parts of the application.

2. Confirm the build is stable. Make sure the build has already passed smoke testing. The core system should load properly and nothing should be fundamentally broken before a sanity check begins.

3. Identify the specific scenarios to test. Select a small set of checks that target the updated area directly. If a login button was fixed, that means valid credentials, invalid credentials, and the redirect afterward, and nothing further afield.

4. Run the checks and stop on failure. Execute the selected scenarios and watch the results closely. If a key check fails, stop immediately and send the build back for fixing rather than continuing.

5. Watch for side effects nearby. While testing the updated feature, keep an eye on whatever sits closest to it. This is not a full regression pass, but an unexpected issue turning up right next to the change is exactly what a sanity check is positioned to catch.

What makes sanity testing faster to scope

The slow part of a sanity check is rarely running it, it is deciding what to run. That decision usually comes from memory: whoever is closest to the change guesses at what else the fix could plausibly touch. True Production Insights in Katalon True Platform gives that guess something to stand on, by tracking how the application is actually used in production and surfacing which flows a given change is likely to affect. That turns scoping from a fresh decision every time into a shortlist, without requiring teams to script a sanity check they will only ever run once.

Sanity testing works because it stays narrow. The moment it tries to cover more than the change in front of it, it stops being fast and starts being an undocumented, informal regression run. Keep it scoped to what changed, confirm the build already passed smoke first, and let regression testing own the broader question.