Sanity Testing – Quick Tutorial on How to do Sanity Test

What is the first thought that comes to your mind when you hear the word ‘Sanity Testing’? You would make a guess by its name and as the name implies, sanity testing aims at checking whether the developer has put some sane thoughts while building the software product or not.

You are close to the answer. Sanity testing is a software testing technique which does a quick evaluation of the quality of the release to determine whether it is eligible for further testing or not. Today, we will explain the details of sanity testing and its importance. We will also explain the differences between sanity, smoke and regression testing which would give you a clear understanding of each of them.

Let’s get started so that we can tell you why we love sanity testing and why you should start loving it, too!

What is Sanity Testing?

Definition of Sanity Testing – “Sanity testing is a subset of regression testing that is focused on one or a few areas of functionality.”

Sanity testing is an unscripted form of testing. The testing team conducts basic tests which are focused on the new functionality or change and its impacts. It aims at testing whether the section of the application is still working after the changes. Sanity testing does not aim at catching all the bugs but it helps to identify any dependent missing functionalities.

Sanity is performed when a new functionality or change is implemented to see whether the software product is working correctly. It determines whether thorough testing of software product shall be carried out or not. If sanity testing fails, rigorous testing is not conducted. Thus, sanity testing saves a lot of time by quickly sending the release back to developers if it is of a poor quality. This also saves the rigorous testing effort.

How to do Sanity Testing?

Unlike other types of software testing, sanity testing does not come with a handful of techniques. You do not need to script the test cases for sanity testing because you want to perform quick and speedy testing. So, the first thing is to identify the new functionalities, changes or any bug fixes. Now, you will check the newly implemented changes if they are working fine. Then, you will randomly check a few related functionalities to see if they are also working as expected. If it goes good, the release can be passed for thorough testing.

Imagine the following scenario. You have several modules in your application. You have a user registration form in ‘Module X’ that allows the user to enter the data and submit it. The client has now requested to add ‘Preview My Profile’ button in the user registration form which enables the user to preview his profile before details are submitted.

The development team has implemented the requirement. The release is in your hands i.e testing team and you want to perform sanity testing. First, you will ask the developer or manager ‘what is new in this release?’ and he will inform you about the client’s requirement. Now, you will open the module X and perform some basic tests on ‘Preview My Profile’ button. You will also see if the ‘Submit’ functionality is still working fine. You will also verify any other functionalities on the user registration form. If things work fine, you will take the release for further testing.

Why we love Sanity Testing (and you should too!)

Before the argument begins, let’s suppose what would happen if sanity testing is not performed. When a new release comes in, the tester would put entire effort in preparing test cases, executing test cases, reporting the issues and logging the defects. The testing team would thoroughly test each and every functionality of the application and its user friendliness. Do you see any problem in this? No. But, there is a problem. This scenario sounds good only as long as the old and new functionalities in the new release are working.

What if the changes and the newer code have messed up your previous functionalities? What if the newer release is crashing down at every other action? Do you consider it wise to undergo such a release through the full testing cycle? No, because the testing effort would go into vain and tester would need to re-test all those functionalities.

Imagine yourself in the scenario and think ‘what is a wiser choice?’ A choice that could enable you to determine whether you should invest effort and time into testing the release or not.

Woohoo! That is the point where ‘Sanity Testing’ comes in and gives you a reason to love it. There are several reasons of why we love sanity.

Let’s have a look at those reasons and you will also start loving sanity test.

1. Speedy Evaluation

First, sanity testing offers speed. Sanity testing has a very narrow focus for functionalities or areas to be tested. You don’t need to script the test cases before carrying out sanity testing rather you use unplanned, intuitive approach to performing sanity testing.

2. Prevents Unnecessary Effort

Second, sanity saves unnecessary testing effort and time. Sanity testing determines whether the application should be further tested or not. This saves tester’s time if the release is in a very poor condition to meet the merit of rigorous testing. Also, testers do not need to report the issues or log them anywhere which saves the reporting time.

3. Enhance Regression Testing

Third, sanity testing is a subset of regression testing. It is verified that the application is functional in accordance with the requirements of the change or new functionality has been implemented.

4. Identify Deployment or Compilation Issue

Fourth, sanity testing might identify any deployment or compilation issue. For example, if the developers did not compile the build using all resource files, the tester might see unpleasant and unfriendly user interface. There can be any deployment notes which development team forgot to mention. Due to the remiss, the release might not be working, or even loading, in the test environment. Sanity testing helps to identify any such issue which can be quickly resolved and helps the tester to continue testing the otherwise well-functional release.

