Sanity testing is regularly used in software testing when there has been a code change or deployment to release new enhancements or bug fixes. In simple terms, it can be defined as a quick test conducted to ensure that the deployed changes work as expected and the current or recent update did not introduce any new flaws into the system.
During sanity testing, a tester performs a brief bug retest, then review any enhancements. Sanity testing can also be referred to as extension of retesting, as well as a subset of regression testing, and it is a less time-consuming method of providing feedback on the overall status of a build, which makes it easier to decide whether continuing testing is worthwhile or not.
In this post, we will discuss how to determine if sanity testing is needed, what the goal of sanity testing should be, and how can sanity testing help to achieve maximum output.
How to determine if Sanity testing is needed
We have seen a spike in demand for sanity testing lately. This is because more teams are adopting agile methodology and moving towards continuous testing which requires a quick turnaround from the tester. So when there are time constraints for running full regression tests, the testers opt instead to run sanity checks. So, sometimes sanity testing is used as a replacement for regression testing.
I want to share an experience from a recently completed project where we used to receive code fixes twice a week. Due to limitations with the platform and poor development, we had noticed that each time a fix was received, it also introduced at least 30% extra new bugs. As well as this, areas which had worked in the previous build were no longer working, and bugs kept floating from QA to development, then development back to QA. Despite knowing how bad the condition of the project was and because I only had one tester on the team, I had to abandon full regression and opt for sanity testing.because of the limited resources availability and need for a quick turnaround,
When determining whether it’s feasible to run a full regression test or only a sanity test depends on factors like time availability, the level of resources or the criticality of the application under test. If the project requires a weekly QA, there probably won’t be sufficient time to run full regression tests and the team may have to perform quick checks surrounding the critical functionalities, which makes sanity testing the preferred choice for the circumstances.
What you can expect from Sanity Testing
Before executing any plan, we make ourselves aware of goals and expectations. Similarly, the expectations for sanity testing must be clear, and risks raised and agreed upon by all the parties involved. Sanity testing can never be expected to reveal every bug in the system, but the primary intention of sanity testing is to ensure that bugs confirmed by developers as fixed are indeed fixed and working.
While the objective of sanity testing is to identify if functionalities work as expected, smoke testing and BVT(Build Verification Testing) are done to determine the stability of the release. While running your sanity checks, you may also get to know about the stability of the application and how firm the build is, which can help determine if the identified issues are process stoppers, and if further testing can be conducted or not.
The main advantage to sanity testing is that it provides quick input to help with driving decisions, but there are chances that issues can be slipped off and missed since sanity is not intended for verifying every area in detail.
How to conduct Sanity Testing
As a Quality lead, if you are looking to get the maximum benefit from the tests you run, the best approach would be to choose the right candidate to perform the review. It’s preferable to have someone who has been a part of the project right from the beginning. The reason being, the person will already have in-depth knowledge about the project and be aware of the bugs and dependencies required to perform sanity testing.
Sanity tests are not run from test scripts, so it’s advisable to be aware of the bugs or the changes planned for release to QA. It will help identify the areas that will require focus while testing. For instance, if a build is expected with a fix only for only a few bugs instead of all, the tester must have the list of those bugs. Once the list is shared and available to the tester, he or she must be able to determine their strategy and plan the sanity review.
Conclusion
Sanity testing is performed in almost 90% of projects, and for some small budget projects, it will be the only form of testing taking place. Sanity testing requires less effort and is one of the most cost-saving forms of testing; hence this is a highly preferred form of testing for startups.
