Smoke Test nello sviluppo mobile — cosa è, compiti e come viene applicato

Cos’è uno Smoke Test?

Smoke Test è un insieme di test rapidi che verificano le funzioni principali di un’applicazione senza analisi approfondita. Il termine deriva dall’ingegneria hardware: se un dispositivo inizia a fumare dopo l’assemblaggio, non viene inviato per test completi. Nello sviluppo mobile, lo Smoke Test svolge la stessa funzione — filtra i build chiaramente non funzionanti. Secondo Microsoft DevOps (2024), l’implementazione di uno Smoke Test riduce il numero di difetti che raggiungono il team QA del 40%.

Uno Smoke Test viene eseguito su ogni nuovo build — sia Android che iOS. Idealmente, uno Smoke Test non dovrebbe richiedere più di 15 minuti e dovrebbe avviarsi automaticamente dopo un build riuscito. Criterio di superamento — il 100% dei test della suite Smoke Test deve essere completato con successo. Se almeno un test fallisce, il build viene contrassegnato come instabile e non viene inviato per ulteriori test. Secondo Google Testing Blog (2024), questo approccio riduce il tempo di consegna delle funzionalità agli utenti del 25%.

Uno Smoke Test può essere manuale (una checklist di 5–10 punti) o automatizzato. Nei progetti mobili moderni, si preferisce uno Smoke Test automatizzato integrato in CI/CD. Smoke Test manuale è giustificato solo nelle fasi iniziali del progetto, quando l’automazione non è economicamente vantaggiosa. Secondo Bitrise (2025), il 73% dei team di sviluppo mobile automatizza i propri Smoke Test.

In cosa si differenzia uno Smoke Test dal test di regressione?

Smoke Test e test di regressione sono spesso confusi, ma sono pratiche diverse con obiettivi diversi. Il test di regressione verifica che le modifiche al codice non abbiano rotto la funzionalità esistente. Copre tutti i moduli e gli scenari dell’applicazione, inclusi i casi rari e limite. Uno Smoke Test verifica solo il percorso critico — gli scenari principali senza i quali l’applicazione è inutile. Profondità di copertura è la principale differenza: lo Smoke Test copre il 5–10% della funzionalità, la regressione copre l’80–100%.

La seconda differenza è il tempo di esecuzione. Una suite di regressione per un’applicazione mobile può richiedere da 2 a 12 ore, a seconda delle dimensioni del progetto e del numero di piattaforme. Uno Smoke Test richiede 5–15 minuti. Secondo Sauce Labs (2025), il tempo medio di esecuzione di una suite di regressione per un’app iOS è di 4,5 ore, e per Android — 3,2 ore. Uno Smoke Test su entrambe le piattaforme si completa in 10–15 minuti.

La terza differenza è il posizionamento nella pipeline. Uno Smoke Test viene eseguito immediatamente dopo il build, prima del test di regressione. Se lo Smoke Test fallisce, la regressione non viene avviata — questo risparmia risorse CI/CD. Efficienza della pipeline — uno Smoke Test filtra fino al 30% dei build che sarebbero falliti nella regressione, e le risorse risparmiate sono sufficienti per eseguire altre attività in parallelo.

Cosa è incluso in uno Smoke Test di un’app mobile

Avvio dell’applicazione

Avvio dell’applicazione — il primo e più importante test. L’applicazione deve avviarsi senza crash su tutti i dispositivi target. Uno Smoke Test verifica l’avvio a freddo: installa → apri → mostra la prima schermata. Se l’app si blocca all’avvio, ulteriori test sono inutili. XCUITest ed Espresso consentono di automatizzare il controllo dell’avvio in 2–3 righe di codice. Argomento di avvio `-AppleLanguages (ru)` aiuta a verificare la localizzazione all’avvio.

Autenticazione

Autenticazione — il secondo scenario critico. Uno Smoke Test deve verificare che il modulo di login venga visualizzato, i campi di input rispondano al tocco, il pulsante di login invii una richiesta e l’applicazione navighi alla schermata principale dopo l’autenticazione riuscita. Un errore di autenticazione blocca l’accesso a tutte le altre funzioni, quindi il suo controllo è incluso nell’insieme minimo. Token refresh — un controllo aggiuntivo per le applicazioni con OAuth 2.0.

Caricamento dei contenuti e navigazione

