Smoke testing in software testing is a quick check that runs after a new build to confirm the basic features still work. If the login page won’t load or the app crashes on launch, there’s no point sending the build to the QA team for deeper testing.
The name comes from hardware engineering. When engineers powered up a new circuit, they watched for smoke. No smoke meant the device was stable enough to keep testing. Software teams borrowed the idea, and today smoke testing is one of the first gates a build has to pass before it moves down the testing pipeline. With release cycles shrinking and CI/CD pipelines pushing builds several times a day, this short sanity check saves teams from wasting hours on a broken version.
What Smoke Testing Actually Means
A smoke test is a small group of test cases that touch the most important paths of an application. The goal isn’t to find every bug. It’s to answer one question: is this build stable enough to test further?
Imagine a banking app. A smoke test would check that a user can open the app, log in, view their balance, and reach the transfer screen. It wouldn’t verify every edge case in the transfer logic or test what happens when the network drops mid-transaction. Those belong to deeper functional and regression suites.
You’ll also see smoke testing called Build Verification Testing (BVT) or Build Acceptance Testing (BAT). All three names describe the same activity. According to the Wikipedia entry on smoke testing, the practice traces back to early software engineering teams at Microsoft and IBM, where daily builds needed a fast pass-or-fail signal.
Types of Smoke Testing
Teams generally run smoke tests in three ways, depending on how mature their testing setup is.
Manual smoke testing
A tester opens the app and walks through a short checklist by hand. This works fine for small projects or early prototypes where automation hasn’t been built yet. It’s slow but flexible, and the tester often spots visual issues a script would miss.
Automated smoke testing
A script runs the same checks every time a new build appears. Most modern teams use this approach because it fits naturally into a CI/CD pipeline. The script triggers, reports pass or fail, and the team moves on.
Hybrid smoke testing
Critical flows are automated, but a tester still does a quick manual walkthrough to catch anything the scripts can’t see, like layout glitches or odd animations. This gives you speed without losing human judgment.
How Smoke Testing Works in Practice
The process starts the moment a developer commits code and a new build is generated. The build moves to a staging environment, and the smoke test kicks off either automatically through a CI tool like Jenkins or GitHub Actions, or manually by a QA engineer.
The script or tester runs through a fixed list of core checks. For a web shop, that might be: site loads, user logs in, product page opens, item adds to cart, checkout page loads. Each step either passes or fails. If everything passes, the build is marked stable and handed over for sanity testing, regression testing, and other deeper checks. If any step fails, the build is rejected immediately and sent back to the development team with a short report.
The whole process should take minutes, not hours. If your smoke suite runs longer than 30 minutes, it has grown beyond its purpose and needs trimming.
A Real-World Example
Say your team ships a SaaS dashboard. A developer pushes a fix for the export feature on Tuesday morning. The CI pipeline builds the app and triggers the smoke suite. The script logs in with a test account, opens three core pages, runs a quick export, and signs out. All five checks pass in under four minutes. The build is promoted to the QA environment, and testers begin their full regression run.
Now imagine the login step fails because the developer accidentally broke the auth token. The smoke test catches it instantly. The build never reaches QA, the team gets a Slack alert, and the developer fixes the issue before lunch. Without that gate, testers might have spent half a day chasing problems caused by a single broken endpoint.
Smoke Testing vs Sanity Testing vs Regression Testing
These three often get mixed up. Here’s the cleanest way to keep them apart.
Smoke testing runs on a fresh build and checks broad, shallow coverage of the main features. It answers: does the build work at all?
Sanity testing runs on a stable build after a small change or bug fix. It’s narrow but slightly deeper, focused on the area that was just modified. It answers: did the recent change behave as expected?
Regression testing is the long, detailed pass that re-checks the whole application to make sure nothing old broke when something new was added. It answers: is the entire system still healthy?
Think of smoke as the front door, sanity as a spot inspection, and regression as the full home inspection.
Tools Teams Use
For automation, the common picks are Selenium for web apps, Cypress and Playwright for modern JavaScript stacks, Appium for mobile, and TestNG or JUnit for the underlying test framework. These scripts usually live inside a CI/CD tool like Jenkins, GitLab CI, CircleCI, or GitHub Actions, which runs the suite automatically on every build. For API-heavy products, Postman and REST Assured handle the same job at the endpoint level.
Why Teams Bother With It
Smoke testing protects everyone’s time. Developers get fast feedback when they break something obvious. Testers don’t waste hours digging into a build that was never going to work. Product managers get more reliable release windows because broken builds are caught at the earliest possible point.
There’s also a quieter benefit. A consistent smoke suite forces the team to agree on what counts as a critical path. That conversation alone often surfaces assumptions nobody had written down.
Limits to Keep in Mind
Smoke tests are shallow by design, so they miss most bugs. A passed smoke test does not mean the build is good, only that it’s testable. Teams sometimes get a false sense of safety and skip deeper testing, which leads to issues slipping into production. The suite also needs maintenance. As the product changes, old smoke checks become outdated and new critical flows need adding. A neglected smoke suite quickly stops catching real problems.
FAQ
Who runs smoke tests, developers or QA?
Both. Developers often run a quick smoke check locally before pushing code. QA teams run the official suite after the build lands in the test environment. In automated pipelines, the CI server handles it without anyone clicking a button.
How long should a smoke test take?
Aim for under 10 minutes for most projects. Anything longer slows down the pipeline and defeats the purpose. If your suite has grown bigger, it’s probably mixing in checks that belong to sanity or regression testing.
How many test cases should a smoke suite have?
There’s no fixed number, but most teams keep it between 5 and 25 cases. The rule of thumb is to cover only the flows that, if broken, would make further testing pointless.
Is smoke testing the same as acceptance testing?
No. Acceptance testing checks whether the software meets business requirements and is usually done before release. Smoke testing checks whether a build is stable enough to test at all, and it happens much earlier in the cycle.
Can smoke testing replace regression testing?
Never. Smoke testing is a quick gate, while regression testing is a full health check. Skipping regression because smoke passed is one of the fastest ways to ship a broken release.
What happens when a smoke test fails?
The build is rejected and sent back to the development team with details about which check failed. No further testing happens on that build. The developers fix the issue, a new build is generated, and the smoke test runs again from the start.