Human language:
In this article, we are going to get familiar with smoke testing, sanity testing, and the key difference between them. To begin with, let's consider each of these types of testing separately.
What is Smoke testing?
Smoke testing, also known as build verification testing or confidence testing, Is the type of testing performed to verify that the critical functionalities of the software are working fine and includes only quick scenarios that point at major areas of the product. It is performed on initial builds before they are released for extensive testing. Smoke testing is one of the important functional testing types. The main purpose of smoke testing is to verify whether all key functions are operational and to reject a software application with defects so that the QA team does not waste time testing broken software applications.
How does it work? When new software functions are built, the developer integrates them with an existing one, during this process the new build code integrates with the existing as a result we have a new build for testing with all the latest changes. The build might be stable or not, and the main reason for Smoke testing is to check that. It is done by both testers and developers because it is simple and requires little time. One of the best industry practices in software engineering is to conduct a Daily build and smoke test in software projects.
Pros of Smoke testing:
The results of this test help decide if a build is stable enough to continue with further testing;
It helps to find issues in the early phase of testing;
Smoke tests are very useful when you either don't have time or don't know where to start and need a quick test to show you the level of your product;
A very limited number of test cases is required to do the Smoke testing;
Improves the overall quality of the system.
Cons of Smoke testing:
Sometimes even after Smoke testing the whole application, critical issues arise in integration and system testing;
Smoke testing does not cover detailed testing.
What is Sanity Testing?
Sanity testing is the type of software testing performed after receiving a software build, with minor changes in code, or functionality, to ascertain that the bugs have been fixed, and no further issues are introduced due to these changes. Sanity testing is performed on stable builds. The main purpose of sanity testing is to determine if the proposed functionality works as expected. Sanity testing also ensures that the modification in the code or functions does not affect the associated modules. Consequently, it can be applied only to connected modules that can be impacted. Sanity Testing is done when a QA does not have sufficient time to run all the test cases. If the sanity test fails, the build is rejected to save the time and costs involved in more rigorous testing. It is also known as a variant of regression testing.
How does It work? The developer builds a new functionality, then adds it to the existing code and provides a new build for the QA Engineer, the QA Engineer tests it and creates bugs, after that, the developer fixes the issues and provides one more build with fixes. Changes made in code for solving these issues might fix the problem or might break the functionality even more than before fixing, and even affect other associated modules. That's why we have sanity testing.
Pros of Sanity testing:
It saves lots of time and effort because it is focused on one or a few areas of functionality;
It is used to verify that a small functionality of the application is still working fine after a minor change;
Since no documentation is required, these tests can be carried out in a lesser time as compared to other formal tests;
In case issues are found during Sanity testing, the build is rejected. This saves a lot of time and resources;
It helps to find related and missing objects;
Cons of Sanity testing:
Its scope is relatively narrow, compared to the other types of testing;
Sanity testing focuses only on the commands and functions of the software;
Sanity testing goes nowhere near the design structure level, so it’s very difficult for the developers to understand how to fix the issues found during the Sanity testing.
The main differences between these two types of testing are:
SMOKE TESTING: This is the first testing on the initial build - to verify the stability of the system VS SANITY TESTING: Done when the build is relatively stable to verify the rationality of the system;
SMOKE TESTING: Verifies the critical functionalities of the system VS SANITY TESTING: Verifies the new functionality bug fixes;
SMOKE TESTING: Exercises the entire system from end to end VS SANITY TESTING: Exercises only the particular component of the entire system;
SMOKE TESTING: Is performed by the developers or testers VS SANITY TESTING: in software testing is usually performed by testers;
SMOKE TESTING: Is a subset of Acceptance testing VS SANITY TESTING: is a subset of Regression Testing;
SMOKE TESTING: It is well elaborate and planned testing VS SANITY TESTING: This is not a planned test and is done only when there is a shortage of time;
SMOKE TESTING: Is usually documented and scripted VS SANITY TESTING: Is not documented and is unscripted.
The main similarity between Smoke and Sanity testing is that both Sanity and Smoke tests are ways to avoid wasting time and effort by quickly determining whether or not an application is fit for more rigorous testing.
Life example:
Let's take a look at the life example of smoke and sanity testing.
Example 1 - Smoke testing. Imagine that the development team develops a new functionality for any online shop named: Wishlist. The main goal is the possibility to add products to the wishlist from the product landing page, product detail page, and checkout. So the development team builds this functionality and provides a new build with it to the QA Engineer for testing. Then the QA engineer launches our online store with the corresponding build and starts the Smoke testing, which means starting checking the major areas of the product like:
Launching the Home page;
Navigation on the menu;
Navigation on the landing pages;
Possibility to make a registration;
Possibility to add the product to the bag;
Possibility to place the order. If any of the mentioned crucial functionalities don't work, the build rejects, and there is no sense to waste time testing anything else before the developer fixes the problem. It happens because it doesn't matter if I can add a product that I like to the wishlist, if there is no possibility for example add it to the bag and place the order at all.
Now let's take a look at the second example. Example 2 - Sanity testing. Imagine that the development team develops the same functionality as in the example for any online shop named: Wishlist. The main goal is the possibility to add products to the wishlist from the product landing page, product detail page, and checkout. As in example 1, the development team builds this functionality and provides a new build with it to the QA Engineer for testing. Then the QA engineer launch our online store with the corresponding build and start the smoke testing, the smoke testing is passed and the major areas of the product works stable. Then the QA engineer proceeds to test our new functionality Wishlist. During testing, the tester finds one issue with the wishlist, in particular, the product doesn't add to the wishlist in the checkout section, so the QA Engineer reports a bug. The next step is that our developer fixes the reported issue, and provides a new build in the test environment with the applied fixed and QA Engineer starts testing it. The main goal is to verify: if the reported issue is fixed. And also verify that the modification in the code or functions does not affect the associated modules, in our example, there is a product landing page, product detail page, and checkout. As example: Besides verifying adding products to the wishlist from the checkout, the fix might affect any function of the checkout itself, so It is necessary to quickly check the main functionalities of the checkout as well. This is our sanity testing.
Conclusion:
So, if you are asked at an interview: What is the difference between Smoke and Sanity Testing? The best way to answer is:
The main differences between these two types of testing are:
SMOKE TESTING: This is the first testing on the initial build - to verify the stability of the system VS SANITY TESTING: Done when the build is relatively stable to verify the rationality of the system;
SMOKE TESTING: Verifies the critical functionalities of the system VS SANITY TESTING: Verifies the new functionality bug fixes;
SMOKE TESTING: Exercises the entire system from end to end VS SANITY TESTING: Exercises only the particular component of the entire system;
SMOKE TESTING: Is performed by the developers or testers VS SANITY TESTING: in software testing is usually performed by testers;
SMOKE TESTING: Is a subset of Acceptance testing VS SANITY TESTING: is a subset of Regression Testing;
SMOKE TESTING: It is well elaborate and planned testing VS SANITY TESTING: This is not a planned test and is done only when there is a shortage of time;
SMOKE TESTING: Is usually documented and scripted VS SANITY TESTING: Is not documented and is unscripted.