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
| Feature | Smoke Testing | Sanity Testing |
|---|---|---|
| Goal | Verify overall build stability | Verify specific functionality after a fix |
| Verified By | QA + Developers (sometimes DevOps) | QA Team |
| Executed When | After a fresh build deployment | After a bug fix or minor update |
| Scope | Wide and shallow (covers major modules) | Narrow and deep (validates one area) |
| Stability Requirement | Ensures the build is stable for full QA | Ensures one specific module is working as expected |
| Scripted vs Exploratory | Usually scripted as a BVT (Build Verification Test) | Mostly unscripted or lightly scripted |
| Regression Relation | Pre-check before full regression | Quick check before deciding deeper regression |
| Time Taken | 10–30 minutes | 5–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.

![The Complete Software Testing Life Cycle (STLC) Guide [2025 Edition]](https://testingmint.com/wp-content/uploads/2025/11/The-Complete-Software-Testing-Life-Cycle.webp)

