--- title: "Smoke Testing: What It Is and When to Run It" description: "Smoke testing is a check that a build starts and its core paths work. Where it fits in the dev cycle, how it differs from regression, and best practices." canonical: "https://momentic.ai/blog/smoke-testing-in-software-development" last-updated: "2026-10-31T09:55:08Z" --- # Smoke Testing: What It Is and When to Run It URL: https://momentic.ai/blog/smoke-testing-in-software-development [blog](/blog) [/ resources](/blog/category/resources) / smoke-testing-in-software-development Resources What smoke testing is, where it sits in the release cycle, how it compares with other test types, and the practices that keep a smoke run short. Wei-Wei Wu CEO, Momentic Smoke testing is a short set of checks that runs on every new build to answer one question: does the build work well enough to test further? If the app starts, a user can log in, and the main journey completes, the build passes. If not, it goes back to the developers before anyone spends hours on deeper testing. Example: after a merge, CI deploys to staging and runs five tests: the home page loads, login works, search returns results, an item can be added to the cart, and checkout reaches the payment step. All five pass in under three minutes, so the regression suite starts. ## What Is Smoke Testing? Smoke testing in software development is a quick, initial round of software testing that verifies the most critical functions of your app work after a new deployment. The idea is that, if these functions fail, there is no point continuing with further testing until they are resolved. So, why ‘smoke’ testing? The term actually comes from hardware engineering processes. When engineers turned on a new device, they checked whether any smoke came out of any components before moving on to more detailed tests. Smoke testing your app is a similar concept. Smoke tests aren’t designed to uncover every defect; instead, they focus on cornerstone functionality such as: - Can the application launch successfully? - Can users log in? - Do main navigation menus work? - Can core forms be submitted? - Are APIs responding? - Can transactions be completed? - Are critical integrations connected? Smoke tests are usually broad but shallow. They cover many important areas quickly without going into detailed edge cases. Let’s say you’re releasing a new version of your e-commerce platform. A round of smoke testing should confirm that users can still browse products, add items to the basket, sign in, and complete checkout. If any of these functions fail, the build may be rejected immediately. ## What Are the Advantages of Smoke Testing? The main advantages of smoke testing are four: less time lost on broken builds, faster delivery, cheaper defect fixes, and one shared release checkpoint for development, QA and operations. Smoke testing is a fast and effective way to quickly test key features, particularly if you’re working in a CI/CD environment, which demands constant iteration and continuous release cycles. ### Smoke Testing Stops You from Wasting Time Smoke testing saves your team hours of wasted effort performing detailed tests on unstable builds. Checking the foundations first improves the reliability of further testing and ensures that any later effort is well-spent. ### Smoke Testing Supports Faster Delivery In CI/CD pipelines, smoke tests act as a sort of quality gate, and that’s important when you’re releasing several times per week. Smoke tests allow you to up your release frequency while maintaining control and confidence. ### Smoke Testing Makes Defect Correction Faster and Cheaper [Fixing critical issues earlier](https://momentic.ai/blog/complete-guide-to-shift-left-software-testing) is almost always cheaper than discovering them later in system testing or production. Finding and fixing critical defects at the smoke-test stage will save plenty of engineering hours that you can reinvest elsewhere. ### Smoke Testing Encourages Collaboration Across the Business Smoke testing creates a shared checkpoint between development, QA, and operations teams. It’s an objective measure that allows everyone to agree on whether a release is ready to progress. ## Smoke Testing in the Software Development Cycle: Where and Why? You should run smoke tests whenever your software changes in any meaningful way. This includes: ### **After a New Build Is Created** Whenever engineers create a new build, smoke testing should confirm that the app installs and launches without issue, and that basic functions work correctly. ### **After Code Merges** When multiple branches are merged into a shared environment, use smoke testing for a quick, meaningful indication of any integration issues. ### **Before Detailed Functional Testing** Smoke testing should happen before manual exploratory testing, regression testing, or performance testing so your team doesn’t waste time testing something that’s fundamentally broken. ### **After Deployments** Once software is deployed to staging, pre-production, or production environments, a quick round of smoke tests allows you to double check there are no major functionality issues. ### **After Infrastructure Changes** Changes to hosting environments, databases, cloud resources, or network configurations can create unexpected failures. Smoke tests help confirm everything still works properly after these updates. ### **In CI/CD Pipelines** Many organisations automate smoke testing to run after every commit or deployment for rapid feedback and to prevent major issues from building up further down the line. For where smoke tests sit among the other pipeline stages, see [CI/CD pipeline testing](/blog/cicd-pipeline-testing). ## Smoke Testing in Software Development: Comparison With Other Testing Types Smoke testing is not a replacement for other testing methods; it’s an early checkpoint that helps teams decide whether more detailed testing should proceed. Here’s how it sits with [other types of testing](https://momentic.ai/blog/types-of-software-testing-glossary), to give you an idea of the role it plays in the wider software development process. | Testing Type | Goal | Depth | When to Use | | --- | --- | --- | --- | | Smoke Testing | Verify critical functionality works | Shallow and broad | After new builds or deployments | | Sanity Testing | Confirm specific bug fixes or minor changes | Narrow and focused | After small updates | | Regression Testing | Ensure existing functionality still works after changes | Deep and broad | Before release or after major changes | | Functional Testing | Validate features against requirements | Detailed by feature | During QA cycles | | Integration Testing | Verify systems/modules work together | Medium to deep | During development and QA | | Performance Testing | Assess speed, stability, scalability | Specialist depth | Before release or optimisation | | User Acceptance Testing (UAT) | Confirm business readiness | Scenario-based | Final pre-release stage | ### Smoke vs sanity vs regression testing Smoke testing is the first gate. Sanity and regression testing come after it; see [types of regression testing](/blog/types-of-regression-testing) for the deeper layer. | | Smoke testing | Sanity testing | Regression testing | | --- | --- | --- | --- | | Question it answers | Is this build stable enough to test? | Does the area that changed work? | Did the change break anything that used to work? | | Scope | Wide and shallow: the critical journeys | Narrow and deeper: one fixed area | Wide and deep: the whole product | | When it runs | Every build, merge and deploy | After a fix or a small change | Before a release, nightly, or on risky changes | | Typical size | 5 to 30 tests | A handful of tests | Hundreds to thousands of tests | | Typical duration | Minutes | Minutes | Tens of minutes to hours | | If it fails | Reject the build | Send the fix back | Triage each failure before release | ## What goes in a smoke suite Pick the checks whose failure would stop a release on its own. For a typical web app, that list looks like this: 1. The app loads at its main URL and returns no server error. 2. A test user can sign up or log in. 3. The main navigation opens each top-level page. 4. Search or the primary list view returns results. 5. The core action works: create a record, add an item to the cart, send a message. 6. The money path reaches its last safe step, such as the payment form in a test environment. 7. A key API used by the front end returns a successful response. 8. A user can log out, and a protected page then redirects to login. Leave out edge cases, rare settings and visual detail. Those belong in the regression suite. For the wider pre-release list, see the [QA release checklist](/blog/qa-release-checklist). If a check has not caught a real problem in months and does not guard a revenue or sign-in path, move it out. ### How long should a smoke suite take? Under five minutes in CI for most teams, so it can run on every pull request without slowing reviews. Run the tests in parallel. If the suite grows past that, remove the tests that do not cover a business-critical journey before you add more machines. ### Adding a smoke gate to GitHub Actions Run the smoke tests on every pull request and fail the check when one fails: `name: Smoke on: pull_request jobs: smoke: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 22 - run: npm ci - run: npx momentic install-browsers - run: npx momentic run --labels smoke --upload-results env: MOMENTIC_API_KEY: ${{ secrets.MOMENTIC_API_KEY }}` Make the job a required status check in the branch protection rules, so a pull request cannot merge while the smoke suite is failing. The same job can run after each staging deploy by adding a `deployment_status` trigger. For the rest of the pipeline, see [CI/CD automation testing](/blog/ci-cd-automation-testing). ## Smoke Testing Best Practices The six smoke testing best practices are: test the business-critical journeys, keep the run to a few minutes, automate it in CI, maintain the tests, define clear pass and fail criteria, and run in an environment that mirrors production. ### Focus on Business-Critical Journeys Smoke testing should test fundamental, high-priority functions; choose your tests accordingly. You might want to focus on login, authentication, or purchase flows, for example. ### Keep It Fast Smoke testing is a quick checkpoint, not an hours-long full execution of your test suite. If it takes any more than a few minutes, slim it down by prioritizing cornerstone functions. ### Automate Where Possible Automating smoke tests in CI/CD pipelines ensures consistency, speed, and repeatability. And, it saves your engineering team time that they can dedicate to other tasks with more business value. ### Maintain Test Cases Regularly Your test suite should evolve with your app. Set time aside to review your test suite, remove outdated tests, and add new ones for critical functionality. Audits take up valuable engineer time and, being blunt, no one enjoys doing them. [AI can help](https://momentic.ai/blog/test-automation-maintenance) – see below for details. ### Use Clear Pass/Fail Criteria Define exactly what constitutes a failed smoke test. This prevents confusion and helps teams make release decisions quickly. ### Run in Realistic Environments Where possible, execute smoke tests in environments that mirror production to help catch configuration and deployment issues. ## Where AI helps with smoke testing Two parts of smoke testing take most of the upkeep: deciding which tests to run, and fixing tests that fail because the UI changed rather than because the app broke. - **Test selection.** On a pull request, AI test selection reads the diff and picks the tests that cover the changed code, so the smoke suite plus the affected tests run instead of the whole suite. In Momentic this is `npx momentic ai select --base main`; see the [AI test selection docs](/docs/ai/select). - **Locator changes.** When a button is renamed or moved, a test written as "Click Checkout" still finds it, because the step describes the element instead of a CSS selector. That keeps a redesign from failing the whole smoke suite. - **Failure triage.** A failed smoke run should say which step failed and show what the page looked like. Momentic uploads each run with the failed step, a screenshot and a trace. ## Momentic: Smart, AI-Native Smoke Testing Automation Momentic runs a smoke suite from plain-English test steps in CI, and re-resolves a step when its element moves, so a UI change does not break the suite. ### How to run a smoke suite with Momentic Add the smoke label to each smoke test, then run only the labeled tests on every pull request and every deployment: `# checkout.test.yaml fileType: momentic/test/v2 id: checkout-smoke labels: [smoke] url: https://shop.example.com steps: - click: Add to cart - click: Checkout - assert: The order summary is visible` `npx momentic run --labels smoke --reporter steps -y --upload-results` A failed test returns a nonzero exit code, so the CI check fails and the build stops. The uploaded run holds the failed step, its screenshot and its trace. > “With Momentic, we’ve caught bugs that would have eluded even our most diligent internal tests.” Using [Momentic](https://momentic.ai/), the team at GPT Zero saw an [89% decrease in defect escape rate](https://momentic.ai/customers/gptzero). They also saw an 80% acceleration in release cycles, thanks to time savings realized through natural language test creation and self-healing tests. Want to join them? [Get a demo today](https://momentic.ai/sales) ## Smoke testing questions, answered. What is smoke testing in software? Smoke testing is a fast, shallow test pass that checks that a new build launches and that its most critical functions work. It runs before deeper testing, so the team does not spend hours testing a broken build. When should you run smoke tests? Run smoke tests after every new build, code merge, deployment and infrastructure change. In a CI/CD pipeline, run them on every pull request and after each deployment to staging or production. What is the difference between smoke testing and sanity testing? Smoke testing checks that the critical functions of a whole build work. Sanity testing checks one changed area in more depth after a fix or a small change. Smoke testing comes first; sanity testing is narrower. How long should a smoke test suite take? Under five minutes in CI for most teams. If it takes longer, move tests that do not guard a critical journey into the regression suite. Can smoke tests be automated? Yes. Most teams run them in CI on every pull request and every deploy, and a failed test fails the check. How many tests should a smoke suite have? Usually 5 to 30. Enough to cover each journey that would stop a release if it broke, and no more. Still have additional questions? ## Keep reading. [Resources QA Release Checklist: 12 Steps Before Every Release A 12-step QA release checklist with an owner and a piece of evidence for each step, and a clear answer to who owns the checklist: engineering or QA. Wei-Wei Wu 13 min read](/blog/qa-release-checklist)[Resources CI/CD Automation Testing: Essential Strategies for Faster Deployments Learn CI/CD automation testing strategies to speed deployments, reduce flaky tests, and improve software quality with automated testing. Wei-Wei Wu 12 min read](/blog/ci-cd-automation-testing)[Resources 7 Types of Regression Testing and When to Use Them What you need to know about the seven main types of regression testing and when to use them - plus a few tips on optimizing your regression testing processes Wei-Wei Wu 8 min read](/blog/types-of-regression-testing) ## Try Mo on your app. Mo is an AI QA engineer. It tests your running app and files each bug with repro steps. Free to start, no credit card. [Try for free](https://app.momentic.ai/signup) [Contact sales](/sales)