What Is Sanity Testing?

Sanity testing is a narrow, focused testing activity performed after a specific change — typically a bug fix or a minor feature update — to verify that the change works correctly and has not obviously broken related functionality. Unlike smoke testing, which broadly checks if the entire build is stable, sanity testing zeroes in on a specific area.

Think of the difference this way: Smoke testing is a doctor checking your vital signs (pulse, blood pressure, temperature) to see if you are generally healthy. Sanity testing is the doctor checking whether the specific medication they prescribed yesterday is working.

After a developer fixes a bug in the payment calculation, sanity testing verifies:

  1. The specific bug is actually fixed (the reported scenario now works correctly)
  2. Closely related functionality still works (other payment calculations are not affected)
  3. The area around the fix is stable (the checkout flow completes)

Sanity testing does NOT verify the entire application. It does not check login, search, or unrelated features. Those are regression testing concerns.

Sanity vs Smoke vs Regression: The Complete Comparison

CharacteristicSmoke TestingSanity TestingRegression Testing
PurposeIs the build stable?Does this specific fix work?Did anything else break?
ScopeBroad, shallowNarrow, deepBroad, deep
WhenAfter every buildAfter a specific fix/changeBefore release
Duration10-15 minutes15-30 minutesHours to days
AutomationUsually automatedUsually manualMix of both
WhoQA or CI/CDQA engineerQA team
Build rejected if fails?Yes — build is unusableMaybe — depends on severityNo — issues are triaged
Test casesPredefined checklistAd-hoc, based on the changePredefined suite
AnalogyGeneral health checkupChecking if the medicine worksFull body scan

When to Use Sanity Testing

After a Bug Fix

A bug report says: “The discount calculation shows 12% instead of 10% for orders over $100.” The developer fixes it. Before running the full regression suite, you perform a sanity test:

  1. Verify the exact scenario from the bug report now shows 10%
  2. Test a few related discount scenarios (order exactly $100, order under $100, multiple discounts)
  3. Verify the fix did not break the order total calculation

After a Minor Feature Update

The product team requests a small change: “Add a ‘Clear All’ button to the notification center.” Before full testing:

  1. Verify the button appears in the notification center
  2. Verify clicking it clears all notifications
  3. Verify individual notification dismissal still works
  4. Verify notification count updates correctly after clearing

After a Configuration Change

The DevOps team updates the database connection pool size from 10 to 50. Sanity testing:

  1. Verify the application still connects to the database
  2. Run a few database-heavy operations (search, report generation)
  3. Verify no timeout errors under normal usage

When NOT to Use Sanity Testing

  • As a replacement for regression testing. Sanity testing is a quick check, not a comprehensive verification. It does not replace the need for regression testing before release.
  • For major feature releases. If the change is significant (new module, architectural change), you need system testing and regression testing, not just a sanity check.
  • When the change scope is unclear. If you do not know what the change affects, sanity testing is insufficient. Do broader testing.

How to Perform Sanity Testing

Sanity testing is typically informal and exploratory:

  1. Read the change description — What was changed and why? What was the reported issue?
  2. Reproduce the original issue (if it was a bug fix) — Confirm the fix by running the exact scenario from the bug report
  3. Test related functionality — Check 3-5 closely related scenarios that might be affected
  4. Check for obvious side effects — Does the UI look correct? Do nearby features still work?
  5. Make a quick decision — Is the fix good enough to proceed with deeper testing, or does it need more work?

The Sanity Testing Mindset

Sanity testing requires experienced judgment. Unlike scripted test cases, sanity testing relies on the tester’s knowledge of the system to:

  • Identify what “related functionality” means for a given change
  • Recognize when something “looks wrong” even if there is no formal test case
  • Know when to stop testing (the fix is reasonable) versus escalate (the fix introduces new issues)

This is why sanity testing is usually performed by experienced QA engineers, not junior testers or automated scripts.

Exercise: Decide Smoke, Sanity, or Regression

For each scenario below, determine which type of testing is most appropriate: Smoke, Sanity, or Regression. Explain your reasoning.

  1. A new build was deployed to the QA environment this morning
  2. A developer fixed a bug where the “Export to CSV” button downloaded an empty file
  3. The team is preparing for a production release next week
  4. The DevOps team migrated the application to a new server
  5. A developer changed the sorting algorithm for search results to be faster
  6. The login page was redesigned with new branding, but the functionality is unchanged
  7. A critical security patch was applied to the authentication module
  8. The nightly build completed at 3 AM
HintAsk yourself: Am I checking if the whole build works (smoke), if a specific fix works (sanity), or if everything still works before a release (regression)?
Solution

  1. Smoke Testing — A new build deployed to QA. Run smoke tests to verify the build is stable before anyone starts testing. If smoke fails, reject the build.

  2. Sanity Testing — A specific bug was fixed (empty CSV export). Verify the exact fix works, test a few related export scenarios, and check that other export formats are unaffected.

  3. Regression Testing — Pre-release testing requires comprehensive verification that no existing functionality is broken. Run the full regression suite.

  4. Smoke Testing — Server migration changes infrastructure, not code. Run smoke tests to verify the application works correctly on the new server (can it connect to the database, can users log in, do pages load).

  5. Sanity Testing — A specific algorithm was changed. Verify search results are still accurate, test various search queries, check sorting order. If the change is extensive, follow up with regression.

  6. Sanity Testing + Targeted Regression — UI redesign with unchanged functionality. Sanity test that login still works with the new design. Then targeted regression on the login flow (password reset, SSO, session management) because the template changed even if logic did not.

  7. Sanity Testing followed by Regression Testing — Security patches are high-risk. First, sanity test that authentication works. Then, full regression on the authentication module (login, logout, password reset, SSO, session timeout, remember me) because security changes can have subtle side effects.

  8. Smoke Testing — Nightly builds should trigger automated smoke tests. If they pass, the build is ready for the QA team in the morning. If they fail, the team knows before they arrive.

Sanity Testing Workflow

graph TD CHANGE[Change Deployed
Bug fix, minor update] --> SMOKE{Smoke Test
Passed?} SMOKE -->|No| REJECT[Reject Build
Fix fundamental issues] SMOKE -->|Yes| SANITY[Sanity Testing
Verify specific change] SANITY -->|Fix works,
no side effects| REGRESSION[Proceed to
Regression Testing] SANITY -->|Fix does not work| RETURN[Return to Developer
Fix is incomplete] SANITY -->|New issues found| TRIAGE[Triage:
Block or proceed?] TRIAGE -->|Block| RETURN TRIAGE -->|Proceed with known issues| REGRESSION

Pro Tips

Tip 1: Sanity testing is about confidence, not coverage. You are not trying to find every possible issue. You are building enough confidence that the fix is reasonable and the area is stable before investing time in comprehensive testing.

Tip 2: Document sanity test results. Even though sanity testing is informal, document what you checked and the outcome. When the bug is reopened in production, you need to know what was verified.

Tip 3: Time-box your sanity testing. Set a limit — 15 to 30 minutes. If you cannot verify the fix in that time, either the fix is too complex for sanity testing or the change has bigger implications than expected.

Key Takeaways

  • Sanity testing is narrow, focused verification of a specific change or bug fix
  • It differs from smoke testing (broad stability) and regression testing (comprehensive verification)
  • Performed manually by experienced QA engineers who use judgment and system knowledge
  • Appropriate after bug fixes, minor updates, and configuration changes
  • Not a replacement for regression testing — it is a quick check before deeper testing
  • Time-box to 15-30 minutes and document results for traceability