Smoke Testing vs Sanity Testing with Examples

Smoke Testing is a broad, shallow test to check build stability, while Sanity Testing is a narrow, deep test to check specific functionality after a fix.
Smoke ensures the application is stable enough for further testing; Sanity ensures one specific area works after changes.

Smoke Testing vs Sanity Testing

FeatureSmoke TestingSanity Testing
GoalVerify overall build stabilityVerify specific functionality after a fix
Verified ByQA + Developers (sometimes DevOps)QA Team
Executed WhenAfter a fresh build deploymentAfter a bug fix or minor update
ScopeWide and shallow (covers major modules)Narrow and deep (validates one area)
Stability RequirementEnsures the build is stable for full QAEnsures one specific module is working as expected
Scripted vs ExploratoryUsually scripted as a BVT (Build Verification Test)Mostly unscripted or lightly scripted
Regression RelationPre-check before full regressionQuick check before deciding deeper regression
Time Taken10–30 minutes5–20 minutes

What is Smoke Testing?

Smoke Testing is a general health check of the application to ensure the latest build is stable enough for detailed testing.

It is sometimes called:

  • Build Verification Testing (BVT)
  • Confidence Testing

Analogy

“Starting your car to see if the engine runs without taking it on a full drive.”
If the engine doesn’t start, there is no point checking headlights or mirrors.

When Do You Perform Smoke Testing?

You perform Smoke Testing when:

  • A new build is deployed to QA.
  • After major merges or integration work.
  • When Dev says “build is ready for testing.”
  • After production deployments (mini smoke).

Example Scenario: Login Page Smoke Test

You’re checking if:

  • Login page loads
  • Username & password fields accept input
  • Login button works
  • User lands on dashboard

You are not checking Forgot Password, Multi-factor Auth, Profile settings, or other areas.
Your goal is simple: Does the build work enough to continue testing?

What is Sanity Testing?

Sanity Testing is a focused check performed to confirm that a specific bug fix or new minor functionality is working as expected.

Analogy

“Checking if the AC works after the mechanic fixed the fan, it’s not a full car inspection.”

When Do You Perform Sanity Testing?

You perform Sanity Testing when:

  • A specific bug has been fixed.
  • A new but small enhancement is added.
  • QA needs to confirm only that functionality is working.
  • Regression is too heavy for this stage.

Example Scenario: Forgot Password Fix

Developer fixes:
“OTP not sent when clicking Forgot Password.”

Sanity test checks:

  • Forgot password page loads.
  • OTP request works.
  • OTP is received.
  • Password reset completes.

You do not test login, signup, logout, or any other modules.
Goal: Confirm the fix is valid.

Key Differences Explained (Wide vs Narrow Testing)

Smoke = Wide & Shallow

You check:

  • Major modules
  • High-level workflow
  • Basic stability

You do not go deep.
You’re just making sure the product isn’t “broken.”

Sanity = Narrow & Deep

You check only:

  • The changed area
  • The fixed functionality
  • Dependencies connected to that area

This is not a full test cycle.
It pulls the focus to a very small region of the application.

Relation Between Smoke, Sanity & Regression Testing

Smoke Testing

Ensures the build is stable enough for regression.

Sanity Testing

Ensures specific changes are verified before regression.

Regression Testing

Ensures nothing else broke because of those changes.

Think of them as:

Smoke → Sanity → Regression

This flow is commonly used in Agile sprints.

Practical Testing Checklists

Smoke Test Checklist

  • Application launches
  • Essential pages load
  • Login works
  • Major navigation works
  • Critical buttons work (Add to Cart, Pay Now, Submit)
  • No major crashes
  • No blocker bugs
  • APIs respond (200 OK for primary endpoints)

Sanity Test Checklist

  • Specific bug fixed
  • Impacted area works as expected
  • Related fields validated
  • No new bugs introduced
  • Flow related to fix is stable
  • Quick re-validation of integration points

Code Examples for Smoke vs Sanity Suites

Below is a simple Java + TestNG example showing how testers separate Smoke and Sanity suites.

Smoke Test Suite

@Test(groups = {"smoke"})
public void verifyLoginSmoke() {
    driver.get("https://example.com/login");
    Assert.assertTrue(loginPage.isLoginButtonVisible());
    Assert.assertTrue(loginPage.canSubmitLogin("test", "password"));
}

Sanity Test Suite

@Test(groups = {"sanity"})
public void verifyForgotPasswordFix() {
    driver.get("https://example.com/forgot-password");
    forgotPage.requestOTP("test@example.com");
    Assert.assertTrue(forgotPage.isOTPSent());
}

How QA Teams Use These

  • Smoke suite is run on every new build.
  • Sanity suite is run on fix validation.
  • Regression suite is run after both pass.

Why Smoke is Scripted & Sanity is Exploratory

  • Smoke Testing is usually pre-defined and documented as a BVT checklist or automated suite.
  • Sanity Testing is often exploratory, because testers want to verify “quick and deep” behavior after a fix.

Conclusion

Smoke Testing checks “Is the build stable?”
Sanity Testing checks “Is this fix working?”

Both ensure quality and save time, especially in Agile sprints.
They are small, fast, targeted tests but their purpose is very different.

Related Post