Sanity testing is a version of regression testing to ensure a specific section of the application is still working after a bug fix or a functionality improvement. This type of QA is different from smoke testing as it is typically focussed only on one or two functionalities whereas smoke testing is aimed at all major functionalities. When the test fails, QA reject the build and send it back to the developers for a fix.
Sanity testing doesn’t use prewritten scripts and is usually done when a quick check is required to see if the build is functional. A QA expert will identify the new features, functionality changes or fixes and then verify that the new implementation works as expected. The QA team will also ensure that the existing functionalities still work as expected. If the new and associated functional tests pass, the QA tester will approve the build as a pass.
The main advantage of sanity testing is that it reduces the time cost for a detailed regression testing. As it is focussed on a specific area, this type of QA provides a quick evaluation and minimises unnecessary effort. This type of QA helps us to detect errors in the early stages of software development and helps minimise time wastage in development cycles. Instead of waiting for all of the testing to be completed, the developers depend on sanity testing to figure the next steps. If the test is successful, the development team can move onto the next task and if the test fails the build goes back to the team for fixing. In most situations, regression testing follows a successful sanity test and that will be used to identify additional bugs.
One of the challenges of sanity testing is that it is usually undocumented and unscripted and so future references are not possible. It might be difficult for some testers, especially when they are new in that project. This type of testing doesn’t go to the design level of testing and it is difficult for the developer to identify and find a way to fix the issue. Also, sanity testing is focused only on certain functionalities which may miss issues with other functionalities.
To minimise the problems that arise due to testing not being scripted, an outsourced QA company can implement a simple way of documenting a sanity testing process. This can be done by creating a test run that uses a pool of existing test cases which can be derived from multiple modules. The results of these test cases are tracked to pass or fail the test, and this provides the developer and the tester a record of the testing that has been done.