Smoke Testing

 Smoke Testing comes into the picture at the time of receiving build software from the development team. The purpose of smoke testing is to determine whether the build software is testable or not. It is done at the time of "building software." This process is also known as "Day 0".

It is a time-saving process. It reduces testing time because testing is done only when the key features of the application are not working or if the key bugs are not fixed. The focus of Smoke Testing is on the workflow of the core and primary functions of the application.

Testing the basic & critical feature of an application before doing one round of deep, rigorous testing (before checking all possible positive and negative values) is known as smoke testing.

In the smoke testing, we only focus on the positive flow of the application and enter only valid data, not the invalid data. In smoke testing, we verify every build is testable or not; hence it is also known as Build Verification Testing.

When we perform smoke testing, we can identify the blocker bug at the early stage so that the test engineer won't sit idle, or they can proceed further and test the independent testable modules.

Note:

• The test engineer knows that the module is independent testable because we have already done one round of smoke testing on them.
• The development team can take their time to fix the bug, and they are not under pressure because the testing team is not sitting idle, and the release does not get postponed, hence it is a time-saving process.

Process to conduct Smoke Testing

Smoke testing does not require to design test cases. There's need only to pick the required test cases from already designed test cases.

As mentioned above, Smoke Testing focuses on the workflow of core applications so; we choose test case suits that covers the major functionality of the application. The number of test cases should be minimized as much as possible and time of execution must not be more than half an hour.

When we perform smoke testing

Generally, whenever the new build is installed, we will perform one round of smoke testing because in the latest build, we may encounter the blocker bug. After all, there might be some change that might have broken a major feature (fixing the bug of or adding a new feature could have affected a major portion of the original software), or we do smoke testing where the installation is happening.

When the stable build is installed anywhere (Test Server, Production Server, and User Acceptance testing), we do smoke testing to find the blocker bug.

Let's use some different scenarios, which help us to understand better when to do smoke testing:

Scenarios 1

The developer develops the application and handed over to the testing team, and the testing team will start the functional testing

Suppose we assume that four days we are given to the functional testing. On the first day, we check one module, and on the second day, we will go for another module. And on the fourth day, we find a critical bug when it is given it to the developer; he/she says it will take another two days to fix it. Then we have to postpone the release date for these extra two days.

To overcome this problem, we perform smoke testing, let us see how it works, in the above situation, instead of the testing module by module thoroughly and come up with critical bug at the end, it is better to do smoke testing before we go for functional, integration and system testing that is, in each module we have to test for essential or critical features, and then proceed for further testing as we can see in the below images:

Scenario 2

While performing the functional testing, if the test engineer identifies the major bug in the early stages, sometimes it is not suitable for the developer to find a major bug in the initial stages. So the test engineer will perform the smoke testing before doing the functional, integration, system, and other types of testing.

While doing smoke testing, the test engineer finds the major bug; he/she will give to the development team for fixing the bug. After the bug is fixed, the test engineer will continue for further testing as we can see in the below image:

Scenario 3

In this scenario, if we are already perform the smoke testing and found the blocker bug and also resolved that bug. After performing the system testing, we will send the application from the testing server to the end-user server for one round of user acceptance testing. And when the customer performs the acceptance testing and does not find any issues and satisfied with the application because we already perform the smoke testing.

Scenarios 4

Once the acceptance testing is done, the application will be deployed to the production server. We have done a round of smoke testing on the production server to check whether the application is installed correctly or not. If any real end-user will found any blocker bug, they will get irritated and will not use the application again, which may lead to the loss of customer business as we can see in the below image:

For not getting this problem in the future, the development team manager, the testing team manager, will take the customer login and do one round of smoke testing.

For example, the real user using the Facebook application and every time we got new features updated internally, and the actual user will not affect because they will not aware of the internal changes and use the application properly.

In the production server, smoke testing can be done by the Business analyst (BA), Development team manager, testing team manager, build team, and the customer.

Why we do smoke testing?

• We will do the smoke testing to ensure that the product is testable.
• We will perform smoke testing in the beginning and detect the bugs in the basic features and send it to the development team so that the development team will have enough time to fix the bugs.
• We do smoke testing to make sure that the application is installed correctly.

Note:

• In the early stage of application development, if we are doing smoke testing, it will fetch more number of bugs. But in the later stage of application development, if we do smoke testing, the number of bugs that we are going to catch in smoke testing will be very less. Therefore, frequently the effort spent on smoke testing is less.
• When we go for smoke testing on every build?

Whenever a new build is installed, we make sure that build is testable or not, and if it is testable, then we perform smoke testing like as we can see in the below image:

Types of smoke testing

Smoke testing is divided into two types:

Formal smoke testing

In this, the development team sends the application to the Test Lead. Then the test lead will instruct the testing team to do smoke testing and send the reports after performing the smoke testing. Once the testing team is done with smoke testing, they will send the smoke testing report to the test lead.

Informal smoke testing

Here, the Test lead says that the application is ready for further testing. The test leads do not specify to do smoke testing, but still, the testing team starts testing the application by doing smoke testing.

Real Time Example:

Suppose, we are using an eCommerce site, and the core working of this site should be login, specific search, add an item into the cart, add an item into the favorite, payment options, etc. Here we are testing function to place an order. After testing, the tester has to be sure and confident about the functioning of the function of the application.

Steps of the workflow are given below:

• Click on item
• Description page should be open.
• Click on Add to Cart
• The cart should be open
• Click on Buy Now
• Payment options should be displayed. Choose one of them.
• Order placed

If this function is working correctly, then tester will pass it in testing and test the next function of the same application.

Advantages of smoke testing

• It is a time-saving process.
• In the early stage, we can find the bugs.
• It will help to recover the quality of the system, which decreases the risk.
• It is easy testing to perform because it saves our test effort and time.