What Is Sanity Testing? A Complete Guide with Examples

A developer fixes a bug in the checkout flow. The build gets pushed to QA. Now what?

Do you re-run the entire test suite before anyone signs off on this build? Or do you spend a few minutes confirming the fix actually works and nothing obvious broke nearby, so the team can decide what happens next?

That quick, targeted check has a name: sanity testing. It's one of the most commonly used testing types in software QA, and a misunderstood one, often confused with smoke testing or treated as a lighter version of regression testing.

This guide breaks down what sanity testing actually is, how it fits into the testing lifecycle, and how to run it well.

What Is Sanity Testing?

Sanity testing is a quick, unscripted check performed on a software build to confirm that a specific bug fix or minor code change works as intended and hasn't introduced any obvious new problems in the areas it touches.

It's a subset of regression testing, but far narrower in scope. Instead of re-verifying the whole application, sanity testing zeroes in on the parts of the software that actually changed, plus anything closely connected to them.

The name comes from the idea of a "sanity check." You're not proving the build is perfect. You're confirming it's rational enough to proceed with. If a login fix breaks the login page itself, there's no point running a lengthy regression suite against it. That build fails the sanity check and goes straight back to development.

Sanity testing is typically performed after a build has already passed smoke testing, once the team has a specific change or fix to verify. It doesn't follow a formal test plan or detailed documentation. Testers rely instead on their understanding of the application to decide what needs checking and how.

Why Sanity Testing Matters

Sanity testing earns its place in the release process for a few concrete reasons:

1. It catches obviously broken builds fast. If a fix doesn't work, or if it visibly breaks something nearby, there's no reason to invest hours in deeper testing. Sanity testing rejects that build early.
2. It's inexpensive to run. Because it's unscripted and narrowly scoped, sanity testing doesn't require dedicated test case design or extensive documentation
3. It gives teams a fast go-or-no-go signal. Before committing QA resources to a full regression pass, sanity testing tells the team whether that investment is worthwhile.
4. It supports frequent releases. Teams shipping multiple builds a day, common in agile and CI/CD environments, rely on sanity testing to keep pace without skipping verification altogether.

Key Characteristics of Sanity Testing

A few traits define sanity testing and set it apart from other testing types:

• Narrow and deep. It focuses on one feature or module in detail rather than skimming the whole application.
• Unscripted. Testers usually work without formally written test cases, relying instead on judgment and familiarity with the change.
• Undocumented, or lightly documented. Formal test reports aren't the priority here; speed is.
• Performed on a relatively stable build. The application needs to already be functional enough that a sanity check is meaningful.
• Fast. A sanity test typically takes minutes to a couple of hours, not days.
• Usually run by QA engineers or developers who already understand the change being verified.

Sanity Testing vs. Smoke Testing vs. Regression Testing

These three terms get mixed up constantly, largely because they happen around the same stage of the release cycle and all exist to catch problems early. Here's how they actually differ.

1. Smoke testing happens first. It's a broad, shallow check run on a brand-new build to confirm the application even starts up and its core functions, like login, navigation, and basic transactions, work at all. Smoke testing answers one question: is this build stable enough to bother testing further?
2. Sanity testing happens next, after a build has passed smoke testing or after a specific fix has been made. It's narrow and deep, focused only on the change itself and its immediate surroundings. Sanity testing answers a different question: did this specific fix work, without breaking anything obviously connected to it?
3. Regression testing is the most exhaustive of the three. It re-runs a large set of test cases, sometimes the entire suite, to confirm that new code hasn't broken any existing functionality anywhere in the application, not just near the recent change. Regression testing is typically scripted, documented, and often automated, and it can take hours or days depending on the size of the application.

In practice, these three often run in sequence: smoke testing decides if the build is worth touching, sanity testing checks the specific fix, and regression testing confirms the fix didn't have ripple effects elsewhere.

Also read - Smoke Testing vs Regression Testing: Key Differences

When Should You Perform Sanity Testing?

Sanity testing fits naturally at a few specific points in the development cycle:

• After a bug fix, to confirm the fix actually resolved the issue
• After a small, isolated code change or configuration update
• Before starting a full regression test cycle, to avoid wasting that effort on a broken build
• Before a production deployment, as a final targeted check
• After a new build in CI/CD pipelines, where it's often automated to run without manual intervention

Sanity testing is less useful for major feature releases, large-scale UI overhauls, or entirely new modules. Those changes are broad enough that they need full regression or exploratory testing instead.

The Sanity Testing Process

Running an effective sanity test generally follows four steps:

1. Review the change. Read the bug report, release notes, or commit log to understand exactly what was modified and why.

2. Identify what's affected. Decide which features or modules could realistically be impacted: the fixed area itself, plus anything tightly coupled to it.

3. Run targeted checks. Execute a handful of focused checks against those areas. This might mean manually clicking through a flow or running a small automated script, depending on the setup.

4. Make the call. If the checks pass, the build moves forward to regression or further testing. If they fail, it goes back to development. There's no need to dig deeper until the obvious problem is fixed.

This process is deliberately lightweight. The goal isn't full coverage; it's a fast, informed judgment call.

Manual vs. Automated Sanity Testing

