Smoke Test in mobiele ontwikkeling — wat is het, taken en hoe het wordt toegepast

Wat is Smoke Test?

Smoke Test (rooktest) is een set snelle tests die de basisfuncties van de app controleren zonder diepgaande analyse. De term komt uit de hardware-engineering: als een apparaat na montage begint te roken, wordt het niet naar volledige testen gestuurd. In mobiele ontwikkeling vervult Smoke Test dezelfde functie — het filtert van tevoren niet-werkende builds eruit. Volgens Microsoft DevOps (2024) vermindert de implementatie van Smoke Test het aantal defecten dat bij het QA-team terechtkomt met 40%.

Smoke Test wordt uitgevoerd op elke nieuwe build — zowel op Android als op iOS. Idealiter duurt Smoke Test niet langer dan 15 minuten en wordt het automatisch gestart na een succesvolle build. Slagingscriterium — 100% van de tests in de Smoke Test-set moet succesvol worden afgerond. Als minstens één test faalt, wordt de build als instabiel gemarkeerd en niet naar verdere testing gestuurd. Volgens Google Testing Blog (2024) verkort deze aanpak de tijd om functies bij gebruikers te krijgen met 25%.

Smoke Test kan zowel handmatig (checklist van 5–10 punten) als geautomatiseerd zijn. In moderne mobiele projecten heeft geautomatiseerde Smoke Test geïntegreerd in CI/CD de voorkeur. Handmatige Smoke Test is alleen gerechtvaardigd in de vroege stadia van een project, wanneer automatisering economisch niet haalbaar is. Volgens Bitrise (2025) automatiseert 73% van de mobiele ontwikkelingsteams Smoke Test.

Hoe verschilt Smoke Test van regressietesten

Smoke Test en regressietesten worden vaak verward, maar het zijn verschillende praktijken met verschillende doelen. Regressietesten controleren of wijzigingen in de code bestaande functionaliteit niet hebben verbroken. Het bestrijkt alle modules en scenario’s van de app, inclusief zeldzame en randgevallen. Smoke Test controleert alleen het kritieke pad — de basisscenario’s zonder welke de app nutteloos is. Diepte van dekking — het belangrijkste verschil: Smoke Test bestrijkt 5–10% van de functionaliteit, regressie 80–100%.

Het tweede verschil — uitvoeringstijd. De regressieset voor een mobiele app kan 2 tot 12 uur duren, afhankelijk van de projectgrootte en het aantal platforms. Smoke Test duurt 5–15 minuten. Volgens Sauce Labs (2025) is de gemiddelde uitvoeringstijd van de regressieset voor een iOS-app 4,5 uur, voor Android 3,2 uur. Smoke Test op beide platforms past binnen 10–15 minuten.

Het derde verschil — plaats in de pijplijn. Smoke Test wordt onmiddellijk na de build, vóór regressietesten uitgevoerd. Als Smoke Test niet wordt doorstaan, wordt regressie niet gestart — dit bespaart CI/CD-bronnen. Pipeline efficiency — Smoke Test filtert tot 30% van de builds eruit die regressie niet zouden doorstaan, en de bespaarde bronnen zijn voldoende voor parallelle uitvoering van andere taken.

Wat valt er onder Smoke Test van een mobiele app

Starten van de app

Starten van de app — de eerste en belangrijkste test. De app moet zonder crash starten op alle doelapparaten. Smoke Test controleert een koude start: installatie → openen → weergave van het eerste scherm. Als de app crasht bij het starten, is verdere testen zinloos. XCUITest en Espresso maken het mogelijk om de startcontrole in 2–3 regels code te automatiseren. Launch argument `-AppleLanguages (nl)` helpt om de lokalisatie bij het starten te controleren.

Autorisatie

Autorisatie — het tweede kritieke scenario. Smoke Test moet controleren of het loginformulier wordt weergegeven, invoervelden reageren op aanraking, de login-knop een verzoek verzendt en de app naar het hoofdscherm gaat na succesvolle autorisatie. Een autorisatiefout blokkeert de toegang tot alle andere functies, daarom maakt de controle ervan deel uit van de minimale set. Token refresh — extra controle voor apps met OAuth 2.0.

Laden van content en navigatie

