Smoke Test sa mobile development — ano ito, mga gawain at kung paano ito ginagamit

Ano ang Smoke Test?

Smoke Test (pagsusuri ng usok) ay isang hanay ng mabilis na mga pagsusuri na sumusuri sa mga pangunahing function ng application nang walang malalim na pagsusuri. Ang termino ay nagmula sa hardware engineering: kung ang isang device pagkatapos ng assembly ay nagsimulang manigarilyo, hindi ito ipinapadala sa buong pagsubok. Sa mobile development, ang Smoke Test ay gumaganap ng parehong function — sinasala ang mga build na hindi gagana. Ayon sa Microsoft DevOps (2024), ang pagpapatupad ng Smoke Test ay nagbabawas ng bilang ng mga depekto na nakakarating sa QA team ng 40%.

Ang Smoke Test ay isinasagawa sa bawat bagong build — pareho sa Android at iOS. Sa ideal na kaso, ang Smoke Test ay hindi dapat tumagal ng higit sa 15 minuto at awtomatikong magsisimula pagkatapos ng matagumpay na build. Kriterya ng pagpasa — 100% ng mga pagsusuri mula sa Smoke Test set ay dapat magtagumpay. Kung hindi bababa sa isang test ang bumagsak, ang build ay minarkahan bilang hindi matatag at hindi ipinapadala sa karagdagang pagsubok. Ayon sa Google Testing Blog (2024), ang pamamaraang ito ay nagbabawas ng oras ng paghahatid ng mga feature sa mga user ng 25%.

Ang Smoke Test ay maaaring manual (checklist ng 5–10 puntos) o automated. Sa modernong mobile projects, ang automated Smoke Test na naka-embed sa CI/CD ay mas pinipili. Manual Smoke Test ay nabibigyang-katwiran lamang sa mga unang yugto ng proyekto, kapag ang automation ay hindi ekonomiko. Ayon sa Bitrise (2025), 73% ng mga mobile development team ay nag-automate ng Smoke Test.

Paano naiiba ang Smoke Test sa regression testing

Smoke Test at regression testing ay madalas na napagkakamalan, ngunit ito ay magkaibang mga kasanayan na may magkaibang layunin. Ang regression testing ay sumusuri kung ang mga pagbabago sa code ay hindi sumira sa umiiral na functionality. Sinasaklaw nito ang lahat ng module at scenario ng application, kabilang ang mga bihirang at boundary cases. Ang Smoke Test ay sumusuri lamang ng kritikal na landas — ang mga pangunahing scenario kung wala ang application ay walang silbi. Lalim ng saklaw — pangunahing pagkakaiba: Smoke Test ay sumasaklaw ng 5–10% ng functionality, regression — 80–100%.

Pangalawang pagkakaiba — oras ng pagpapatupad. Ang regression set para sa mobile application ay maaaring tumagal mula 2 hanggang 12 oras depende sa laki ng proyekto at bilang ng mga platform. Ang Smoke Test ay tumatagal ng 5–15 minuto. Ayon sa Sauce Labs (2025), ang average na oras ng pagpapatupad ng regression set para sa iOS application ay 4.5 oras, para sa Android — 3.2 oras. Ang Smoke Test sa parehong platform ay umaabot sa 10–15 minuto.

Pangatlong pagkakaiba — posisyon sa pipeline. Ang Smoke Test ay isinasagawa kaagad pagkatapos ng build, bago ang regression testing. Kung ang Smoke Test ay hindi pumasa, ang regression ay hindi sinisimulan — ito ay nakakatipid ng mga mapagkukunan ng CI/CD. Pipeline efficiency — Smoke Test ay sumasala ng hanggang 30% ng mga build na hindi papasa sa regression, at ang naipon na mga mapagkukunan ay sapat para sa parallel na pagpapatakbo ng iba pang mga gawain.

Ano ang kasama sa Smoke Test ng mobile application

Pag-lunch ng application

Pag-lunch ng application — una at pinakamahalagang pagsusuri. Ang application ay dapat mag-lunch nang walang crash sa lahat ng target na device. Sinusuri ng Smoke Test ang cold start: pag-install → pagbukas → pagpapakita ng unang screen. Kung ang application ay nag-crash sa pag-lunch, ang karagdagang pagsubok ay walang kabuluhan. Ang XCUITest at Espresso ay nagbibigay-daan sa automation ng pagsusuri ng pag-lunch sa 2–3 linya ng code. Launch argument `-AppleLanguages (fil)` ay tumutulong upang suriin ang localization sa start.

Authorization

Authorization — pangalawang kritikal na scenario. Dapat suriin ng Smoke Test na ang login form ay ipinapakita, ang mga input field ay tumutugon sa pagpindot, ang login button ay nagpapadala ng request, at ang application ay pumupunta sa home screen pagkatapos ng matagumpay na authorization. Ang error sa authorization ay humaharang sa access sa lahat ng iba pang function, kaya ang pagsusuri nito ay kasama sa minimal na set. Token refresh — karagdagang pagsusuri para sa mga application na may OAuth 2.0.

Pag-load ng content at navigation

