Sanity Testing is done when as a QA we do not have sufficient time to run all the test cases, be it Functional Testing, UI, OS, or Browser Testing.

“ Sanity Testing as a test execution which is done to touch each implementation and its impact but not thoroughly or in-depth, it may include functional, UI, version, etc. testing depending on the implementation and its impact. ”

Following are some pointers to help you perform this testing successfully on a ‘mobile app’:

1. First of all, analyze the impact of the OS version on the implementation with your team.
2. On the above note, analyze for the phone models also i.e. are there any features of the phone that will impact the implementation? Is the implementation of behavior-changing with GPS? Is the implementation behavior changing with the phone’s camera? etc. If you find that there’s no impact, avoid testing on different phone models.
3. Unless there are any UI changes for the implementation it would recommend keeping UI testing on the least priority, you can inform the team (if you want) that UI will not be tested.
4. In order to save our time, avoid testing on good networks because it is obvious that the implementation is going to work as expected on a strong network. It would recommend starting with testing on a 4G or 3G network.
5. If we must test for a matrix of different OS and their version, It would suggest that you do it in a smart way. For instance, choose the lowest, medium, and the latest OS-version pairs for testing. we can mention in the release document that not every combination is tested.
6. On a similar line, for UI implementation sanity test, use small, medium, and large screen sizes to save time. We can also use a simulator and emulator.

Smoke Testing is not exhaustive testing but it is a group of tests that are executed to verify if the basic functionalities of that particular build are working fine as expected or not. This is and should always be the first test to be done on any ‘new’ build.

Smoke Testing Examples

1) Acceptance Testing

Whenever a build is released to the QA, smoke test in the form of an Acceptance Testing should be done

Let us take the following Examples as implementations done in a build to understand the smoke tests for those:

• Implemented the login functionality to allow the registered drivers to log in successfully.
• Implemented the dashboard functionality to show the routes that a driver is to execute today.
• Implemented the functionality to show an appropriate message if no routes exist for a given day.

In the above build, at the acceptance level, the smoke test will mean to verify that the basic three implementations are working fine. If any of these three is broken, then the QA should reject the build.

2) Integration Testing

Let us consider the following Examples of integration implementation for this testing:

• Implemented the integration of route and stops modules.
• Implemented the integration of arrival status update and reflect the same on the stops screen.
• Implemented the integration of complete pick up till the delivery functionality modules.

In this build, the smoke test will not only verify these three basic implementations but for the third implementation, a few cases will verify for complete integration too. It helps a lot to find out the issues that get introduced in integration and the ones that went unnoticed by the development team.

3) System Testing

As the name itself suggests, for system level, the smoke testing includes tests for the most important and commonly used workflows of the system.  This is done only after the complete system is ready & tested, and this testing for system-level can be referred to as smoke testing before regression testing also.

Before starting the regression of the complete system, the basic end to end features is tested as a part of the smoke test. The smoke test suite for the complete system comprises of the end to end test cases that the end-users are going to use very frequently.

This is usually done with the help of automation tools

Importance In SCRUM Methodology

Nowadays, the projects hardly follow the Waterfall methodology in project implementation, mostly all the projects follow Agile and SCRUM only. Compared to the traditional waterfall method, Smoke Testing holds high regard in SCRUM and Agile.

I worked for 4 years in SCRUM. And as we know that in SCRUM, the sprints are of shorter duration and hence it is of extreme importance to do this testing, so that the failed builds can immediately be reported to the development team and fixed as well.