MT - 17 - Smoke and sanity testing.

 

Lets see the diagram to understand the basic concept between smoke and sanity testing:









Smoke Testing:

Smoke Testing is performed after software build to ascertain that the critical functionalities of the program is working fine.It is executed "before" any detailed functional or regression tests are executed on the software build.The purpose is to reject a badly broken application, so that the QA team does not waste time installing and testing the software application.

In Smoke Testing, the test cases chosen cover the most important functionality or component of the system. The objective is not to perform exhaustive testing, but to verify that the critical functionalities of the system is working fine.
For Example a typical smoke test would be - Verify that the application launches successfully, Check that the GUI is responsive ... etc.

Smoke testing term came from hardware testing, when you get new hardware and power it on if smoke comes out then you do not proceed with testing.It is done to check the normal health of the build and make sure if it is possible to continue testing. It is done in the beginning of the software testing cycle.A subset of most basic and important test cases is selected and run to make sure that most basic and crucial functions of the software are working fine.
It follows shallow and wide approach where you cover all the basic functionality of the software.
Smoke test is scripted, i.e you have either manual test cases or automated scripts for it.
In some organizations smoke testing is also known as Build Verification Test(BVT) as this ensures that the new build is not broken before starting the actual testing phase.

Sanity Testing -

After receiving a software build, with minor changes in code, or functionality, Sanity testing is performed to ascertain that the bugs have been fixed and no further issues are introduced due to these changes.The goal is to determine that the proposed functionality works roughly as expected. If sanity test fails, the build is rejected to save the time and costs involved in a more rigorous testing.

The objective is "not" to verify thoroughly the new functionality, but to determine that the developer has applied some rationality (sanity) while producing the software. For instance, if your scientific calculator gives the result of 2 + 2 =5! Then, there is no point testing the advanced functionalities like sin 30 + cos 50.When there are some minor issues with software and a new build is obtained after fixing the issues then instead of doing complete regression testing a sanity is performed on that build. You can say that sanity testing is a subset of regression testing.
Sanity testing is done after thorough regression testing is over, it is done to make sure that any defect fixes or changes after regression testing does not break the core functionality of the product. It is done towards the end of the product release phase.It follows narrow and deep approach with detailed testing of some limited features.It is like doing some specialized testing which is used to find problems in particular functionality.It is done with an intent to verify that end user requirements are met on not.