Pag-load ng pangunahing content — ikatlong pagsusuri ng Smoke Test. Ang home screen o feed ng application ay dapat mag-load at magpakita ng data. Kung ang API ay hindi tumugon o ang pag-parse ng response ay sira, makikita ng user ang isang blangkong screen. Ang pagsusuri ng network sa Smoke Test ay kasama ang basic GET request sa pangunahing endpoint at pagsusuri na ang response ay may inaasahang structure. Navigation — ikaapat na scenario. Ang Smoke Test ay dumadaan sa mga pangunahing screen ng application: home → search → profile → settings. Ang tab bar at side menu — tipikal na mga pinagmumulan ng problema sa navigation na natutuklasan ng Smoke Test sa maagang yugto.

Automation ng Smoke Test sa CI/CD

Fastlane — karaniwang tool para sa pag-automate ng mobile CI/CD. Ang Smoke Test sa Fastlane ay sinisimulan sa pamamagitan ng `scan` (para sa XCUITest) o `gradle` (para sa Espresso). Pinapayagan ng Fastlane ang configuration ng Smoke Test sa maraming device nang magkakasabay, na nagbabawas ng kabuuang oras. Configuration sa Fastfile ay may kasamang target para sa Smoke Test set at threshold ng pagpasa: 100% matagumpay na mga test.

GitHub Actions (2024) ay nag-publish ng template ng mobile CI/CD na may built-in na Smoke Test. Ang template ay may tatlong yugto: build → Smoke Test → regression. Kung ang Smoke Test ay bumagsak, ang template ay awtomatikong magtatapos sa pipeline at magpapadala ng notification sa Slack o Telegram. Matrix strategy ay nagpapahintulot sa pagpapatakbo ng Smoke Test sa tatlong bersyon ng iOS at limang modelo ng Android nang sabay-sabay.

Paghahati ng responsibilidad sa CI/CD: Smoke Test ay responsable para sa mabilis na feedback, regression — para sa buong saklaw. Ang Smoke Test ay hindi dapat duplicate ang regression at vice versa. Granularity ng Smoke Test — isang pagsusuri bawat kritikal na scenario. Kung ang Smoke Test ay tumatagal ng higit sa 15 minuto, kailangan itong i-optimize: alisin ang mga labis na pagsusuri o i-parallelize ang execution.

# Fastfile configuration para sa 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

Mga Tool para sa Smoke Test

XCUITest — framework ng Apple para sa UI testing ng iOS applications. Ang XCUITest ay ginagamit para sa automation ng Smoke Test: pag-lunch ng application, pagsusuri ng mga elemento ng interface, pag-simulate ng mga aksyon ng user. Sa kombinasyon sa Xcode Server o GitHub Actions, ang XCUITest ay tumatakbo sa bawat commit. XCTest — pangunahing framework para sa unit test na nagpupuno sa XCUITest para sa pagsusuri ng logic.

Espresso — framework ng Google para sa UI testing ng Android. Ang Espresso ay nag-synchronize sa UI thread at ginagarantiyahan na ang lahat ng animation ay natapos bago magsimula ang pagsusuri. Ang Espresso ay sumusuporta sa pagsusuri sa pamamagitan ng `onView(withId(...)).check(matches(...))`. Android Test Orchestrator ay nagpapatakbo ng bawat Smoke Test sa isang hiwalay na proseso, na pumipigil sa impluwensya ng mga nakaraang test sa mga susunod na test.

Detox — framework para sa React Native na sumusuporta sa Smoke Test at grey-box testing. Ang Detox ay nag-synchronize sa React Native bridge at awtomatikong naghihintay para sa pagkumpleto ng mga asynchronous na operasyon. Grey-box testing ay nagpapahintulot sa Detox na suriin ang estado ng application nang walang direktang access sa source code.

Halimbawa ng Smoke Test sa Swift at Kotlin

XCUITest para sa iOS ay naglalaman ng dalawang pagsusuri: pag-lunch ng application at pagpapakita ng home screen. Ang test ay nag-lunch ng application sa pamamagitan ng `XCUIApplication().launch()` at sinusuri kung ang key element (hal. `navigationBar`) ay umiiral. Kung ang application ay nag-crash sa pag-lunch, ang XCTest framework ay nagtatala ng error at ang test ay nagtatapos sa FAIL. Smoke Test ay hindi sumusuri ng content — lamang na ang screen ay bumukas.

Espresso para sa Android ay gumagamit ng `ActivityScenario` para sa pag-lunch ng Activity at `onView` para sa pagsusuri ng mga elemento. Ang kritikal na pagkakaiba sa pagitan ng mga platform: ang iOS simulator ay maaaring magpakita ng ibang pag-uugali mula sa totoong device, kaya ang Smoke Test sa Android ay inirerekomenda na patakbuhin sa Firebase Test Lab o emulator. Firebase Test Lab ay sumusuporta sa parallel na pagpapatakbo ng Smoke Test sa 10 device.

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))
    }
}

Ang halimbawa sa itaas ay nagpapakita ng Smoke Test para sa login screen sa iOS. Ang unang test ay sumusuri kung ang login button ay umiiral sa screen. Ang pangalawang test ay dumadaan sa buong authorization path at sinusuri na pagkatapos ng matagumpay na pag-login, ang welcome message ay ipinapakita. Timeout ng 5 segundo para sa waitForExistence — karaniwang halaga para sa Smoke Test: kung ang UI element ay hindi ipinapakita sa oras na ito, ang application ay hindi gumagana nang tama.