What is Smoke Testing in Software Testing?

What is Smoke Testing in Software QA?

Smoke testing checks the core functionality of a program, to ensure that the program is ready for further testing. This prevents a QA team from attempting to run a full test of software that can’t complete basic functions. In the context of technology, the phrase “smoke test” comes from hardware testing. A new board is plugged in and the power is turned on. If there is smoke coming from the board, the power is turned off and testing is ceased. The term smoke test in technology is broadly used to test product features in a limited time. If key features don’t work or if key bugs haven’t fixed, testing is ceased so that further time is not wasted installing or testing the build.  Getting the identified issues fixed becomes the programmer’s top priority. Smoke Testing is essentially a subset of all defined/planned test cases that cover the main functionality of a component or system, to ascertaining that the most crucial functions of a program work, but not bothering with finer details. Some of the capabilities tested during the smoke test phase often include access to the application, logging in with a set of users (admin, regular user) and main modules of a particular application, and more.

Where Does the Expression “Smoke Test” Come From?

The term “smoke test” found its derivation in the construction industry. It originated from the practice of construction workers injecting smoke into water pipelines to validate that they do not leak, which helps avoid floods.

When is Smoke Testing Done?

The smoke testing is a testing process to make sure if the build received from the development team is testable or not. It is often called a “Day 0” check and it is done at the “build level.” A smoke test can also be run as part of the build process in concert with a more thorough test when the build is to be a release candidate. Work will begin when the GUI interface and database are stable. Additionally, smoke testing is often conducted when new basic functionality is added to a system. But, this is not an exhaustive test such as unit tests or regression tests. Sometimes a smoke test is not enough to test a change in detail when working on a module, especially when using new code. Running a smoke test with each build does not remove the responsibility from developers to test their changes before submitting them to the repository. Developers should run the smoke test manually before committing a change.

The image below depicts how smoke testing works.

How smoke testing works

The purpose of Smoke Testing

The main purpose of Smoke Testing is not to find bugs in the software, but rather, to let the system test team know what their starting point is. Smoke testing provides a goal for the developers and lets them know when they have achieved a degree of stability. The trick to establishing a good smoke test is to create a group of tests that are broad in scope, as opposed to depth.

Importance of Smoke Testing

Smoke tests disqualify bad builds at a low cost, making it easier to cope with frequent (such as daily) builds. Smoke tests are often automated and standardized from one build to the next. They test things that are expected to work, and if they don’t, it may mean the program was built with the wrong file or that something basic is broken. A smoke test is most useful for bug fixes and for looking for inadvertent interactions between existing and new functionality.

Characteristics of Smoke Testing

A smoke test should:

  • Be quick to run, where “quick” depends on the specific situation.
  • Be self-scoring, as any automated test should be.
  • Provide broad coverage across the system.
  • Be runnable by developers as well as part of the quality assurance process.
  • It need not be exhaustive, but it should be should be capable of exposing basic errors in a new build.

Advantages of Smoke Testing

  • Minimize the integration risk.
  • The quality of the end-product is improved, as it is likely to uncover both functional errors, architectural and component-level design defects.
  • Error diagnosis and corrections are simplified, as the test is associated with incremental (new build then smoke test and then rebuild etc.)
  • Sometimes it is confused with sanity testing however it is different and a smoke test is done first and does not go further than that.

Who Can Do the Smoke Testing?

The smoke test is an important part during the deployment process so it is required that the test team is aware of the application’s features that are the core of the business functionality.  The person in charge of the smoke testing should be able to test every module of the application. And, after performing the smoke testing, the tester should be able to approve or reject the deployed build.  In case that the build is rejected, the tester should be able to provide better feedback to the development team and process in a quicker way.



The Automation of Smoke Testing

To build a smoke test, the test team first determines which parts of the application make up the high-level functionality, and then develops automated procedures for testing the major parts of the system. In this context, major refers to the basic operations that are used most frequently.  These operations can be exercised to determine if there are any small or large flaws in the software. Examples of major functions include logging in, adding records, deleting records, and generating reports. Smoke tests may also comprise a series of tests verifying that the database points to the correct environment, the database is the correct version, sessions can be launched, all screens and menu selections are accessible, and data can be entered, selected and edited. When automating tests, the smoke test should be the first series of tests to automate.  Smoke testing through automation is a huge benefit and value to the customers as well as a time and a cost control for businesses. Build verification tests are added to the library of reusable scripts.  Performing a smoke test may require 1-2 days.  When testing the first release of an application, the test team may want to perform a smoke test on each segment of the system so as to be able to initiate test development as soon as possible without waiting for the entire system to become stable.

What is Sanity Testing?

Sanity testing is different than smoke testing and is done during the release phase to check the main functionalities of the application without going deeper.  It is also called a subset of Regression testing.

Smoke Test VS Sanity Test


In a project’s first release, a development team releases the build for testing and the test teams test the build. Testing the build for the very first time in order to accept or reject the build. This is Smoke Testing. If the test team accepts the build then that particular build goes on for further testing. Imagine the build has 3 modules: Login, Admin, Employee. The test team tests these main functionalities of the application without going deeper. This is Sanity Testing.

Smoke Testing is a Critical Step

The smoke test is an important part of the testing process cycle and it must not be skipped in any release.  The smoke test identifies issues so that they can be fixed before proceeding. By sacrificing the quality of smoke testing, it could have negative consequences that affect the real users and impact the business model.  If the application is not able to allow users to complete simple actions like accessing the application or logging into the application they may look for an alternative and that leads to a business losing a customer – something nobody wants.  Additionally, if the application being developed is for internal operations it can stop or delay business operations until the development team is notified and able to work on the fix. Smoke testing reduces rework and avoids in-depth testing of a system that is not stable.

Get Better Results with Nearshore Software Development
Enjoy offshore advantages without flying half-way around the world to meet your team. 

Finding and hiring great developers is only the tip of the iceberg. Cost, quality, dependability and process are all critical factors. Companies that develop or rely heavily on software, turn to Tiempo Development for:

  • Cost-Effective Software Development Resources
  • Dedicated High-Performing Agile Teams
  • Commitment to Ultimate Client Outcomes
  • Fast Ramp Up and Seamless Integration
  • Expert Resources Available in Almost Every Technology; Java, Python, .NET, React, Angular, PHP, etc.
  • Headquartered in the United States

If we’re not 100% certain we can fundamentally improve your performance, we’ll help you find someone who can.

Get Ultimate Outcomes!