[Sanity Testing vs Smoke Testing]

Differences between Sanity Testing and Smoke Testing

We will be discussing what smoke and sanity are in Software Testing. Software testing is a process that saves time and money. Smoke Testing and Sanity Testing make sure bugs and defects get exposed early in the development cycle. Most people get confused about the difference between Sanity Testing (or Smoke Testing). Both testing methods are different and can be performed in different phases of a testing process.

Understanding the terminology of smoke and sanity testing is essential before understanding how they relate to each other.

What is Build?

When a product is being tested manually, it is called build. This is software that includes a certain set of features/bugs. The build is used to modify the code and create the application format. Each new build will be an improved version.

What is Release?

Software testing uses it all the time. The release is the final product or project delivered to the customer. It covers all phases from Requirement to Design, Development, Testing, and Delivery until it is handed over. We can also say that a release refers to an entire application. The build, on the other hand, is the component of an application or software.

Smoke Testing:

Smoke Testing is not exhaustive, but it's a series of tests that are performed to determine if the fundamental functionalities of a particular build work as expected. This test should always be performed first on any "new" build.

The QA team releases a build for testing to the development team. It is not possible to immediately test the build and determine if there are any bugs or broken functionality.

What can QA do to ensure the functionality of the core functions is working properly?

Once all the tests are marked "Smoke" in the test suite, the build will be accepted by QA for regression testing and/or further testing. If any of these smoke tests fail, the build will be rejected by the QA team. The development team will need to fix the problem and release another build for testing.

The Smoke test can be described as surface-level testing to verify that the build submitted by the developer team to the QA group is ready for further testing. This is done by the development team prior to releasing the build the QA.

This testing is usually used in Integration Testing and System Testing. Do not consider this a substitute for real end-to–end complete testing. It includes both positive as well as negative tests depending upon the build implementation.

Smoke Testing Examples:

This is usually used to test Integration, Acceptance and System.

As a QA I was strict about accepting a build after I had done a smoke-test. Let's take a look at these three tests and show you how a smoke test works.

#1) Acceptance testing

When a build is released for QA, it should be subject to Acceptance Testing.

This test will verify the functionality of the implementation. In this way, you'll need to verify every implementation for the build.

We will use the following examples to show how we can understand the smoke testing for those.

The login functionality was implemented to allow registered drivers log in.

The dashboard functionality was implemented to show which routes a driver has to follow today.

Implemented functionality to display the appropriate message if no routes are available for a given day.

At the acceptance level, the smoke testing will be used to confirm that all three implementations work properly in the above build. The QA should reject the build if any of these three fail.

#2) Integration Testing

This testing takes place after each module has been implemented and tested. Integration Testing is used to verify that the end-to-end functionality and basic integration functions work properly.

It could be the combination of two or all of the modules. The complexity of the smoke tests will vary depending upon the level of integration.

Let's take a look at the following examples of integration implementation for this type of testing:

Implemented the integration between stop and route modules.

The integration of arrival status updates was implemented. It reflects the same on stop screen.

Integration of complete pick up and delivery functionality modules.

This build's smoke test will not only verify the three main implementations but will also check for integration in a few cases. It's helpful to discover the problems that are introduced during integration, and the ones that go unnoticed by developers.

#3) System Testing

Smoke testing covers the most commonly used workflows and important systems, as the name implies. This can only be done once the system is fully tested.

As part of the smoke testing, the basic features of the entire system are evaluated before they can be used in regression. The smoke test suite of the complete system includes the end to end test cases that the users will be using most frequently.

What is Sanity Testing?

It's used to determine if the build contains bugs. Most commonly, Sanity testing takes place on stable builds. It is also known to be a type of regression testing.

It is important to ensure that the features are working as planned. The build will be rejected if the sanity test fails. This is to avoid additional testing and costs.

SMOKE TESTING:

This method of testing began in hardware testing. It involves turning on a brand new piece of hardware and evaluating whether it fails to catch fire or make smoke. This is the most common type of testing in software. It covers all aspects of the application, without going too deep.

Smoke testing is either scripted (using a written set or an automated method).

Smoke tests can be used to check the entire application. It's both shallow and large.

This testing is done to make sure that only the most critical functions of a program work. However, it does not concern itself with the finer points.

This is a routine health check-up of the application's construction before it is tested in-depth.

SANITY TESTING:

A sanity check is a narrow, focused regression test that only examines one or two areas of functionality. Sanity Testing can be both narrow and in-depth.

This test is not usually scripted.

This test determines if a section of the application works again after a minor modification.

This is cursory test, and it is done when cursory analysis is not sufficient to verify that the application functions according to specifications. This level of testing is part of regression testing.

This is done to confirm that the requirements have been met by reviewing all features from the beginning.

This content is ariginnaly published by https://bqurious.mystrikingly.com/blog/the-ultimate-guide-to-smoke-testing-vs-sanity-testing