Laden van de hoofdcontent — de derde Smoke Test. Het hoofdscherm of de feed van de app moet laden en gegevens weergeven. Als de API niet reageert of het parsen van het antwoord is verbroken, ziet de gebruiker een leeg scherm. Netwerkcontrole in Smoke Test omvat een basis GET-verzoek naar het hoofdeindpunt en controle of het antwoord de verwachte structuur heeft. Navigatie — het vierde scenario. Smoke Test doorloopt de hoofdschermen van de app: hoofd → zoeken → profiel → instellingen. Tabbladbalk en zijmenu — typische bronnen van navigatieproblemen die Smoke Test in een vroeg stadium detecteert.

Automatisering van Smoke Test in CI/CD

Fastlane — de standaard tool voor het automatiseren van mobiele CI/CD. Smoke Test op Fastlane wordt gestart via `scan` (voor XCUITest) of `gradle` (voor Espresso). Fastlane maakt het mogelijk om Smoke Test op meerdere apparaten parallel in te stellen, wat de totale tijd verkort. Configuratie in Fastfile omvat een target voor de Smoke Test-set en een slagingsdrempel: 100% succesvolle tests.

GitHub Actions (2024) publiceerde een mobiele CI/CD-sjabloon met ingebouwde Smoke Test. Het sjabloon omvat drie fasen: build → Smoke Test → regressie. Als Smoke Test faalt, beëindigt het sjabloon automatisch de pijplijn en stuurt een melding naar Slack of Telegram. Matrix strategy maakt het mogelijk om Smoke Test op drie iOS-versies en vijf Android-modellen tegelijkertijd uit te voeren.

Verdeling van verantwoordelijkheden in CI/CD: Smoke Test is verantwoordelijk voor snelle feedback, regressie voor volledige dekking. Smoke Test mag regressie niet dupliceren en vice versa. Granulariteit van Smoke Test — één controle per kritiek scenario. Als Smoke Test langer dan 15 minuten duurt, moet het worden geoptimaliseerd: overbodige controles verwijderen of uitvoering paralleliseren.

# Fastfile-configuratie voor de 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

Tools voor Smoke Test

XCUITest — het Apple-framework voor UI-testen van iOS-apps. XCUITest wordt gebruikt voor automatisering van Smoke Test: starten van de app, controleren van interface-elementen, simuleren van gebruikersacties. In combinatie met Xcode Server of GitHub Actions wordt XCUITest bij elke commit gestart. XCTest — het basisframework voor unittesten dat XCUITest aanvult voor logische controle.

Espresso — het Google-framework voor UI-testen van Android. Espresso synchroniseert met de UI-thread en garandeert dat alle animaties zijn voltooid voordat de controle begint. Espresso ondersteunt controle via `onView(withId(...)).check(matches(...))`. Android Test Orchestrator start elke Smoke Test in een apart proces, wat voorkomt dat eerdere tests latere tests beïnvloeden.

Detox — een framework voor React Native dat Smoke Test en grey-box testen ondersteunt. Detox synchroniseert met de React Native bridge en wacht automatisch op voltooiing van asynchrone bewerkingen. Grey-box testen stelt Detox in staat om de app-status te controleren zonder directe toegang tot de broncode.

Voorbeeld van Smoke Test in Swift en Kotlin

XCUITest voor iOS bevat twee controles: starten van de app en weergave van het hoofdscherm. De test start de app via `XCUIApplication().launch()` en controleert of het belangrijke element (bijv. `navigationBar`) bestaat. Als de app crasht bij het starten, registreert het XCTest-framework de fout en eindigt de test met FAIL. Smoke Test controleert niet de inhoud — alleen dat het scherm is geopend.

Espresso voor Android gebruikt `ActivityScenario` om Activity te starten en `onView` om elementen te controleren. Het kritieke verschil tussen platforms: de iOS-simulator kan ander gedrag vertonen dan een echt apparaat, daarom wordt aanbevolen Smoke Test op Android uit te voeren op Firebase Test Lab of emulator. Firebase Test Lab ondersteunt parallelle uitvoering van Smoke Test op 10 apparaten.

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

Het bovenstaande voorbeeld toont Smoke Test voor het inlogscherm op iOS. De eerste test controleert of de inlogknop op het scherm bestaat. De tweede test doorloopt het volledige autorisatiepad en controleert of na succesvol inloggen een welkomstbericht wordt weergegeven. Timeout van 5 seconden voor waitForExistence — standaardwaarde voor Smoke Test: als het UI-element niet binnen deze tijd wordt weergegeven, werkt de app niet correct.