Smoke and Sanity Testing

What is Smoke Testing?
Smoke Testing is a type of software testing which is usually performed on initial software builds to make sure that the critical functionalities of the program are working absolutely fine.

 Smoke testing – it is executed before any functional or any regression tests are executed in detail on the software build. The main objective here is to reject a badly broken application so that the QA team does not waste time installing and testing the software application. Instead of performing exhaustive testing, we make sure that critical functionalities are working fine.

How to Conduct Smoke Testing?
Smoke tests can be performed manually or they can be automated. To execute smoke tests, you don’t need to write new test cases, instead, you can just pick the necessary test cases that are already defined by programmers. The primary focus here is to test the core application workflow. So, just pick those test cases that define the main functionalities of your software.

What is Sanity Testing?
Sanity Testing is a type of software testing which is conducted after receiving a software build, with minor changes in the code, or functionality. The aim is to make sure that the bugs have been fixed and to confirm that there are no further issues introduced due to the new changes.


Unlike smoke testing, the objective goal of sanity test is not to verify the core functionalities, instead, it is to verify the correctness and rationality of the software. It is usually done near the end of a test cycle, to ascertain if bugs have been fixed and if minor changes to the code are well tolerated. Also, to determine whether the most recent fixes have affected any component functionality. Sanity tests are often unscripted and can be performed manually, or with the help of automated tools

How to Conduct Sanity Testing ?
Similar to smoke testing, you don’t need to write new test cases unless a new feature is introduced. The main objective here is, to ensure that false results or bugs are not present in component processes. Also, to check whether the build is sane enough to move to further stages of software testing cycle.