Smoke Test in Mobile Development — What It Is, Tasks, and How It’s Applied

What Is a Smoke Test?

Smoke Test is a set of quick tests that verify the core functions of an application without deep analysis. The term comes from hardware engineering: if a device starts smoking after assembly, it is not sent for full testing. In mobile development, the Smoke Test serves the same function — it filters out obviously non-functional builds. According to Microsoft DevOps (2024), implementing a Smoke Test reduces the number of defects reaching the QA team by 40%.

A Smoke Test is run on every new build — both Android and iOS. Ideally, a Smoke Test should take no more than 15 minutes and launch automatically after a successful build. Pass criteria — 100% of the tests in the Smoke Test suite must pass. If even one test fails, the build is marked as unstable and is not sent for further testing. According to Google Testing Blog (2024), this approach reduces feature delivery time to users by 25%.

A Smoke Test can be either manual (a checklist of 5–10 items) or automated. In modern mobile projects, preference is given to an automated Smoke Test built into CI/CD. Manual Smoke Test is justified only at early project stages when automation is not economically viable. According to Bitrise (2025), 73% of mobile development teams automate their Smoke Tests.

How Is a Smoke Test Different from Regression Testing?

Smoke Test and regression testing are often confused, but they are different practices with different goals. Regression testing verifies that code changes have not broken existing functionality. It covers all modules and scenarios of the application, including rare and edge cases. A Smoke Test checks only the critical path — the core scenarios without which the application is useless. Coverage depth is the main difference: a Smoke Test covers 5–10% of functionality, while regression covers 80–100%.

The second difference is execution time. A regression suite for a mobile application can take from 2 to 12 hours, depending on project size and the number of platforms. A Smoke Test takes 5–15 minutes. According to Sauce Labs (2025), the average execution time of a regression suite for an iOS application is 4.5 hours, and for Android — 3.2 hours. A Smoke Test on both platforms fits within 10–15 minutes.

The third difference is pipeline placement. A Smoke Test runs immediately after the build, before regression testing. If the Smoke Test fails, regression is not launched — this saves CI/CD resources. Pipeline efficiency — a Smoke Test filters out up to 30% of builds that would have failed regression, and the saved resources are enough to run other tasks in parallel.

What’s Included in a Mobile App Smoke Test

App Launch

App launch — the first and most important test. The application must launch without crashing on all target devices. A Smoke Test checks cold start: install → open → display the first screen. If the app crashes on launch, further testing is pointless. XCUITest and Espresso allow automating the launch check in 2–3 lines of code. Launch argument `-AppleLanguages (ru)` helps verify localization at startup.

Authentication

Authentication — the second critical scenario. A Smoke Test must verify that the login form is displayed, input fields respond to touch, the login button sends a request, and the application navigates to the main screen after successful authentication. An authentication error blocks access to all other features, so it is included in the minimal set. Token refresh — an additional check for applications with OAuth 2.0.

Content Loading and Navigation

Main content loading — the third Smoke Test. The main screen or feed of the application must load and display data. If the API does not respond or response parsing is broken, the user sees an empty screen. Network checking in a Smoke Test includes a basic GET request to the main endpoint and verifying that the response has the expected structure. Navigation — the fourth scenario. A Smoke Test navigates through the main screens of the application: home → search → profile → settings. Tab bar and side menu are typical sources of navigation issues that a Smoke Test catches early.

Smoke Test Automation in CI/CD

Fastlane — the standard tool for automating mobile CI/CD. A Smoke Test in Fastlane is run via `scan` (for XCUITest) or `gradle` (for Espresso). Fastlane allows configuring Smoke Test execution on multiple devices in parallel, reducing overall time. Configuration in Fastfile includes targeting the Smoke Test suite and a pass threshold: 100% successful tests.

GitHub Actions (2024) published a mobile CI/CD template with a built-in Smoke Test. The template includes three stages: build → Smoke Test → regression. If the Smoke Test fails, the template automatically terminates the pipeline and sends a notification to Slack or Telegram. Matrix strategy enables running the Smoke Test on three iOS versions and five Android models simultaneously.

Responsibility split in CI/CD: the Smoke Test provides fast feedback, while regression provides full coverage. The Smoke Test should not duplicate regression, and vice versa. Granularity of a Smoke Test — one check per critical scenario. If a Smoke Test takes more than 15 minutes, it needs to be optimized: remove redundant checks or parallelize execution.

# Fastfile configuration for Smoke Test
platform :ios do
    lane :smoke do
        scan(
            scheme: 'App',
            devices: ['iPhone 15', 'iPhone SE'],
            testplan: 'SmokeTest',
            output_directory: 'reports/smoke',
            fail_build: true
        )
    end

    lane :regression do
        scan(
            scheme: 'App',
            devices: ['iPhone 15', 'iPhone 14', 'iPhone SE'],
            testplan: 'FullRegression'
        )
    end
end

Smoke Test Tools

XCUITest — Apple’s framework for UI testing iOS applications. XCUITest is used to automate Smoke Tests: launching the app, checking UI elements, simulating user actions. Combined with Xcode Server or GitHub Actions, XCUITest runs on every commit. XCTest — the base framework for unit tests that complements XCUITest for logic verification.

Espresso — Google’s framework for UI testing Android. Espresso synchronizes with the UI thread and ensures all animations are completed before verification starts. Espresso supports checking via `onView(withId(...)).check(matches(...))`. Android Test Orchestrator runs each Smoke Test in a separate process, preventing tests from influencing each other.

Detox — a framework for React Native that supports Smoke Test and grey-box testing. Detox synchronizes with the React Native bridge and automatically waits for asynchronous operations to finish. Grey-box testing allows Detox to verify application state without direct access to the source code.

Smoke Test Example in Swift and Kotlin

XCUITest for iOS contains two checks: launching the application and displaying the main screen. The test launches the app via `XCUIApplication().launch()` and checks that a key element (e.g., `navigationBar`) exists. If the app crashes on launch, the XCTest framework records the error and the test ends with FAIL. Smoke Test does not check content — only that the screen opened.

Espresso for Android uses `ActivityScenario` to launch an Activity and `onView` to check elements. A critical difference between platforms: the iOS simulator may behave differently from a real device, so Android Smoke Tests are recommended to run on Firebase Test Lab or an emulator. Firebase Test Lab supports parallel execution of Smoke Tests on 10 devices.

import XCTest

class LoginSmokeTest: XCTestCase {
    let app = XCUIApplication()

    override func setUp() {
        continueAfterFailure = false
        app.launch()
    }

    func testLoginButtonExists() {
        XCTAssertTrue(app.buttons["Log In"].exists)
    }

    func testLoginFlow() {
        app.textFields["email"].tap()
        app.textFields["email"].typeText("test@test.com")
        app.secureTextFields["password"].tap()
        app.secureTextFields["password"].typeText("password123")
        app.buttons["Log In"].tap()
        XCTAssertTrue(app.staticTexts["Welcome"].waitForExistence(timeout: 5))
    }
}

The example above shows a Smoke Test for the login screen on iOS. The first test checks that the login button exists on the screen. The second test runs through the full authentication path and checks that a welcome message is displayed after successful login. Timeout of 5 seconds for `waitForExistence` is the standard value for a Smoke Test: if the UI element does not appear within that time, the application is not working correctly.