Smoke Test i mobil utveckling — vad är det, uppgifter och hur det tillämpas

Vad är Smoke Test?

Smoke Test (röktestning) är en samling snabba tester som kontrollerar applikationens grundläggande funktioner utan djupgående analys. Termen kommer från hårdvaruteknik: om en enhet efter montering börjar ryka skickas den inte till fullständig testning. I mobil utveckling fyller Smoke Test samma funktion — den sorterar bort icke-fungerande byggen i förväg. Enligt Microsoft DevOps (2024) minskar implementeringen av Smoke Test antalet defekter som når QA-teamet med 40%.

Smoke Test utförs på varje nytt bygge — både på Android och iOS. Idealt sett bör Smoke Test inte ta längre än 15 minuter och starta automatiskt efter ett lyckat bygge. Godkännandekriterium — 100% av testerna i Smoke Test-uppsättningen måste slutföras framgångsrikt. Om minst ett test misslyckas markeras bygget som instabilt och skickas inte till vidare testning. Enligt Google Testing Blog (2024) minskar detta tillvägagångssätt tiden för att leverera funktioner till användarna med 25%.

Smoke Test kan vara både manuell (checklista med 5–10 punkter) och automatiserad. I moderna mobilprojekt föredras automatiserad Smoke Test inbyggd i CI/CD. Manuell Smoke Test är bara motiverad i de tidiga stadierna av ett projekt, när automatisering inte är ekonomiskt försvarbart. Enligt Bitrise (2025) automatiserar 73% av mobilutvecklingsteamen Smoke Test.

Hur skiljer sig Smoke Test från regressionstestning

Smoke Test och regressionstestning förväxlas ofta, men det är olika praktiker med olika syften. Regressionstestning kontrollerar att ändringar i koden inte har brutit befintlig funktionalitet. Den täcker alla moduler och scenarier i applikationen, inklusive sällsynta och gränsfall. Smoke Test kontrollerar endast den kritiska vägen — de grundläggande scenarierna utan vilka applikationen är oanvändbar. Täckningsdjup — den största skillnaden: Smoke Test täcker 5–10% av funktionaliteten, regression 80–100%.

Den andra skillnaden — utförandetid. Regressionsuppsättningen för en mobilapplikation kan ta 2 till 12 timmar beroende på projektets storlek och antalet plattformar. Smoke Test tar 5–15 minuter. Enligt Sauce Labs (2025) är den genomsnittliga utförandetiden för regressionsuppsättningen för en iOS-app 4,5 timmar, för Android 3,2 timmar. Smoke Test på båda plattformarna ryms inom 10–15 minuter.

Den tredje skillnaden — plats i pipelinen. Smoke Test utförs omedelbart efter bygget, före regressionstestning. Om Smoke Test inte godkänns startas inte regressionen — detta sparar CI/CD-resurser. Pipeline efficiency — Smoke Test sållar bort upp till 30% av byggen som inte skulle klara regressionen, och de sparade resurserna räcker för parallell körning av andra uppgifter.

Vad ingår i Smoke Test av en mobilapplikation

Start av applikationen

Start av applikationen — det första och viktigaste testet. Applikationen måste starta utan krasch på alla målenheter. Smoke Test kontrollerar kallstart: installation → öppning → visning av första skärmen. Om applikationen kraschar vid start är vidare testning meningslös. XCUITest och Espresso gör det möjligt att automatisera startkontrollen på 2– rader kod. Launch argument `-AppleLanguages (sv)` hjälper till att kontrollera lokaliseringen vid start.

Auktorisering

Auktorisering — det andra kritiska scenariot. Smoke Test måste kontrollera att inloggningsformuläret visas, inmatningsfält reagerar på beröring, inloggningsknappen skickar en begäran och applikationen går till huvudskärmen efter lyckad auktorisering. Ett auktoriseringsfel blockerar åtkomst till alla andra funktioner, därför ingår dess kontroll i minimiuppsättningen. Token refresh — extra kontroll för applikationer med OAuth 2.0.

Laddning av innehåll och navigering

