Smoke Test dans le développement mobile — qu’est-ce que c’est, tâches et comment il est appliqué

Qu’est-ce qu’un Smoke Test?

Smoke Test est un ensemble de tests rapides qui vérifient les fonctions principales d’une application sans analyse approfondie. Le terme vient de l’ingénierie matérielle : si un dispositif commence à fumer après l’assemblage, il n’est pas envoyé pour des tests complets. Dans le développement mobile, le Smoke Test remplit la même fonction — il filtre les compilations manifestement non fonctionnelles. Selon Microsoft DevOps (2024), la mise en œuvre d’un Smoke Test réduit le nombre de défauts atteignant l’équipe QA de 40%.

Un Smoke Test est exécuté sur chaque nouvelle compilation — à la fois Android et iOS. Idéalement, un Smoke Test ne devrait pas prendre plus de 15 minutes et se lancer automatiquement après une compilation réussie. Critère de réussite — 100% des tests de l’ensemble Smoke Test doivent aboutir. Si au moins un test échoue, la compilation est marquée comme instable et n’est pas envoyée pour des tests supplémentaires. Selon Google Testing Blog (2024), cette approche réduit le temps de livraison des fonctionnalités aux utilisateurs de 25%.

Un Smoke Test peut être manuel (une liste de vérification de 5–10 points) ou automatisé. Dans les projets mobiles modernes, la préférence est donnée à un Smoke Test automatisé intégré dans CI/CD. Smoke Test manuel n’est justifié qu’aux premiers stades du projet, lorsque l’automatisation n’est pas économiquement viable. Selon Bitrise (2025), 73% des équipes de développement mobile automatisent leurs Smoke Tests.

En quoi un Smoke Test diffère-t-il des tests de régression?

Smoke Test et tests de régression sont souvent confondus, mais ce sont des pratiques différentes avec des objectifs différents. Les tests de régression vérifient que les modifications du code n’ont pas cassé les fonctionnalités existantes. Ils couvrent tous les modules et scénarios de l’application, y compris les cas rares et limites. Un Smoke Test vérifie uniquement le chemin critique — les scénarios principaux sans lesquels l’application est inutile. Profondeur de couverture est la principale différence : le Smoke Test couvre 5–10% de la fonctionnalité, la régression couvre 80–100%.

La deuxième différence est le temps d’exécution. Un ensemble de régression pour une application mobile peut prendre de 2 à 12 heures, selon la taille du projet et le nombre de plateformes. Un Smoke Test prend 5–15 minutes. Selon Sauce Labs (2025), le temps d’exécution moyen d’un ensemble de régression pour une application iOS est de 4,5 heures, et pour Android — 3,2 heures. Un Smoke Test sur les deux plateformes se termine en 10–15 minutes.

La troisième différence est le placement dans le pipeline. Un Smoke Test est exécuté immédiatement après la compilation, avant les tests de régression. Si le Smoke Test échoue, la régression n’est pas lancée — cela économise les ressources CI/CD. Efficacité du pipeline — un Smoke Test filtre jusqu’à 30% des compilations qui auraient échoué en régression, et les ressources économisées sont suffisantes pour exécuter d’autres tâches en parallèle.

Ce qui est inclus dans un Smoke Test d’application mobile

Lancement de l’application

Lancement de l’application — le premier et le plus important test. L’application doit démarrer sans planter sur tous les appareils cibles. Un Smoke Test vérifie le démarrage à froid : installer → ouvrir → afficher le premier écran. Si l’application plante au démarrage, les tests supplémentaires sont inutiles. XCUITest et Espresso permettent d’automatiser la vérification du lancement en 2–3 lignes de code. Argument de lancement `-AppleLanguages (ru)` aide à vérifier la localisation au démarrage.

Authentification

Authentification — le deuxième scénario critique. Un Smoke Test doit vérifier que le formulaire de connexion est affiché, les champs de saisie répondent au toucher, le bouton de connexion envoie une requête et l’application navigue vers l’écran principal après une authentification réussie. Une erreur d’authentification bloque l’accès à toutes les autres fonctions, donc sa vérification est incluse dans l’ensemble minimal. Token refresh — une vérification supplémentaire pour les applications avec OAuth 2.0.

Chargement du contenu et navigation

