Smoke Test w rozwoju aplikacji mobilnych — co to jest, zadania i jak jest stosowany

Co to jest Smoke Test?

Smoke Test (testowanie dymne) to zestaw szybkich testów, które sprawdzają podstawowe funkcje aplikacji bez głębokiej analizy. Termin pochodzi z inżynierii sprzętowej: jeśli urządzenie po złożeniu zaczyna dymić, nie wysyła się go do pełnego testowania. W tworzeniu aplikacji mobilnych Smoke Test pełni tę samą funkcję — odsiewa z góry nienadające się do użytku kompilacje. Według Microsoft DevOps (2024), wdrożenie Smoke Test zmniejsza liczbę defektów docierających do zespołu QA o 40%.

Smoke Test jest wykonywany na każdej nowej kompilacji — zarówno na Androidzie, jak i na iOS. W idealnym przypadku Smoke Test powinien zajmować nie więcej niż 15 minut i uruchamiać się automatycznie po udanej kompilacji. Kryterium zaliczenia — 100% testów z zestawu Smoke Test musi zakończyć się sukcesem. Jeśli choć jeden test upada, kompilacja jest oznaczana jako niestabilna i nie jest wysyłana do dalszego testowania. Według Google Testing Blog (2024), takie podejście skraca czas dostarczania funkcji do użytkowników o 25%.

Smoke Test może być zarówno ręczny (lista kontrolna z 5–10 punktami), jak i zautomatyzowany. W nowoczesnych projektach mobilnych preferowany jest zautomatyzowany Smoke Test wbudowany w CI/CD. Ręczny Smoke Test jest uzasadniony tylko na wczesnych etapach projektu, gdy automatyzacja jest ekonomicznie nieopłacalna. Według Bitrise (2025), 73% zespołów tworzących aplikacje mobilne automatyzuje Smoke Test.

Czym Smoke Test różni się od testowania regresyjnego

Smoke Test i testowanie regresyjne są często mylone, ale to różne praktyki o różnych celach. Testowanie regresyjne sprawdza, czy zmiany w kodzie nie złamały istniejącej funkcjonalności. Obejmuje wszystkie moduły i scenariusze aplikacji, w tym rzadkie i graniczne przypadki. Smoke Test sprawdza tylko krytyczną ścieżkę — podstawowe scenariusze, bez których aplikacja jest bezużyteczna. Głębokość pokrycia — główna różnica: Smoke Test pokrywa 5–10% funkcjonalności, regresja — 80–100%.

Druga różnica — czas wykonania. Zestaw regresyjny dla aplikacji mobilnej może zajmować od 2 do 12 godzin w zależności od rozmiaru projektu i liczby platform. Smoke Test zajmuje 5–15 minut. Według Sauce Labs (2025), średni czas wykonania zestawu regresyjnego dla aplikacji iOS wynosi 4,5 godziny, dla Androida — 3,2 godziny. Smoke Test na obu platformach mieści się w 10–15 minutach.

Trzecia różnica — miejsce w potoku. Smoke Test jest wykonywany bezpośrednio po kompilacji, przed testowaniem regresyjnym. Jeśli Smoke Test nie zostanie zaliczony, regresja nie jest uruchamiana — oszczędza to zasoby CI/CD. Pipeline efficiency — Smoke Test odsiewa do 30% kompilacji, które nie przeszłyby regresji, a zaoszczędzone zasoby wystarczają do równoległego uruchamiania innych zadań.

Co wchodzi w skład Smoke Test aplikacji mobilnej

Uruchomienie aplikacji

Uruchomienie aplikacji — pierwszy i najważniejszy test. Aplikacja musi uruchamiać się bez awarii na wszystkich docelowych urządzeniach. Smoke Test sprawdza zimny start: instalacja → otwarcie → wyświetlenie pierwszego ekranu. Jeśli aplikacja ulega awarii przy uruchomieniu, dalsze testowanie jest bezcelowe. XCUITest i Espresso pozwalają zautomatyzować sprawdzanie uruchamiania w 2–3 linijkach kodu. Launch argument `-AppleLanguages (pl)` pomaga sprawdzić lokalizację przy starcie.

Autoryzacja

Autoryzacja — drugi krytyczny scenariusz. Smoke Test powinien sprawdzić, czy formularz logowania jest wyświetlany, pola wejściowe reagują na dotyk, przycisk logowania wysyła żądanie, a aplikacja przechodzi do ekranu głównego po udanej autoryzacji. Błąd autoryzacji blokuje dostęp do wszystkich pozostałych funkcji, dlatego jej sprawdzenie wchodzi w skład minimalnego zestawu. Token refresh — dodatkowe sprawdzenie dla aplikacji z OAuth 2.0.

Ładowanie treści i nawigacja