Laddning av huvudinnehåll — det tredje Smoke Testet. Huvudskärmen eller flödet för applikationen måste laddas och visa data. Om API:t inte svarar eller tolkningen av svaret är trasig ser användaren en tom skärm. Nätverkskontroll i Smoke Test omfattar en grundläggande GET-förfrågan till huvudslutpunkten och kontroll av att svaret har förväntad struktur. Navigering — det fjärde scenariot. Smoke Test går igenom applikationens huvudskärmar: huvud → sök → profil → inställningar. Flikfältet och sidomenyn — typiska källor till navigeringsproblem som Smoke Test upptäcker tidigt.

Automatisering av Smoke Test i CI/CD

Fastlane — standardverktyget för att automatisera mobil CI/CD. Smoke Test på Fastlane startas via `scan` (för XCUITest) eller `gradle` (för Espresso). Fastlane gör det möjligt att konfigurera Smoke Test på flera enheter parallellt, vilket minskar den totala tiden. Konfiguration i Fastfile innehåller ett mål för Smoke Test-uppsättningen och ett godkännandetröskel: 100% lyckade tester.

GitHub Actions (2024) publicerade en mobil CI/CD-mall med inbyggd Smoke Test. Mallen omfattar tre steg: bygge → Smoke Test → regression. Om Smoke Test misslyckas avslutas pipelinen automatiskt och en notifiering skickas till Slack eller Telegram. Matrix strategy gör det möjligt att köra Smoke Test på tre iOS-versioner och fem Android-modeller samtidigt.

Ansvarsfördelning i CI/CD: Smoke Test ansvarar för snabb återkoppling, regression för full täckning. Smoke Test ska inte duplicera regression och vice versa. Granularitet Smoke Test — en kontroll per kritiskt scenario. Om Smoke Test tar längre än 15 minuter måste det optimeras: ta bort överflödiga kontroller eller parallellisera utförandet.

# Fastfile-konfiguration för 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

Verktyg för Smoke Test

XCUITest — Apples ramverk för UI-testning av iOS-applikationer. XCUITest används för automatisering av Smoke Test: starta applikationen, kontrollera gränssnittselement, simulera användaråtgärder. I kombination med Xcode Server eller GitHub Actions körs XCUITest vid varje commit. XCTest — grundramverket för enhetstester som kompletterar XCUITest för logikkontroll.

Espresso — Googles ramverk för UI-testning av Android. Espresso synkroniserar med UI-tråden och garanterar att alla animationer är slutförda innan kontrollen pörjar. Espresso stöder kontroll via `onView(withId(...)).check(matches(...))`. Android Test Orchestrator kör varje Smoke Test i en separat process, vilket förhindrar att tidigare tester påverkar efterföljande.

Detox — ett ramverk för React Native som stöder Smoke Test och grey-box-testning. Detox synkroniserar med React Native bridge och väntar automatiskt på att asynkrona operationer slutförs. Grey-box-testning gör det möjligt för Detox att kontrollera applikationens tillstånd utan direkt åtkomst till källkoden.

Exempel på Smoke Test i Swift och Kotlin

XCUITest för iOS innehåller två kontroller: starta applikationen och visa huvudskärmen. Testet startar applikationen via `XCUIApplication().launch()` och kontrollerar om nyckelelementet (t.ex. `navigationBar`) finns. Om applikationen kraschar vid start registrerar XCTest-ramverket felet och testet avslutas med FAIL. Smoke Test kontrollerar inte innehåll — bara att skärmen öppnades.

Espresso för Android använder `ActivityScenario` för att starta Activity och `onView` för att kontrollera element. Den kritiska skillnaden mellan plattformar: iOS-simulatorn kan visa annorlunda beteende än en verklig enhet, därför rekommenderas Smoke Test på Android att köras på Firebase Test Lab eller emulator. Firebase Test Lab stöder parallell körning av Smoke Test på 10 enheter.

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

Exemplet ovan visar Smoke Test för inloggningsskärmen på iOS. Det första testet kontrollerar om inloggningsknappen finns på skärmen. Det andra testet går igenom hela auktoriseringsvägen och kontrollerar att ett välkomstmeddelande visas efter lyckad inloggning. Timeout på 5 sekunder för waitForExistence — standardvärde för Smoke Test: om UI-elementet inte visas inom denna tid fungerar applikationen inte korrekt.