Smoke Testing and Sanity Testing

Apart from similar names, Smoke Test and Sanity Test, both aims at reducing testing efforts. No doubt they are confused for each other.

Smoke Testing
Smoke Testing is the very basic and initial testing activity that verifies if the application/deliverable is testable or not. I read somewhere that “Smoke testing is like General Health Check Up”. It is generally applicable during Integration Testing, System Testing and Acceptance Testing.
Only positive scenarios are validated in Smoke Testing.

Scope – The set of test cases which verifies the functionality on a high level. Some basic scenarios may include:
1. Tester is able to access the application/deliverable.
2.  Tester is able to navigate through the application.
3. The user is able to interact with user interface.

Example– Following may be the test cases for a login page:
1. ‘OK’ button is logging in the user on entering some data in user name and password.
2. Cancel button is responding entering some data in user name and password and user remains on the same page.
 Type anything in the username and password field and press the OK button, the page should change and the request should have gone to the database to confirm if it is a valid request or not.

Advantages of Smoke testing:
1. Issues that arise due to integration of modules can be found.
2. Issues are found in the early phase of testing.
3. Induces confidence to tester that fixes in the previous builds have not broken major features.

Sanity Testing
Sanity Testing is a part of Regression Testing and it is performed when we do not have enough time for doing testing. I read somewhere that “specialized health check-up”.
Sanity Testing covers both positive and negative scenarios.

Scope – The set of test cases from regression test suite which quickly verified status of the product after they have done changes in the code or there is some controlled code change in a feature to fix any critical issue. Care must be taken care to:
1. Include only critical test cases in BVT.
2. Only stable test scenarios should be included
3. Test cases included should be sufficient for application test coverage.
Example Following may be the test cases for a login page:
1. ‘OK’ button is logging in the user on entering valid data in user name and password.
2. ‘OK’ button is not logging in the user on entering invalid data in user name and password.
2. Cancel button is responding entering some data in user name and password and user remains on the same page.
Some of the Test cases for Text editor may be:
1) Creating text file.

2) Writing something into text editor
3) Copy, cut, paste functionality of text editor
4) Opening, saving, deleting text file.

Advantages of Sanity testing:
1. Makes sure that developers have not defined conflicting or multiple functions or global variable definitions.
2. Helps to identify the dependent missing objects.
To conclude, consider purchasing a vehicle – Car or Bike.
We take it for a test ride and check basic functionalities– Smoke Test
We bring it home, ride it more and check detailed information (Mileage etc) – Sanity Testing

Regression Testing and Retesting

Difference between Regression Testing and Retesting is another one of the most frequently asked question in Software Testing interviews. So, a very straight forward and crisp answer would be –
Re-testing is the verification of defects to confirm that the functionalities are working as expected. When a bug is fixed, the test cases which failed with reference to it are executed again.
Regression Testing is performed to verify that any changes to the code (bug fixes, enhancements, code cleanup etc.) have not impacted the untouched or other functionalities of the software/application.
For example:

  • Consider an application ‘abc’ with modules ‘a1, b1 and c1’.
  • Some bug fixes are to module b1.
  • Retesting – Testing the bugs raised and module b1.
  • Regression Testing – Testing the areas affected by module b1 on a1 and c1.

Regression Testing
Image Source: MS Word Clip Art
The image above also represents basic Regression Testing and Retesting concept:
Rotten apple spoils the barrel –
Ensure the rotten one is removed ~Re-testing
Always go through the rest ~Regression Testing
Following is a detailed description of differences between Regression and Retesting.


Regression Testing

Retesting is performed to make sure that the tests cases which failed in last execution are passed after the defects against them failures are fixed.
Regression testing is performed to ensure that changes like defect fixes or enhancements to the module or application have not affected the unchanged parts of application.
Retesting is carried out based on the defect fixes.
Regression testing is not carried out on specific defect fixes. It is planned as specific area or full regression testing.
In Retesting, the test cases which failed earlier are included in the test suite.
In Regression testing, test cases which impact the functionality of application are included in the test suite irrespective of their passed/failed status in earlier runs.
Test cases for Retesting cannot be prepared before start testing. In Retesting only re-execute the test cases failed in the prior execution.
Regression test cases are derived from the functional specification, user manuals, user tutorials, and defect reports in relation to corrected problems.
Automation for retesting scenarios is not recommended.
Regression scenarios are the first candidates of automation testing
Retesting is performed before Regression.
Regression testing can be carried out parallel with Retesting.