Sanity Testing: What It Checks and When to Run It

Sanity testing is a quick, focused check that a bug fix or small change works as intended and hasn’t broken any features nearby. A tester usually tries the affected feature by hand, along with a few connected screens, without preparing formal test documents first. The goal is a fast yes-or-no answer before the update reaches users.

Every small fix forces the same decision on a software team: ship the correction now, or wait days for a full round of testing. Skipping checks risks a repair that fails in front of customers, while retesting the whole product after any minor change slows each release down. A short, targeted pass gives teams a middle path.

People often confuse sanity testing with smoke testing, and a widely used industry glossary once listed the terms as synonyms. Below, you’ll find what each pass includes, how the method relates to similar techniques, and when a quick check is enough. Familiarity with the product speeds the process up, which is why many companies hand this work to a dedicated QA team.

What Does Sanity Testing Actually Check?

A sanity check begins once a developer has fixed a bug. The corrected code goes into a build, a new version of the software that’s ready to try. From there, the tester looks at three areas:

• The fix itself: Repeating the exact steps that used to trigger the bug shows whether the result is now correct.
• Features that rely on the same data: Any screen that reads, displays, or sends that information gets a quick look.
• The next step a user takes: If customers usually head to a particular page afterward, the tester follows that path too.

Everything outside those three areas is left alone on purpose. A small scope lets a team run a quick check after every minor fix without holding up releases.

Sanity passes are also usually unscripted, meaning the tester works with no prepared list of steps. Most planned QA work follows written test cases, instructions listing every action and the expected outcome. Instead, an experienced tester familiar with the update decides on the spot what to try, which keeps the pass short.

A Sanity Testing Example: One Fix, Five Quick Checks

Imagine a booking app for a chain of clinics. Patients in other time zones reported that confirmed visits showed up one hour off. A developer corrects the code that converts local times, and the new build arrives for testing.

A sanity pass on the time fix could include five checks:

1. Switch time zones. Set a phone to another region, reserve a slot, and make sure the booking screen displays the correct hour.
2. Open the confirmation email. Check that the email lists the same appointment time.
3. Add the visit to a calendar. Verify that the event lands at the right hour.
4. Trigger the reminder. Make sure the notification the app sends quotes the same slot.
5. Reschedule once. Moving the appointment runs the corrected conversion again, so one change reveals whether the fix holds there too.

If all five checks pass, the update can ship with reasonable confidence. Any failure sends the fix back to the developer, along with the exact step that broke. Notice what the tester skipped: payments, patient profiles, search, and every other feature the change never touched. Those features get a full pass in the regular testing round before a bigger release.

Sanity Testing vs Smoke Testing: Two Different Questions

Smoke testing usually runs first on a new build and asks whether the software is stable enough to examine at all. A tester, or a script that repeats the same steps automatically, opens the app, logs in, and clicks through the main features. If anything crashes or a core screen won’t load, the build is rejected before any deeper testing begins. A sanity check happens later and asks a narrower question: does this specific fix work?

The International Software Testing Qualifications Board (ISTQB), which runs a widely used certification for testers, listed “sanity test” as a synonym of “smoke test” in the board’s 2023 glossary. The current edition defines smoke testing as a check that software is ready for planned testing. Sanity testing no longer appears there at all. In everyday work, however, many QA teams draw a clear line between the terms.

To learn who usually runs smoke and sanity checks, how much automation helps, and what typically triggers a run, read our dedicated article on sanity testing vs smoke testing.

Where Does Sanity Testing Fit Within Regression Testing?

Sanity testing is the narrowest form of regression testing. A regression is a feature that used to work and broke after a later update. Full regression testing rechecks the existing product to catch those failures, a job that can take days on a large platform. By contrast, a sanity pass looks for the same problem in a much smaller area, around one fix.

Splitting the effort by size resembles the testing pyramid, a common planning model with many quick, cheap checks at the base and a few broad, slow ones at the top. The same logic applies here: sanity passes run after nearly every fix, while a full regression run waits for a release.

A related term, retesting, means confirming that one reported bug is really gone. Every sanity pass begins there, then looks one step further, at the features next to the fix.

The table below lines up the three checks covered in this section, plus smoke testing for reference:

When Should You Run Sanity Testing?

A sanity check fits situations where a change is small, the risk stays contained, and a full regression round would delay the update for little gain. Common examples include:

• A hotfix: This urgent correction ships outside the usual schedule, often while customers are affected, so the check has to be fast.
• A small fix between releases: A wrong price label or a broken button can be confirmed on the spot, with no need to retest everything.
• A settings change: Adjusting a configuration, such as a tax rate or a switch that turns an option on, alters how the product behaves without any new code. The affected screens still deserve a look.
• A third-party update: When a payment provider or map service updates the tools your app relies on, every connected feature gets a sanity pass.

Some areas of a product get fixed again and again, such as checkout or login. For those spots, automation testing can turn the most common sanity checks into scripts that run within minutes of every update. Testers then have more time for hands-on exploration.

When a Sanity Check Isn't Enough

Sanity testing falls short when an update is big or risky, because the effects of a large change can spread far beyond the edited code. For example, a new feature, a redesign, or new rules for payments or account access can break screens that a narrow check would never visit.

Even a small change can be risky when it touches a core system, as Google Cloud’s June 2025 outage shows. A routine data update with a few blank fields triggered a flaw in code that had shipped two weeks earlier without safeguards. According to Google’s incident report, more than 60 Google Cloud and Workspace products went down for about 3 hours as a result. Changes that touch core systems need a full regression round and a gradual rollout, where an update reaches a small group of users before everyone else.

How Does QAwerk Run Sanity Checks Between Releases?

On client projects, a sanity pass at QAwerk has four parts:

1. Read the change. We review the bug report and the developer’s notes to understand the problem and the solution.
2. List what the fix touches. Next, we note every feature and page that shares data with the corrected code, then confirm that list with the developer.
3. Check the new build by hand. The tester repeats the original bug steps, then walks through each connected screen as a customer would.
4. Report a clear verdict. Your team gets a plain answer: ship the update, return the code for more work, or schedule full regression testing because the change reached further than expected.

Of course, no two projects are exactly alike. Here are two examples of how that routine plays out with real clients:

• Surgical training simulators: VirtaMed builds virtual reality simulators where surgeons practice keyhole surgery with haptic feedback, the sense of touch recreated in the instruments. Realistic contact between simulated tools and organs is hard to program. One of our bug reports, for example, described a gallbladder passing straight through surrounding tissue. When a minor fix lands, our testers confirm the repair and then go over the simulator’s main features. That mix of sanity and smoke checks suits a product where one physics change can affect a whole procedure.
• Identity checks on mobile: Thirdfort was replacing separate iOS and Android apps with one cross-platform version, and new builds arrived often. Critical bugs included errors when submitting Source of Funds details, a step that shows where a buyer’s money comes from. The app also froze while the enhanced ID screen loaded. Each fix was retested before the next update shipped. In addition, regression cycles covered the editing and back-navigation flows around that step.

Picking the right screens to check after a correction depends on knowing how a product fits together. Our dedicated QA engineers stay with one client across many releases, so the testers already know the links between features. When a change turns out bigger than expected, the same team moves straight into full regression testing, with no handover or fresh onboarding.

Get your next fix checked before release.

FAQ

What is sanity testing?

Sanity testing is a brief review of software after a developer fixes a bug or ships a small update, confirming the correction works and hasn’t damaged anything nearby. The name borrows the everyday phrase “sanity check,” meaning a quick look for obvious mistakes. A QA engineer usually works by hand, covering the changed area and nearby features, so the update can go live without a full testing cycle.

Is sanity testing manual or automated?

Most sanity testing is done by hand, because each fix needs a fresh judgment about what to examine, which an experienced tester can make quickly. Automation pays off when bugs keep appearing in the same place, such as a checkout flow that needs repairs several times a month. In that situation, a short set of saved scripts reruns the same checks after each update.

What is the difference between sanity testing and retesting?

The difference between sanity testing and retesting is scope. Retesting answers one question: has the reported problem disappeared? If an export button produced an empty file, retesting means clicking it once more and opening the result. A sanity pass goes further and also tries related features, such as other export formats or the download history, to make sure the repair caused no new problems.

Who performs sanity testing?

QA engineers usually perform sanity testing, ideally specialists who already know the product and understand the change. Developers sometimes run a quick check before handing a fix over, but an independent tester is more likely to spot side effects the author didn’t expect. Companies without in-house QA often give sanity testing to an external partner that works alongside the development team.

Can sanity testing replace regression testing?

Sanity testing can’t replace regression testing, because a sanity pass only examines one change and the features right next to the edit. Regression testing reviews the whole product and catches problems in areas nobody touched recently, such as a refund screen failing after someone reworked the shopping cart. Teams usually run sanity checks on small fixes during development and a complete regression cycle before each release.