Before starting detailed testing of a software application, QA engineers need to determine whether the application is stable enough for further testing. A newly deployed build may contain installation issues, broken functionality, or defects that prevent testers from proceeding with their planned test cases.
Similarly, when developers fix a specific defect or make a small change, QA engineers need to verify whether the affected functionality is working correctly before spending time on complete testing.
This is where smoke testing and sanity testing become important.
Both testing approaches help QA teams identify problems early, but they serve different purposes. Smoke testing checks whether the critical functionalities of a new build are working, while sanity testing verifies whether a specific change or bug fix works as expected.
For example, imagine a developer shares a new build of an e-commerce application. Before starting detailed testing, a QA engineer checks whether the application launches, users can log in, products are displayed, and checkout is accessible. This is smoke testing.
Later, the developer fixes a defect related to discount coupon calculations. The QA engineer verifies whether the corrected discount calculation works for different coupon conditions. This is sanity testing.
Understanding the difference between these approaches helps QA engineers select the right testing activities at different stages of the software development lifecycle.
In this article, we will understand smoke testing and sanity testing, explore their differences, and look at practical examples from real-world applications.
What Is Smoke Testing?
Smoke testing is a preliminary testing activity performed on a new software build to verify whether the application's critical functionalities are working correctly.
Its main purpose is to determine whether the build is stable enough for further testing.
When developers deliver a new build to the QA team, testers do not immediately start executing hundreds of detailed test cases. First, they perform a basic set of checks to identify major issues that could block further testing.
For example, consider an online shopping application.
Before starting detailed functional testing, a QA engineer may verify:
Whether the application launches successfully.
Whether the login page is accessible.
Whether users can log in.
Whether the product listing page loads.
Whether products can be added to the cart.
Whether the checkout page is accessible.
Whether the application connects to the required backend services.
If these critical functionalities are working, the QA team can proceed with detailed testing.
However, if the application crashes immediately after login or the shopping cart does not load, the build may not be suitable for further testing.
In that situation, the QA team reports the blocking issues and requests a corrected build.
When Should Smoke Testing Be Performed?
Smoke testing is generally performed:
After receiving a new build from the development team.
After deploying an application to a QA environment.
After a major integration or development update.
Before starting a complete functional testing cycle.
After a release candidate is deployed to a staging environment.
Smoke testing can be performed manually or through automated test suites.
Many teams automate smoke tests because the same critical checks need to be executed whenever a new build becomes available.
Practical Example: Smoke Testing an E-Commerce Application
Consider an e-commerce application where the development team has delivered a new build containing several updates.
The QA team needs to determine whether the application is ready for detailed testing.
The tester prepares a basic smoke test suite covering important application workflows.
Test Case ID | Test Scenario | Expected Result |
|---|
TC_SMK_001 | Launch the application | Application should open successfully |
TC_SMK_002 | Open the login page | Login page should load without errors |
TC_SMK_003 | Log in using valid credentials | User should reach the dashboard |
TC_SMK_004 | Open the product listing page | Products should be displayed |
TC_SMK_005 | Open product details | Product information should load correctly |
TC_SMK_006 | Add a product to the cart | Product should be added successfully |
TC_SMK_007 | Open the shopping cart | Cart details should be displayed |
TC_SMK_008 | Navigate to checkout | Checkout page should load successfully |
TC_SMK_009 | Open the order history page | Order history should be accessible |
These test cases cover the application's basic functionality.
Suppose the login page works, products are displayed, and users can add products to the cart. However, the checkout page displays a server error.
The QA engineer should report the issue because checkout is an important business workflow.
The team should investigate and provide a corrected build before proceeding with detailed checkout testing.
The objective is not to validate every possible checkout condition during smoke testing. It is to establish whether the basic functionality is available.
What Is Sanity Testing?
Sanity testing is a focused testing activity performed after a specific change, bug fix, or minor update to verify that the affected functionality is working correctly.
Its main purpose is to check whether the recent change behaves as expected and whether the related functionality remains stable.
Unlike smoke testing, sanity testing does not cover the entire application's critical workflows.
It concentrates on the particular area that has been modified.
For example, imagine a banking application where users are unable to transfer money when the transaction amount contains decimal values.
The developer fixes the issue and shares an updated build.
The QA engineer performs sanity testing by checking:
Whether users can transfer amounts containing decimal values.
Whether whole-number transactions still work.
Whether invalid transaction amounts are rejected.
Whether insufficient balance validation works.
Whether the transaction amount is reflected correctly in transaction history.
The tester focuses on the affected payment functionality instead of executing every test case related to login, account statements, profile management, and other unrelated modules.
When Should Sanity Testing Be Performed?
Sanity testing is generally performed:
After a specific bug fix.
After a minor functionality update.
After a small code change.
When an existing feature receives a targeted enhancement.
Before deciding whether the affected functionality is ready for further testing.
Sanity testing helps QA engineers quickly determine whether the recent change has addressed the reported issue.
Practical Example: Sanity Testing a Discount Coupon Bug Fix
Consider an e-commerce application where customers can apply discount coupons during checkout.
The QA team reports a defect:
"When a customer applies a 20% discount coupon, the application calculates the discount incorrectly."
The developer fixes the calculation logic and provides an updated build.
Now the QA engineer needs to verify the fix.
Test Case ID | Test Scenario | Expected Result |
|---|
TC_SAN_001 | Apply a valid 20% discount coupon | Discount should be calculated correctly |
TC_SAN_002 | Apply a 10% discount coupon | Application should calculate the correct discount |
TC_SAN_003 | Apply an expired coupon | Application should reject the coupon |
TC_SAN_004 | Apply a coupon to an ineligible product | Discount should not be applied |
TC_SAN_005 | Remove an applied coupon | Original order amount should be restored |
TC_SAN_006 | Apply a coupon with a maximum discount limit | Discount should not exceed the configured limit |
TC_SAN_007 | Verify the final payable amount | Total should include the correct discount, taxes, and delivery charges |
These scenarios focus on the modified discount functionality and its related calculations.
If the calculations work correctly, the QA engineer can confirm that the reported issue has been addressed.
However, this does not automatically mean the entire application is ready for release. Other testing activities may still be required.
Smoke Testing vs Sanity Testing: Key Differences
Although both testing approaches are used to validate software builds, their objectives and scope are different.
Comparison | Smoke Testing | Sanity Testing |
|---|
Main Objective | Verify basic application stability | Verify a specific change or bug fix |
Testing Scope | Broad but shallow | Narrow and focused |
Primary Focus | Critical application functionalities | Modified functionality and related areas |
When Performed | Usually after receiving a new build | Usually after a specific change or bug fix |
Test Coverage | Covers important workflows across modules | Covers selected scenarios around the change |
Test Cases | Basic and predefined test cases | Focused test cases based on the modification |
Execution Time | Generally short | Generally short |
Automation | Commonly automated | Can be manual or automated |
Build Acceptance | Helps decide whether the build is suitable for further testing | Helps decide whether the specific change works correctly |
Example | Verify login, product listing, cart, and checkout accessibility | Verify corrected discount calculations |
The simplest way to remember the difference is:
Smoke testing checks whether the application is stable enough for testing, whereas sanity testing checks whether a specific change works correctly.
Real-World Example: How Both Testing Approaches Work Together
Consider a banking application that receives a new build containing an updated fund transfer feature.
The development team has introduced changes to transaction calculations and fixed an issue related to transaction history.
The QA team can use both testing approaches.
Step 1: Perform Smoke Testing
After receiving the new build, the tester checks the application's critical workflows.
Application launches successfully.
Users can log in.
Account details are displayed.
Account balance is accessible.
Fund transfer page loads.
Transaction history page opens.
If these basic functionalities work, the build can proceed to further testing.
Step 2: Perform Sanity Testing
The tester now focuses on the updated fund transfer and transaction history functionality.
Transfer a valid amount.
Transfer an amount containing decimal values.
Verify insufficient balance validation.
Verify transaction reference generation.
Confirm that successful transactions appear in transaction history.
Check whether failed transactions are recorded correctly.
The tester verifies whether the recent changes work as expected.
Step 3: Continue With Detailed Testing
After successful smoke and sanity testing, the QA team can proceed with broader functional, integration, regression, security, and other required testing activities.
These testing activities provide additional confidence in the application before release.
Common Mistakes QA Engineers Should Avoid
Even experienced testers sometimes confuse smoke testing with sanity testing or use them interchangeably.
Here are some common mistakes and better approaches.
Common Mistake | Better Approach |
|---|
Performing detailed testing during smoke testing | Focus on critical application workflows |
Testing the entire application during sanity testing | Concentrate on the modified functionality and related areas |
Skipping smoke testing for new builds | Verify basic build stability before detailed execution |
Treating sanity testing as complete regression testing | Perform appropriate regression testing separately |
Using the same test cases for every build | Update test coverage according to application changes |
Ignoring related functionality during sanity testing | Check dependencies and nearby business workflows |
Assuming a successful smoke test means the build is defect-free | Remember that smoke testing provides only preliminary confidence |
Can Smoke Testing and Sanity Testing Be Automated?
Yes. Both approaches can be automated depending on the application, testing framework, and project requirements.
Smoke testing is particularly suitable for automation because critical workflows are generally repeated whenever a new build is delivered.
For example, Selenium or Playwright can automate basic browser checks such as application launch, login, navigation, and product listing.
For API-based applications, tools such as Postman or Rest Assured can verify important API responses.
Sanity testing can also be automated when the same targeted checks are repeated after frequent bug fixes or changes.
For example, an automated test can verify discount calculations whenever the pricing logic is modified.
However, not every sanity test needs automation. For small changes, manual execution may be faster and more practical.
The decision should depend on execution frequency, test stability, maintenance effort, and business risk.
Conclusion
Smoke testing and sanity testing help QA teams identify issues at different stages of software development.
Smoke testing verifies whether a new build's critical functionalities are working well enough to proceed with detailed testing. Sanity testing focuses on a specific change or bug fix to confirm that the modified functionality behaves correctly.
For example, when a new e-commerce build is delivered, smoke testing checks whether login, product listing, cart, and checkout are accessible. If developers later fix a discount calculation issue, sanity testing verifies the corrected calculation and its related scenarios.
Both approaches save testing time and help identify important problems earlier in the development cycle.
As a QA engineer, understanding when to perform smoke testing and when to perform sanity testing is important. Choose the testing approach based on the purpose of the build validation or code change, and do not treat either approach as a replacement for complete regression testing.
Join the conversation! Your thoughts help the community grow.