Sanity testing
Sanity testing is a narrow, targeted check that one specific area behaves correctly after a change to it. It decides whether deeper testing of that area is worth doing. It is deliberately shallow: it confirms the change did what it claimed, not that the rest of the system still works.
The longer version
The situation it exists for is narrow and common. A fix lands, or a small feature is added, and the question is whether the thing that was supposed to change actually changed. Running a full regression suite to answer that is disproportionate, and shipping without checking at all is how a fix that fixed nothing reaches a release. A sanity test is the proportionate answer in between.
It is usually unscripted and it is usually not automated, which is the practical difference from everything around it. Somebody who understands what the change was meant to do exercises the affected area and forms a judgement. That informality is the point: writing and maintaining a scripted test for every individual change would cost more than the check is worth, and the cases worth keeping graduate into the regression suite instead.
The distinction from smoke testing is a matter of shape rather than of depth. A smoke test is broad and shallow, run against a whole new build to decide whether it is stable enough to test at all. A sanity test is narrow and shallow, run against one area after one change. Teams use the two terms inconsistently and some use them interchangeably, which is worth knowing before an argument about definitions replaces the checking.
A sanity test is a gate, not a verdict. Passing one means the area is coherent enough to justify spending real testing time on it. It does not mean the change is correct, it does not cover the paths the change might have broken elsewhere, and treating it as a substitute for regression testing is how unrelated breakage reaches production.
Common questions
What is the difference between smoke testing and sanity testing?
A smoke test is broad and shallow, run against a whole build to decide whether it is stable enough to test further. A sanity test is narrow and shallow, run against one area after a specific change to that area. Both are quick gates rather than thorough passes, and the industry does not use the terms consistently.
Should sanity tests be automated?
Usually not, because a sanity test is tied to one particular change and a script written for it has no second use. The checks worth keeping belong in the regression suite, where they run against every future change. Automating the one-off case costs more to write and maintain than the check saves.
Does sanity testing replace regression testing?
No. A sanity test looks only at the area somebody changed, and the defects that hurt most are the ones a change causes somewhere nobody was looking. Regression testing exists precisely to cover the behaviour nobody meant to touch, so the two answer different questions and a team needs both.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.