A guide to smoke testing

A guide to smoke testing

Smoke testing is a software development process where a sufficient amount of code is written for a product to function enough to test the basic functionality of the product. It is a type of rudimentary software testing and, when used for API testing, a variety of black-box testing. This post is about smoke testing. What is it? Why do we need it? How to do it? You’ll find the answers here.


Table of Contents



Looking for an API monitoring tool?

Testfully offers multi-step tests, Email, Slack, SMS and PagerDuty alerts, team collaboration, historical test results and many more features. Import from Postman supported!


What is smoke testing?

Smoke Testing is a software quality assurance technique for the early detection of defects. A smoke test is intended to detect significant problems with a new or modified software release. It is done when the product is in a form that can show a functionality or behavior and not find bugs. Smoke testing is also known as sanity test, build verification test (BVT), or build verification (BV).

Smoke tests are typically automated and can be used to verify that the application is ready for further testing.


Origin of smoke testing

A quick search on the internet brings multiple stories about the origin of smoke testing. We shall share two of them with you!

The term smoke test comes from the practice of electronic hardware testing by checking for any sign of smoke before the device is soldered into place or further testing is commenced.

In the 1950s, the term “smoke testing " was used by aircraft manufacturers to ensure that their planes were in good working condition before they took flight. Essentially, it was a way for the manufacturers to smoke out any faults on the aircraft (haha).


What is the goal of smoke testing?

The goal of smoke testing is to determine if the software has any major faults or defects that need to be corrected. Smoke testing is conducted on an application after it has been coded, tested, and debugged.

Depending on the test target and test suite size, running functional and non-functional tests can be slow at times. As a result, QA teams often run smoke tests to discover what’s working and what isn’t before they invest more time and effort into complete functional testing and non-functional testing to save time and be nimble.


When should smoke testing be done?

Smoke testing makes sense when a sufficient amount of code is written for a product to function enough to test the basic functionality.

Continuous integration (CI) is a software development process in which new code changes are continuously delivered and immediately build, tested, and deployed into a live environment, usually with little or no human intervention. Smoke tests are generally one of the first tests executed by your CI pipeline as part of a build and deploy process. They should not replace your unit or functional tests, but they should help detect your codebase problems.

Smoke testing is a specific type of integration test that checks to see if a build is broken.


Benefits of smoke testing

  • Smoke testing is the first line of defense that tests the foundation or core code for a release
  • Smoke tests are quick and easy to run
  • Smoke tests can be used to identify problems in the build that might later manifest as bugs
  • While they do not guarantee that the software is error-free, smoke tests can provide an early indication of where there may be problems
  • Smoke tests prevent broken software handover to QA teams
  • Smoke tests do not require extra time investment as you can use standard functional tests for smoke testing

Looking for an API testing tool?

Testfully offers multi-step tests, local & deployed API testing, team collaboration, historical test results and many more features. Import from Postman supported!

How to do smoke testing (step by step)

Ideally, smoke testing should be one step within a CI pipeline. Moreover, we highly recommend leveraging functional tests for some of the most critical aspects of your software in a test suite for smoke testing.

We highly recommend running smoke tests daily against the code in the main branch

As we mentioned earlier, smoke tests are meant to be executed many times, and during each build, it’s essential to pick the functional tests that run fast enough. The below diagram shows a standard software development workflow with smoke testing included in it:

Agile software development workflow with smoke testing


Example smoke test for API

Login is one of the most critical aspects of any application, and most APIs offer some endpoint for token generation. Considering how vital the login feature is for an online business, A functional test for login validation makes it a good candidate for a smoke test. The diagram below shows a two-step smoke test for login verification.

Example API smoke test

comments powered by Disqus

Recent Articles

blog-image
7 HTTP methods and how to use them

HTTP protocol works by clients sending requests to the servers and servers responding to the requests. We do CRUD operations (Create, Read, Update, Delete) by sending HTTP requests with different HTTP methods, sometimes called HTTP verbs.



blog-image
Introduction to API Blueprint

API blueprint is a powerful high-level API design language for web APIs. In this article, we want to dive deeper into it and learn more about how it works, the differences between API blueprint and Swagger, and what makes it unique that leads to its extensive use. But before we dig into API Blueprint, we must ensure a solid base of information about the “API first approach” concepts.

blog-image
False positive & false negative in software testing

Exports in automated software testing have borrowed false positive and false negative terms from the medical examination field. In the medical field, the purpose of a test is to determine whether the patient has a particular medical condition or not. As far as software testing is concerned, a false positive indicates a bug when there is none. Conversely, a false negative indicates no bug when there is one.