Ładowanie głównej treści — trzeci test Smoke Test. Ekran główny lub kanał aplikacji musi się ładować i wyświetlać dane. Jeśli API nie odpowiada lub parsowanie odpowiedzi jest uszkodzone, użytkownik widzi pusty ekran. Sprawdzenie sieci w Smoke Test obejmuje podstawowe żądanie GET do głównego endpointu i weryfikację, że odpowiedź ma oczekiwaną strukturę. Nawigacja — czwarty scenariusz. Smoke Test przechodzi przez główne ekrany aplikacji: główny → wyszukiwanie → profil → ustawienia. Pasek kart i menu boczne — typowe źródła problemów w nawigacji, które Smoke Test wykrywa na wczesnym etapie.

Automatyzacja Smoke Test w CI/CD

Fastlane — standardowe narzędzie do automatyzacji mobilnego CI/CD. Smoke Test na Fastlane uruchamia się przez `scan` (dla XCUITest) lub `gradle` (dla Espresso). Fastlane pozwala skonfigurować uruchamianie Smoke Test na wielu urządzeniach równolegle, co skraca całkowity czas. Konfiguracja w Fastfile zawiera target na zestaw Smoke Test i próg zaliczenia: 100% udanych testów.

GitHub Actions (2024) opublikował szablon mobilnego CI/CD z wbudowanym Smoke Test. Szablon obejmuje trzy etapy: kompilacja → Smoke Test → regresja. Jeśli Smoke Test upada, szablon automatycznie kończy potok i wysyła powiadomienie do Slack lub Telegram. Matrix strategy pozwala uruchamiać Smoke Test na trzech wersjach iOS i pięciu modelach Androida jednocześnie.

Podział odpowiedzialności w CI/CD: Smoke Test odpowiada za szybką informację zwrotną, regresja — za pełne pokrycie. Smoke Test nie powinien powielać regresji i odwrotnie. Granularność Smoke Test — jedna kontrola na jeden krytyczny scenariusz. Jeśli Smoke Test zajmuje więcej niż 15 minut, należy go zoptymalizować: usunąć nadmiarowe kontrole lub zrównoleglić wykonanie.

# Konfiguracja Fastfile dla 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

Narzędzia do Smoke Test

XCUITest — framework Apple do testowania UI aplikacji iOS. XCUITest jest używany do automatyzacji Smoke Test: uruchamianie aplikacji, sprawdzanie elementów interfejsu, symulowanie działań użytkownika. W połączeniu z Xcode Server lub GitHub Actions XCUITest uruchamia się przy każdym commicie. XCTest — podstawowy framework do testów jednostkowych, który uzupełnia XCUITest do sprawdzania logiki.

Espresso — framework Google do testowania UI Androida. Espresso synchronizuje się z wątkiem UI i gwarantuje, że wszystkie animacje zostały zakończone przed rozpoczęciem kontroli. Espresso obsługuje sprawdzanie przez `onView(withId(...)).check(matches(...))`. Android Test Orchestrator uruchamia każdy Smoke Test w osobnym procesie, co zapobiega wpływowi poprzednich testów na kolejne.

Detox — framework dla React Native, który obsługuje Smoke Test i testowanie grey-box. Detox synchronizuje się z React Native bridge i automatycznie oczekuje na zakończenie operacji asynchronicznych. Testowanie grey-box pozwala Detox sprawdzać stan aplikacji bez bezpośredniego dostępu do kodu źródłowego.

Przykład Smoke Test w Swift i Kotlin

XCUITest dla iOS zawiera dwie kontrole: uruchomienie aplikacji i wyświetlenie ekranu głównego. Test uruchamia aplikację przez `XCUIApplication().launch()` i sprawdza, czy kluczowy element (np. `navigationBar`) istnieje. Jeśli aplikacja ulega awarii przy uruchomieniu, XCTest framework rejestruje błąd i test kończy się FAIL. Smoke Test nie sprawdza zawartości — tylko że ekran się otworzył.

Espresso dla Androida używa `ActivityScenario` do uruchomienia Activity i `onView` do sprawdzania elementów. Kluczowa różnica między platformami: symulator iOS może wykazywać odmienne zachowanie od rzeczywistego urządzenia, dlatego Smoke Test na Androidzie zaleca się uruchamiać na Firebase Test Lab lub emulatorze. Firebase Test Lab obsługuje równoległe uruchamianie Smoke Test na 10 urządzeniach.

import XCTest

class LoginSmokeTest: XCTestCase {
    let app = XCUIApplication()

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

    func testLoginButtonExists() {
        XCTAssertTrue(app.buttons["Zaloguj się"].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))
    }
}

Powyższy przykład pokazuje Smoke Test dla ekranu logowania na iOS. Pierwszy test sprawdza, czy przycisk logowania istnieje na ekranie. Drugi test przechodzi pełną ścieżkę autoryzacji i sprawdza, czy po pomyślnym zalogowaniu wyświetlany jest komunikat powitalny. Timeout 5 sekund dla waitForExistence — standardowa wartość dla Smoke Test: jeśli element UI nie wyświetli się w tym czasie, aplikacja działa nieprawidłowo.