Sanity testing can be done either way, and the right choice depends on how often builds ship and how complex the affected area is.

1. Manual sanity testing works well for small teams, early-stage products, or one-off fixes where the scope is small enough that a tester can verify it by hand in a few minutes. It requires no scripting overhead, which is part of its appeal, but it also depends heavily on the tester's judgment and doesn't scale well if it needs to be repeated constantly.
2. Automated sanity testing makes sense for teams shipping frequent builds, especially in CI/CD pipelines. A short automated script, often built with frameworks like Selenium, Appium, Cypress, or Playwright, can re-run the same targeted checks on every new build without manual effort, catching obvious breakages before a human ever looks at the release. The tradeoff is upfront setup time, which only pays off if the same checks will be repeated often.

Many teams use both: manual sanity checks for one-off fixes, and a small automated sanity suite that runs on every build as a first line of defense.

Also read - Manual Testing vs Automation Testing: Key Differences Explained

Sanity Testing Examples

Example 1: Streaming app, subtitle rendering fix. A video streaming app ships a fix for subtitles that were falling out of sync during playback. A sanity test here would play two or three titles, toggle subtitles on and off, and confirm they render correctly and stay in sync. It would not re-test unrelated areas like downloads, billing, or the recommendation engine, since those weren't touched by this fix.

Example 2: Banking app, password reset fix. A mobile banking app fixes a bug in its password reset flow. A sanity check would request a reset link, confirm the OTP arrives and is accepted, set a new password, and confirm login works with the new password and fails with the old one. It would skip unrelated areas like fund transfers or bill pay, since those modules weren't part of the fix.

Example 3: E-commerce app, promo code fix. An online store fixes a bug where a percentage-based promo code was calculating discounts incorrectly. A sanity test would apply that specific code, confirm the discount amount is now correct, check that an expired code is still rejected, and confirm the order total updates properly. Full checkout, shipping options, and payment gateway integration would only be retested if the fix touched that logic too.

In each case, sanity testing stays deliberately narrow: testing what changed, and what's directly connected to it, rather than the entire application.

Also read - What Is a Software Bug? [Definition, Types, Examples, and How to Avoid]

Limitations of Sanity Testing

Sanity testing is fast, but that speed comes with tradeoffs worth knowing before you rely on it too heavily.

1. Narrow scope means blind spots. A sanity test can pass cleanly while an unrelated part of the application is broken, simply because that area was never checked.
2. It depends on tester judgment. Because it's unscripted, the quality of a sanity test depends entirely on whether the tester correctly identifies what needs checking. A less experienced tester might miss a connected module that a more experienced one would catch instinctively.
3. It's not a substitute for regression testing. Sanity testing tells you whether a specific fix works. It doesn't tell you whether that fix broke something three modules away. That's what regression testing is for.
4. Lack of documentation can hurt traceability. Skipping formal test cases makes sanity testing fast, but it also makes it harder to prove exactly what was checked if a bug slips through later.

Sanity Testing Best Practices

A few habits make sanity testing more reliable without slowing it down:

• Stay focused on the change. Resist the urge to test unrelated areas. That's what regression testing is for.
• Keep a lightweight checklist. Even a short, informal list of what to check prevents testers from relying purely on memory.
• Automate the repeatable parts. If the same sanity check runs on every build, script it and plug it into CI/CD.
• Test in realistic conditions. Running sanity checks in a stable, production-like environment, using real devices and real networks rather than relying solely on emulators, helps avoid false passes that don't hold up once real users hit the build.
• Revisit the checklist as the app evolves. A sanity check that made sense six months ago may be missing a module that didn't exist back then.

How HeadSpin Can Help with Sanity Testing

Sanity testing is only as reliable as the environment it runs in. HeadSpin gives teams access to real, SIM-enabled devices across 50+ global locations, so a sanity check reflects how a fix actually behaves on real hardware and real-world networks rather than an emulator.

For teams that want to automate recurring sanity checks, HeadSpin supports 60+ automation frameworks, including Appium, Selenium, and Playwright, and integrates directly with CI/CD pipelines so the same targeted checks can run on every new build without manual effort.

HeadSpin's Regression Intelligence feature is well suited to the core question behind sanity testing: does this build behave rationally compared to the last one? It compares KPIs build-to-build, device-to-device, and network-to-network, and can trigger an alert automatically when a metric crosses a set threshold. Paired with AI-powered root-cause detection, it helps teams understand why a check failed without digging through logs by hand.

Conclusion

Sanity testing exists to answer one narrow question quickly: does this specific fix actually work, without obviously breaking what's nearby? As a fast checkpoint between "the code changed" and "we're confident enough to test further," sanity testing saves teams from wasting hours on builds that were never going to pass in the first place.

Used consistently, alongside smoke and regression testing rather than instead of them, sanity testing keeps release cycles moving without sacrificing the confidence teams need to ship.

FAQs

Q1. Who performs sanity testing?

Ans: Usually QA engineers, though in smaller teams developers often run sanity checks themselves since they're already familiar with the change.

Q2. How long does sanity testing take?

Ans: Typically minutes to a couple of hours, depending on how many areas are affected by the change. If it's taking much longer than that, it's probably drifting into regression testing territory.