Sanity Testing

What is Sanity Testing?

The basic test to evaluate the result is true or not is called sanity testing. It comes under regression testing to ensure the code changes is working as expected. After this testing, developers take decision as to proceed with the build or not. The build is rejected if the test fails to save time and money. It just checks the functionalities of the application and the entire application is not tested. If the deployment is needed immediately, sanity testing is performed. It checks that after bugs fixing, other functionalities are not affected.

Why do we Need Sanity Testing?

Consider a scenario of testing the payment module of a web application, but during the testing, the payment page is not loading properly or the OTP field is not displayed to the user. The testers file a bug and report it to the developers. Developers then fix the bug of the page loading and OTP field of the payment page and submitted back to the testers for testing. There is no reason to do the more rigorous testing around the Payment page if the main bugfixes are not resolved. In this case, testers will now perform the Sanity testing around the Payment page in order to check the bug fixes, i.e. basic issues are resolved or not. It is also important to test if no other issues or bugs are raised in the related functionality because of the fixing of the previous issues.

In order to reduce the future time and effort in advance, it is performed before the deep, regression testing of the module. It tests the basic “rationality” of an application before the testing of the entire system.

How does Sanity Testing Work?

As we know that it is a quick and speedy testing, so there is a quick check performed around the application for the bug fixes, new functionality and any other changes made in the application. It is usually unscripted so no documentation and test case creation is done in the Sanity test of an application. The main objective of this is not the exhaustive testing of an application instead it focuses on the testing of a specific component.

When an application is a hand over to the testers for the Sanity test, no deep testing is performed around the whole application. Testers first test the bug fixes, new functionality of the application. It is basically a quick check done by the team of testers in order to pass/ fail the application to verify if it is ready for further in – detail testing. That is why it is also referred to as ‘Tester Acceptance Testing’. It usually saves time and money by failing the application after the quick check if the build is not good enough to go through further testing. After the testing of bug fixes and new functionality, related modules or interrelated functionality of an application is tested in order to verify that no new bugs were introduced because of the code changes or the fixing of previous issues.

For example, if in an application there are 2 modules, module 1 and module 2. Module 1 is related to module 2 as the data is transferred from module 1 to module 2. Previously if the bugs were found in module 2 and after fixing those issues by the developers, a new build is released for testing. Then testers will perform the basic Sanity test of an application of the newly deployed build, module 2 is tested first for the verification of fixed bugs in the new build and if module 2 is working fine, then the module 1 is also tested as both are related to each other in order to check if that fix has impacted the module 1 or not.

Advantages and Disadvantages

Some of the advantages and disadvantages are given below:

Advantages

Some of the advantages are given below:

• It is narrow and deep. Before testing the entire application, it helps in the testing of a particular component having bug fixes.
• Since no detailed documentation is required for Sanity testing of an application, no extra time is wasted and testers mainly focus on the testing of bug fixes and affected areas of application.
• It is very helpful since the efforts are not wasted in the regression testing if the defects are found during the Sanity test and the project is rejected at the early stages.
• Sometimes, it is very helpful in the early identification of compilation and deployment issues. If the basic functionality of an application is not working fine, or the previous bugs still exist but done from the developer’s end, there would be some merging or compilation issues.

Disadvantages

Some of the disadvantages are given below:

• It has only a narrow scope. It is not used for the detailed testing of the whole application. It is only used to test the basic functionality of a part of a module of the application.
• It is used to test the “rationality” of application, unlike smoke testing which checks the “stability” of an application.
• In case of small size applications, it is not that much helpful as it would consume extra time to verify the functionality of specific component instead of the whole application can be tested at that time.
• It is generally unscripted and sometimes consumes more time and indirectly increases the overall budget of the project.

Conclusion

The above description clearly explains Sanity testing and the importance of Sanity testing while testing any software application. Some testers always have confusion regarding the Smoke and Sanity test but both are very much different and used for their specific scenarios. Smoke testing is done to verify that the critical functionalities of the whole application are working fine or not. Being a tester, it is very important to understand the difference between the two.

Recommended Articles

This is a guide to Sanity Testing. Here we discuss the basic concept, working, need along with advantages and disadvantages in detail. You can also go through our other suggested articles to learn more –

1. Smoke Testing vs Sanity Testing
2. What is Automated Testing?
3. System Testing
4. White Box Testing vs Black Box Testing