Chargement du contenu principal — le troisième test du Smoke Test. L’écran principal ou le fil d’actualité de l’application doit se charger et afficher des données. Si l’API ne répond pas ou l’analyse de la réponse est cassée, l’utilisateur voit un écran vide. La vérification réseau dans un Smoke Test inclut une requête GET de base au point d’accès principal et la vérification que la réponse a la structure attendue. Navigation — le quatrième scénario. Un Smoke Test parcourt les écrans principaux de l’application : accueil → recherche → profil → paramètres. La barre d’onglets et le menu latéral sont des sources typiques de problèmes de navigation qu’un Smoke Test détecte précocement.

Automatisation du Smoke Test dans CI/CD

Fastlane — l’outil standard pour automatiser le CI/CD mobile. Un Smoke Test dans Fastlane est exécuté via `scan` (pour XCUITest) ou `gradle` (pour Espresso). Fastlane permet de configurer l’exécution du Smoke Test sur plusieurs appareils en parallèle, réduisant le temps total. Configuration dans Fastfile inclut la cible de l’ensemble Smoke Test et un seuil de réussite : 100% de tests réussis.

GitHub Actions (2024) a publié un modèle de CI/CD mobile avec un Smoke Test intégré. Le modèle comprend trois étapes : compilation → Smoke Test → régression. Si le Smoke Test échoue, le modèle termine automatiquement le pipeline et envoie une notification à Slack ou Telegram. Matrix strategy permet d’exécuter le Smoke Test sur trois versions d’iOS et cinq modèles Android simultanément.

Répartition des responsabilités dans CI/CD : le Smoke Test fournit un retour rapide, tandis que la régression fournit une couverture complète. Le Smoke Test ne doit pas dupliquer la régression, et vice versa. Granularité du Smoke Test — une vérification par scénario critique. Si un Smoke Test prend plus de 15 minutes, il doit être optimisé : supprimer les vérifications redondantes ou paralléliser l’exécution.

# Configuration Fastfile pour 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

Outils pour Smoke Test

XCUITest — le framework d’Apple pour les tests d’interface utilisateur des applications iOS. XCUITest est utilisé pour automatiser les Smoke Tests : lancer l’application, vérifier les éléments d’interface, simuler les actions de l’utilisateur. Combiné avec Xcode Server ou GitHub Actions, XCUITest s’exécute à chaque commit. XCTest — le framework de base pour les tests unitaires qui complète XCUITest pour la vérification de la logique.

Espresso — le framework de Google pour les tests d’interface Android. Espresso se synchronise avec le thread d’interface utilisateur et garantit que toutes les animations sont terminées avant le début de la vérification. Espresso prend en charge la vérification via `onView(withId(...)).check(matches(...))`. Android Test Orchestrator exécute chaque Smoke Test dans un processus séparé, empêchant les tests antérieurs d’influencer les suivants.

Detox — un framework pour React Native qui prend en charge les Smoke Tests et les tests en boîte grise. Detox se synchronise avec le pont React Native et attend automatiquement la fin des opérations asynchrones. Tests en boîte grise permettent à Detox de vérifier l’état de l’application sans accès direct au code source.

Exemple de Smoke Test en Swift et Kotlin

XCUITest pour iOS contient deux vérifications : lancer l’application et afficher l’écran principal. Le test lance l’application via `XCUIApplication().launch()` et vérifie qu’un élément clé (par exemple, `navigationBar`) existe. Si l’application plante au lancement, le framework XCTest enregistre l’erreur et le test se termine avec FAIL. Smoke Test ne vérifie pas le contenu — seulement que l’écran s’est ouvert.

Espresso pour Android utilise `ActivityScenario` pour lancer une Activity et `onView` pour vérifier les éléments. Une différence critique entre les plateformes : le simulateur iOS peut présenter un comportement différent d’un appareil réel, il est donc recommandé d’exécuter les Smoke Tests Android sur Firebase Test Lab ou un émulateur. Firebase Test Lab prend en charge l’exécution parallèle de Smoke Tests sur 10 appareils.

import XCTest

class LoginSmokeTest: XCTestCase {
    let app = XCUIApplication()

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

    func testLoginButtonExists() {
        XCTAssertTrue(app.buttons["Connexion"].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’exemple ci-dessus montre un Smoke Test pour l’écran de connexion sur iOS. Le premier test vérifie que le bouton de connexion existe sur l’écran. Le deuxième test parcourt le chemin complet d’authentification et vérifie qu’un message de bienvenue est affiché après une connexion réussie. Timeout de 5 secondes pour `waitForExistence` est la valeur standard pour un Smoke Test : si l’élément d’interface n’apparaît pas dans ce délai, l’application ne fonctionne pas correctement.