Caricamento del contenuto principale — il terzo test dello Smoke Test. La schermata principale o il feed dell’applicazione deve caricarsi e mostrare i dati. Se l’API non risponde o l’analisi della risposta è danneggiata, l’utente vede una schermata vuota. Il controllo della rete in uno Smoke Test include una richiesta GET di base all’endpoint principale e la verifica che la risposta abbia la struttura prevista. Navigazione — il quarto scenario. Uno Smoke Test naviga attraverso le schermate principali dell’applicazione: home → ricerca → profilo → impostazioni. La barra delle schede e il menu laterale sono fonti tipiche di problemi di navigazione che uno Smoke Test rileva precocemente.

Automazione dello Smoke Test in CI/CD

Fastlane — lo strumento standard per automatizzare il CI/CD mobile. Uno Smoke Test in Fastlane viene eseguito tramite `scan` (per XCUITest) o `gradle` (per Espresso). Fastlane consente di configurare l’esecuzione dello Smoke Test su più dispositivi in parallelo, riducendo il tempo complessivo. Configurazione in Fastfile include il targeting della suite Smoke Test e una soglia di superamento: 100% di test riusciti.

GitHub Actions (2024) ha pubblicato un modello CI/CD mobile con uno Smoke Test integrato. Il modello include tre fasi: build → Smoke Test → regressione. Se lo Smoke Test fallisce, il modello termina automaticamente la pipeline e invia una notifica a Slack o Telegram. Matrix strategy consente di eseguire lo Smoke Test su tre versioni di iOS e cinque modelli Android contemporaneamente.

Divisione delle responsabilità in CI/CD: lo Smoke Test fornisce un feedback rapido, mentre la regressione fornisce una copertura completa. Lo Smoke Test non deve duplicare la regressione, e viceversa. Granularità dello Smoke Test — un controllo per scenario critico. Se uno Smoke Test richiede più di 15 minuti, deve essere ottimizzato: rimuovere i controlli ridondanti o parallelizzare l’esecuzione.

# Configurazione Fastfile per 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

Strumenti per Smoke Test

XCUITest — il framework di Apple per i test dell’interfaccia utente delle applicazioni iOS. XCUITest viene utilizzato per automatizzare gli Smoke Test: avviare l’app, verificare gli elementi dell’interfaccia, simulare le azioni dell’utente. In combinazione con Xcode Server o GitHub Actions, XCUITest viene eseguito a ogni commit. XCTest — il framework di base per i test unitari che complementa XCUITest per la verifica della logica.

Espresso — il framework di Google per i test dell’interfaccia Android. Espresso si sincronizza con il thread dell’interfaccia utente e garantisce che tutte le animazioni siano completate prima dell’inizio della verifica. Espresso supporta la verifica tramite `onView(withId(...)).check(matches(...))`. Android Test Orchestrator esegue ogni Smoke Test in un processo separato, impedendo ai test precedenti di influenzare quelli successivi.

Detox — un framework per React Native che supporta Smoke Test e test grey-box. Detox si sincronizza con il bridge di React Native e attende automaticamente il completamento delle operazioni asincrone. Test grey-box consentono a Detox di verificare lo stato dell’applicazione senza accesso diretto al codice sorgente.

Esempio di Smoke Test in Swift e Kotlin

XCUITest per iOS contiene due verifiche: avviare l’applicazione e mostrare la schermata principale. Il test avvia l’app tramite `XCUIApplication().launch()` e verifica che un elemento chiave (ad esempio, `navigationBar`) esista. Se l’app si blocca all’avvio, il framework XCTest registra l’errore e il test termina con FAIL. Smoke Test non verifica il contenuto — solo che la schermata si sia aperta.

Espresso per Android utilizza `ActivityScenario` per avviare un’Activity e `onView` per verificare gli elementi. Una differenza critica tra le piattaforme: il simulatore iOS può mostrare un comportamento diverso da un dispositivo reale, pertanto si consiglia di eseguire gli Smoke Test Android su Firebase Test Lab o un emulatore. Firebase Test Lab supporta l’esecuzione parallela di Smoke Test su 10 dispositivi.

import XCTest

class LoginSmokeTest: XCTestCase {
    let app = XCUIApplication()

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

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

L’esempio sopra mostra uno Smoke Test per la schermata di login su iOS. Il primo test verifica che il pulsante di login esista sulla schermata. Il secondo test percorre il percorso completo di autenticazione e verifica che dopo un login riuscito venga visualizzato un messaggio di benvenuto. Timeout di 5 secondi per `waitForExistence` è il valore standard per uno Smoke Test: se l’elemento dell’interfaccia non appare in quel tempo, l’applicazione non funziona correttamente.