Sanity tests and smoke tests are terms that are often used interchangeably. At the core, sanity tests make sure that a system is ready to test. That is the simplest definition, but it is a little more involved than that.

Sanity tests, or sanity checks, can involve two different ways of verifying the system is ready to be tested. The first part is to ensure that the system is stable and that all major components are functioning. These tests are just a small subset of regressions tests and generally touch only the major existing functionality. For instance, are all of the pages there? Is the system communicating with the web servers, media servers, mail servers, and databases? These are very quick and shallow tests to make sure that further testing is even possible. If the database communication was broken, then any other testing would be a waste of time and effort. These tests are easily automated.

The second part of sanity tests verify that any new functionality or bug fixes were actually applied. If your goal is to test a new functionality and it wasn’t put into the build, then spending hours creating the data to test it would be a waste of time. For each defect fixed, change applied, or functionality added, a sanity test must be done. These tests are manual and ad-hoc (or unscripted).

Once the stability of the application has been verified by the sanity tests, the heavy lifting can begin. This kind of testing saves a lot of time and frustration by making sure that the application is ready for the more specific tests and that it’s reasonable, or sane, to continue. If the sanity test fails, then the build is rejected.

QA Mentor’s Testing Execution On-Demand and our Manual Test Design and Execution Service is available to work with your developers, business analysts, and managers to design or perform your sanity tests. We can help you save time by identifying show-stopping issues before more thorough testing is even started.