In this article, we see what is Smoke Testing and Sanity Testing and also the difference between Smoke and Sanity Testing. Both smoke tests and sanity tests have their own objectives and priorities. These two types of testing play a key role in the success of a project.
Smoke and Sanity Testing come into the picture after build release. There is chaos in novice testers when it comes to the difference between smoke and sanity testing. Here in this article, let’s see what Smoke and Sanity Testing are and the difference between Smoke and Sanity Testing in detail with practical examples to understand easily. Hopefully, by the end of this article, you will get a clear idea of Sanity and Smoke Testing.
Check the below video to see “Smoke Testing Vs Sanity Testing”
Please be patient. The video will load in some time.
If you liked this video, then please subscribe to our YouTube Channel for more video tutorials.
Smoke Testing is done to make sure if the build we received from the development team is testable or not. It is also called as “Day 0” check. It is done at the “build level”.
It helps not to waste the testing time to simply testing the whole application when the key features don’t work or the key bugs have not been fixed yet. Here our focus will be on primary and core application workflow.
To conduct smoke testing, we don’t write test cases. We just pick the necessary test cases from already written test cases.
Do we really write test cases for all testing types? Here in this article, we have given a clear idea of choosing testing types to write test cases.
As mentioned earlier, here in Smoke Testing, our main focus will be on core application workflow. So we pick the test cases from our test suite which cover the major functionality of the application. In general, we pick a minimal number of test cases that won’t take more than half an hour to execute.
Real-Time Example: Assume, you are working for an eCommerce site. When a new build is released for testing, as a Software QA you have to make sure whether the core functionalities are working or not. So you try to access the eCommerce site and add an item into your cart to place an order. That’s a major workflow in most of the eCommerce sites. If this flow works, you can say this build is passed. You can move on to functional testing on the same build.
Sanity Testing is done during the release phase to check for the main functionalities of the application without going deeper. It is also called as a subset of Regression testing. It is done at the “release level”.
At times due to release time constraints rigorous regression testing can’t be done to the build, sanity testing does that part by checking main functionalities.
Most of the time, we don’t get enough time to complete the whole testing. Especially in Agile Methodology , we will get pressure from the Product owners to complete testing in a few hours or end of the day. In these scenarios, we choose Sanity Testing. Sanity Testing plays a key role in these kinds of situations.
Earlier I have posted a detailed post on “ Difference between Regression and Retesting ”. If you haven’t gone through it, you can browse by clicking on the link.
Same as Smoke testing, we don’t write separate test cases for Sanity testing. We just pick the necessary test cases from already written test cases.
As mentioned earlier, it is a subset of regression testing. When it comes to Sanity testing, the main focus is to make sure whether the planned functionality is working as expected.
Real-Time Example: Let’s take the same example as above. Assume you are working on an eCommerce site. A new feature is released which is related to Search functionality. Here your main focus should be on the search functionality. Once you make sure that the Search functionality is working fine then you move on to other major functionality such as payment flow.
Sanity & Smoke Testing Process:
Smoke Testing is also known as Build Verification Testing
Sanity Testing is also known as Surface Level Testing
For example: In a project for the first release, the Development team releases the build for testing, and the test team tests the build. Testing the build for the very first time is to accept or reject the build. This we call it Smoke Testing. If the test team accepts the build then that particular build goes for further testing. Imagine the build has 3 modules namely Login, Admin, Employee. The test team tests the main functionalities of the application without going deeper. This we call it Sanity Testing.
|SMOKE TESTING||SANITY TESTING|
|Smoke Test is done to make sure if the build we received from the development team is testable or not||Sanity Test is done during the release phase to check for the main functionalities of the application without going deeper|
|Smoke Testing is performed by both Developers and Testers||Sanity Testing is performed by Testers alone|
|Smoke Testing exercises the entire application from end to end||Sanity Testing exercises only the particular component of the entire application|
|Smoke Testing, build may be either stable or unstable||Sanity Testing, build is relatively stable|
|It is done on initial builds.||It is done on stable builds.|
|It is a part of basic testing.||It is a part of regression testing.|
|Usually it is done every time there is a new build release.||It is planned when there is no enough time to do in-depth testing.|
I have received many queries from my Facebook and Twitter followers on this.
Yes, we do automate Smoke test cases. It saves a lot of testing time. Assume you have 50-100 smoke test cases. To execute these 50-100 test cases, it may take time around 4-6 hours approximately. If you have automation scripts for these test cases, you can execute them once the build is released and confirm whether the build is passed or not in less than the time you spend on manually executing smoke test cases. So most of the teams automate smoke test cases.