5. Quick Status of Release

Last, sanity testing gives you a quick state of the product which can help you plan your next step accordingly. If sanity test fails, you might plan your development team to postpone the next task and fix the flawed release first. On the other hand, if sanity test is passed you might ask your development team to go ahead with the next task while keeping only one developer on the fixes or allocating 1-2 hours for bug fixes on the daily basis.

Don’t you think these reasons are enough to love sanity testing?

Sanity Testing Vs Smoke Testing And Regression Testing

The terminologies ‘Sanity Testing’, ‘Smoke Testing’ and ‘Regression Testing’ are confused with each other. People use ‘sanity testing’ and ‘smoke testing’ interchangeably. However, there is a difference in all these testing techniques. Yes, that is why they have got different names.

Before we move on to the differences, let’s have a quick look at the definitions of sanity testing, smoke testing and regression testing.

Sanity Testing

As explained above, sanity testing offers quick, broad and shallow testing to determine whether it is possible and reasonable to proceed with further testing. It is a non-scripted form of testing that verifies if a small section of the application is working, after a change or fix, as expected or not.

Smoke Testing

Smoke testing ascertains that the critical functionalities of a software product are working fine. Smoke testing is conducted before sanity and regression testing. Some test managers also smoke test their product at the end of testing life cycle, when they are at the final stage to hand over their product to the client. It saves from any embarrassment that one might have to face when critical functionalities are malfunctioning.

It is important to note that smoke testing does not take new functionalities, changes or bug fixes into account. Rather, it tests the critical functionalities independent of the new feature, change or fix. Smoke testing does not aim at testing the application exhaustively, instead it tests the most important functionalities only. Typical example of smoke testing includes the successful launch of application, login, CRUD operation, responsiveness of user interface.

Regression Testing

Regression testing is the type of software testing which verifies that the older functionalities and features are still working. The purpose of regression testing is to check that the newer code or change has not impacted the previously correctly working functionalities adversely.

The main difference between regression testing and sanity testing is the ‘Scope of Testing’. Sanity testing has a narrow scope and focuses on only one or more functionalities, whereas regression testing has a broad scope. It checks all functionalities that might be directly or indirectly affected by the change or new code. It aims at catching all the possible bugs that might be present. The testing team follows a set of regression test cases and report the issues in the defect tracking system. The software product is regressively tested,once it clears the sanity testing.

Sanity Testing	Smoke Testing	Regression Testing
It is performed when a new functionality, change or bug fix is implemented.	It is performed in the initial phases when the release is unstable or at the final phase when the release is ready for deployment.	It is performed when a new functionality, change or bug fix is implemented.
It has a narrow scope.	It has only critical functionalities in the scope.	It has a broad scope.
The aim is to quickly verify if the new functionality, change or fix is working and has not broken down existing functionality.	The aim is to check if the critical functionalities are working as expected.	The aim is to check if the older functionalities are still working fine, after the change.
It does not catch all the bugs of the functional areas which are impacted by the code change.	It catches the bugs in critical functionalities only.	It catches all the bugs of the functional areas which are impacted by the code change.
It is non-scripted	It is scripted	It is scripted
It takes very less time to be performed.	It takes not more than 30 minutes.	It takes more time and testing effort.
It determines whether the application should be tested for regression.	It determines whether the application is stable or not.	It determines whether the old and new functionalities are working together correctly or not.

Conclusion

Let’s wrap the discussion and quickly take a recap of what we have discussed so far. Sanity testing is a tool to tell whether your software release meets the merit to be exhaustively tested or is too flawed to be tested. It is performed when a new functionality, change request or bug fix is implemented in the code. Its scope is narrow and focused on only functionalities which have been impacted by the change.

Many people confuse between sanity testing, smoke testing, and regression testing. In the article, we have also discussed the minor differences between sanity, smoke and regression testing.

We love sanity testing because it offers several benefits such as speedy evaluation of the quality of software release. It allows you to save time and effort by timely taking the decision to stop testing if it cannot pass through even the sanity testing. Sanity testing enhances the regression testing and verifies the application meets the user requirements after the implemented changes. Sanity testing is also used to give a quick status about the release and plan the next tasks accordingly.

What are your views on ‘Sanity Testing’? How important is it to perform sanity? Did you find it useful in your project? Do let us know about your opinion in the comment section below.