Introduction
Smoke Testing and Sanity Testing are often confused with each other. It's a common misconception that they're the same. Nevertheless, each serve a different purpose in Software Testing Life Cycle. Therefore, it's important to grasp the key difference between sanity testing and smoke testing to apply the right test strategy during software testing. Throughout this blog post, you will discover the differences between smoke testing and sanity testing, how to perform each, and how to master each with an example.
Smoke Testing
Testing the application at a very high-level.
Smoke Testing, also known as Build Verification / Acceptance Testing, is a preliminary testing phase but one of the most critical tests that cover the most critical user scenarios and things that need to be working for a user to actually use our product on the most basic level. These tests should be simple and high-level and these are the kind of tests which should be run early and often.
To put it in another way, it checks whether the essential features of a software application are working correctly. Think of it as a quick health check for the application. The objective is not to perform in-depth testing but to discard any broken application, so that the QA team does not involve and waste time in installing and testing the software application. If Smoke Test fails, you can reject the build and send it back to developers.
When to use?
A new build of the software is received.
When a new module / functionality is added.
You need to catch severe issues early in the development process.
How to perform?
Whenever the Dev team provides a fresh build to the QA team. Fresh build = build has new changes made by the developer.
Determine the key functionalities that must work for the application to be considered viable.
Create a set of test cases that cover these critical scenarios.
Run the selected test cases on the new build.
Analyze the test results. If all critical functionalities pass, the build is considered “smoke tested” and can proceed to more extensive testing.
Example
Let’s say we are testing slack's web application, the most critical user flows that should be tested very first are signup, login, creating channels, joining channels and posting messages.
Sanity Testing
Checking a new functionality or bug fixes in depth.
After Smoke tests pass and when you are ensured that the build is stable Sanity testing is performed, it can be used to test minor changes in code or functionality, to confirm that the bugs have been fixed and there are no further issues introduced due to the new changes. It is a subset of regression testing. It focuses on specific areas or functionalities of the software that have been modified or added since the last round of testing (Smoke Test).
The goal of Sanity Testing is to verify that the recent changes haven’t adversely affected the core features of the application. It is a narrow and deep approach, unlike Smoke Testing which is broad and shallow.
When to use?
Specific changes or enhancements have been made to the software.
You want to confirm that recent modifications haven’t broken critical functionalities.
Time is limited, and you need a quick check after minor updates.
How to perform?
Get the build that contains specific changes or enhancements.
Determine which parts of the software are impacted by the recent changes.
Create test cases that focus on the areas influenced by the modifications.
Run the selected test cases on the modified build.
Review the test results. If the critical functionalities related to the changes pass, the sanity test is successful.
Example
In the context of testing Slack's web application, since Slack added the new feature Slackbot into it's application, Sanity testing would involve quickly verifying that the Slackbot provides custom responses to messages to members on the Slack app.
Conclusion
Alright, so wrapping things up, Software Testing is an integral part of the development process. An application can be tested in either of these ways to verify its quality quickly. Smoke Testing gives you a quick check to see if everything's working okay before diving deeper, while Sanity Testing makes sure the recent changes haven't thrown everything out of whack. In addition, they can be easily automated, saving time and effort for teams.