Sanity Testing: When It Is Genuinely Different From Smoke

It is half past four on a Thursday. A customer has reported that the fee on the payment screen is wrong for one tier. Business accounts are being charged 1.9 percent where the pricing page promises 1.4 percent. A developer finds the bug in twenty minutes and pushes a fix.

The release goes out at six. The full regression suite is 840 cases and takes just over two hours, so it will not fit. Somebody has to look at the fix, decide whether it worked, and decide whether it broke anything nearby. That narrow check is sanity testing. This post covers what it is, why most teams already do it without naming it, and the one condition under which the separate name earns its keep.

What sanity testing is

Sanity testing is a quick, targeted check that a specific change did what it was supposed to do, and did not obviously break what sits next to it.

The scope is the change, not the build. That is the whole idea. You are not asking whether the application works. You are asking whether this fix works, and whether the code around it still behaves.

It is usually run after a bug fix or a small feature change, often late in a release cycle when a full regression run is not affordable. It is usually short, frequently unscripted, and almost always done by whoever knows the change best.

The honest part: most teams run one thing and call it two

Here is the thing most articles on this term will not say. In the large majority of teams, smoke testing and sanity testing are the same activity under two names.

Somebody deploys a build. Somebody else opens the app, signs in, clicks through the two or three screens that matter, and says it looks fine. Whether that gets logged as a smoke check or a sanity check depends on which word the team happened to adopt.

If that describes your team, you are not doing anything wrong. Two names for one useful habit is a vocabulary problem, not a process problem. It becomes a real problem in only two situations:

• An auditor or a customer asks what your release process is, and your documentation describes two distinct steps that nobody performs separately
• A new joiner is told to "run a sanity check" and has no idea what that means, because there is no written definition and no case list

Both are solved the same way, by writing down what actually happens rather than what a textbook says should.

The one condition where the distinction is real

There is a case where the separate term earns its place, and it is narrower than the textbooks suggest.

A smoke check is scoped to the build. It runs the same fixed set of cases every time, whatever changed, and it answers whether the build is worth testing.

A sanity check is scoped to the change. The cases are chosen after you know what was modified, and they answer whether that modification worked.

That difference has a practical consequence. A smoke suite can be written once and automated. A sanity check cannot be fully pre-written, because you do not know which cases you need until you know what the developer touched.

Take the fee bug from the opening. The sanity check for that fix is not the twelve case smoke suite. It is roughly this:

• The business tier now shows 1.4 percent rather than 1.9 percent
• The tier above it, at 1.1 percent for enterprise, is unchanged
• The tier below it, at 2.4 percent for personal accounts, is unchanged
• A 500.00 GBP payment on the business tier debits 507.00, matching the fee shown
• The daily cap still blocks a payment above 10,000.00, because the cap and the fee share a calculation path

Five checks, about four minutes, and every one was chosen because of what the diff contained. The fifth is the interesting one. Nobody would think to check a spending cap after a pricing fix unless they had seen that both read the same rounding helper.

None of that is knowable in advance, which is exactly why it cannot be a pre-written suite.

Writing a sanity check down, when it cannot be pre-written

This is where sanity testing gets awkward, and where most teams quietly give up on recording anything.

The check is decided in the moment, run in the moment, and then it evaporates. Three months later a similar bug appears in the same calculation. Nobody can say what was verified the first time. The knowledge was real. It just never became an artefact.

The fix is not to pre-write sanity cases, which is impossible. It is to capture two things afterwards:

• Which cases you ran, even as a list of five one line titles
• Which of them were chosen because of the change, rather than run out of habit

That second point is the valuable one. A sanity check that keeps selecting the same three cases for every fix in a given area is telling you something. Those cases are load bearing. They are being verified informally over and over, and they should be promoted into the written suite.

This is the same handoff that exploratory testing needs in order to leave a record. The work is unscripted by nature and the findings are valuable. The value only survives if somebody writes a short version down afterwards.

Who should run it

The person who understands the change, which is usually the developer who made it or the tester who reported the bug.

That is a departure from most testing advice, which prefers independence. The reasoning here is specific. A sanity check is about the blast radius of a diff, and judging blast radius requires knowing what the diff touched.

A tester with no visibility of the change will verify the obvious path and miss the shared calculation two screens away. In the fee example, they would confirm the percentage and stop. The daily cap would ship broken.

If your team splits this work, the practical middle ground is a short handover. The developer names what was touched and what shares code with it. The tester picks the cases. That conversation takes two minutes and is most of the value of the exercise.

What a sanity check does not tell you

It is worth being blunt about the limits. Sanity checks get over trusted at exactly the moment they are least reliable, which is late on a release day.

• It does not tell you the release is safe. It tells you one change behaved.
• It does not cover regression in areas you did not think to check. A fix touching shared code with a dependency you did not know about will pass a sanity check.
• It does not replace the regression suite. It buys you time until the suite can run.

That last point is the one to hold on to. A sanity check is a decision to defer, not a decision to skip. If a fix goes out on a sanity check alone, the full 840 cases still need to run afterwards, and somebody needs to own that they do.

Where it fits

Sanity testing sits between the build level gate and the release level suite. The build gate runs the same cases every time. The regression suite runs everything that still earns its runtime. Sanity testing is the narrow, change shaped check in between.

The wider map of testing types covers how the layers relate. The practical version is simpler than the vocabulary suggests. Decide what changed, decide what shares code with it, check both, and write down what you checked.

Keeping that written record is ordinary test case management work. It is what turns a Thursday afternoon judgement call into something the team can reuse.