Qu'est-ce que le smoke testing ?

Qu'est-ce que le smoke testing ?

Le smoke testing (test de fumée) est une série rapide et superficielle de vérifications exécutée sur un nouveau build pour confirmer que ses fonctions les plus critiques marchent, avant de consacrer du temps à des tests plus poussés. Si l'application ne démarre pas, si la connexion échoue ou si un endpoint essentiel renvoie une erreur, le build est rejeté immédiatement. On parle aussi de tests de vérification de build (BVT).

Cette page donne la définition courte. Le guide complet, avec un exemple de parcours d'achat et une méthode pour automatiser une suite, se trouve sur le blog (en anglais) : smoke testing in software testing.

Ce que vérifie un test de fumée

Un test de fumée couvre la largeur, pas la profondeur. Il touche une fois chaque parcours critique pour l'activité, puis passe au suivant.

• L'application démarre et son endpoint de santé répond 200.
• Un utilisateur peut se connecter.
• Le parcours principal fonctionne, par exemple recherche, ajout au panier et ouverture de la page de paiement.
• L'application joint sa base de données, son cache et sa file de messages sans dépasser le délai.
• Les principaux fichiers JavaScript et CSS se chargent avec un 200 et non un 404.

Les règles de validation, les cas limites, les contrôles de sécurité et le comportement sous charge ne relèvent pas d'un test de fumée. Ils appartiennent aux tests de régression, aux tests fonctionnels et aux tests de charge.

Quand l'exécuter

1. À chaque build d'intégration continue, comme première étape. S'il échoue, le reste du pipeline ne s'exécute pas.
2. Après chaque déploiement en préproduction ou en production, avant d'envoyer du trafic vers la nouvelle version.
3. Après un changement d'infrastructure comme un nouvel enregistrement DNS, un certificat TLS ou un basculement de base de données, même si le code n'a pas bougé.
4. Avant un test de charge. Un test de 30 minutes contre un build dont la connexion est déjà cassée ne produit que du bruit.

Exemple

Une boutique en ligne déploie une nouvelle version. La suite de fumée demande la page d'accueil, lance une recherche, ajoute un produit au panier, ouvre la page de paiement et interroge l'endpoint de santé. Cinq vérifications, exécutées une fois chacune, terminées en quelques secondes ou deux minutes. Si la page de paiement renvoie une erreur 500, le déploiement s'arrête et l'équipe examine cet unique échec, au lieu de lire des centaines de résultats rouges issus d'une régression complète.

Tests de fumée, de cohérence et de régression

• Le smoke testing est large et superficiel : ce build est-il assez vivant pour être testé plus avant ?
• Le sanity testing est ciblé : après une petite correction, cette zone précise se comporte-t-elle correctement ?
• Les tests de régression sont larges et profonds : cette modification a-t-elle cassé quelque chose qui fonctionnait ? Ils s'exécutent une fois le test de fumée passé.

Smoke testing pour les API et les applications web

Pour un service HTTP, un test de fumée peut se limiter à quelques requêtes avec des assertions sur le statut et le corps de la réponse. Avec k6, cela donne un utilisateur virtuel, une itération et un check() par requête. Avec JMeter, c'est un groupe de threads avec un thread et une boucle, plus une assertion de réponse sur chaque sampler. Dans un projet Java, marquer les tests critiques avec un groupe TestNG fournit un jeu de fumée exécutable séparément.

Un test de fumée lancé depuis un ordinateur portable ne prouve pas que le DNS public, le CDN et la chaîne de certificats fonctionnent. Les mêmes vérifications lancées depuis le cloud contre l'URL publique, si. La surveillance d'API planifiée est en pratique un test de fumée qui ne s'arrête jamais : LoadFocus API Monitoring exécute vos requêtes critiques selon un calendrier depuis le cloud et vous alerte dès que l'une échoue. Pour le test de charge qui suit le test de fumée, voir les tests de charge k6.

Erreurs fréquentes

• Laisser la suite grossir. Quand elle dure dix minutes, c'est une suite de régression et plus personne ne la lance en premier.
• Tolérer des vérifications instables. Un test de fumée qui échoue au hasard apprend à l'équipe à l'ignorer.
• Confondre vert et correct. Réussir signifie que le build mérite d'autres tests, pas qu'il est sans défaut.
• Ne l'exécuter que dans votre propre réseau, ce qui masque les problèmes de DNS, de CDN et de certificat.
• Ne jamais la mettre à jour. Quand un nouveau parcours critique sort, ajoutez-le ; quand l'un disparaît, retirez-le.

Questions fréquentes sur le smoke testing

Le smoke testing est-il la même chose que les tests de vérification de build ?

Oui. Build verification testing (BVT) et build acceptance testing sont d'autres noms de la même pratique : une vérification rapide qu'un nouveau build est assez stable pour passer à des tests plus poussés.

Combien de temps un test de fumée doit-il durer ?

De quelques secondes à deux minutes environ. Si votre suite dure dix minutes, scindez-la et ne gardez en fumée que les vérifications vraiment critiques.

Faut-il automatiser les tests de fumée ?

Oui, dès qu'un pipeline existe, car une barrière qui bloque les builds ne peut pas attendre une personne. Une liste de contrôle suffit pour un jeune projet, mais toute vérification répétée à chaque version devrait être automatisée.

Quelle est la différence entre smoke testing et sanity testing ?

Le smoke testing est large et superficiel et s'exécute à chaque build. Le sanity testing est ciblé et s'exécute après une modification précise pour confirmer que cette zone fonctionne désormais.

Peut-on lancer des tests de fumée en production ?

Oui, avec des actions en lecture seule ou des actions de test clairement identifiées. Lancés après un déploiement, ou en continu comme moniteur planifié, ils confirment que la version sert réellement les utilisateurs.

Un test de fumée réussi signifie-t-il que le logiciel est sans bug ?

Non. Il signifie seulement que le build est assez stable pour justifier des tests plus poussés. Les cas limites, les erreurs de logique et les problèmes de performance exigent des tests de régression, fonctionnels et de charge.