Let’s start by looking at this scenario: One fine morning, you are about to leave for the office in your car but it refuses to start. You are already short for time, and you have to test an important function of a product and the deadline is fast approaching. After trying several things, the car still refuses to start and in the end, you have to take a cab and reach the office very late.
After the mess this made of your day, over the weekend, you decide to buy a new car and head out to the local showroom in search of a decent sedan. After choosing a car, you (being a tester) decided to take a test ride and was satisfied with the result. The car is now in your possession and you can test the performance over the long run and analyze different features (fuel mileage etc.) which you were unable to do in the showroom.
What we learn from the above scenario is that the test ride you took at the showroom can be called Smoke Testing the product, where you looked into the basic features of the car and found them acceptable. Once purchased, testing the car in more detail will continue as you get to experience your new vehicle more fully, and this form of testing can be called Sanity Testing, again borrowing the phrase from the software test environment. Testers perform smoke testing to determine whether the application is acceptable for further testing or not, and when the build is deployed after minor fixes, sanity testing is performed to verify that issues have been fixed or not. It is a technique which is also known as narrow regression testing.
The Basic Concept of Sanity Testing
When time is short, Sanity testing can be a better option than not testing at all. It is performed to test the modules so their impact can be determined, but without going in-depth. It is useful when deadlines are strict and there is not enough time available to thoroughly test the application.
In an Agile environment, big releases are planned systematically and delivered to the client, whereas sometimes, as the situation demands, small releases need to be delivered where there is no extra time available for the testing, leaving no time for documentation of the test cases, bug reporting, or Regression Testing.
Items to Consider in Sanity Testing
Sanity Testing is performed when time is too short to test the build thoroughly, and it’s not possible to execute all the test cases. This situation risky, and the possible implications are tremendous. To minimise mistakes and oversights, a tester should take care of a few things at their end.
- It is advisable not to accept the build where there are no written requirements available. Sometimes the client conveys changes and/or requirements verbally and expects us to adjust accordingly. Compel the client to provide some written points on acceptance criteria.
- As said, sanity testing is done when there is not enough time to test the application thoroughly, leaving you unable to document bugs and test cases. This is a less than ideal situation so be sure to make your own notes. Document your bugs roughly on your notepad and if there is some time left, share those with your team for future reference.
- Throw the ball into the courts of others. Email the list of issues to every stakeholder.
- Automation testing can help reduce the pressure of manual efforts.
- Finally, draft an email containing the main details that you have tested, as well as what you did not test. Give justification and reasons for the bugs that have been resolved and those which have not been.
Advantages of Sanity Testing
- Sanity testing focuses on a few major areas of functionality which can help in identifying core functionality issues, ultimately saving time
- Sanity testing is usually non-documented
- During sanity testing, we are able to identify missing and dependent functionalities
Disadvantages of Sanity Testing
- The primary focus of the sanity test is to check that the functions of the application work as expected
- During times when deadlines are tight, organizations prefer to perform sanity testing (bypassing regression testing) which leaves some of the functionalities unattended. This can mean issues persist in the production environment leaving a bad impact on the businesses.
- As said, it is non-documented so no official reference is available.
Conclusion
In the end, the type of testing you choose for which situation depends on the intuition of testers. Devise a strategy to achieve your end-goal. Define how you will proceed and what you aim to achieve with the short time span.