Qu'est-ce que le smoke testing ?

Qu'est-ce que le smoke testing ?

Le smoke testing est un ensemble rapide et superficiel de checks qui tourne contre un build frais pour confirmer que le systeme est assez stable pour meriter un testing plus profond. Il exerce seulement les chemins les plus critiques, comme le fait que l'application demarre, que le login fonctionne et qu'un endpoint central repond, et il repond a une seule question par oui ou non : ce build a-t-il casse quelque chose de si fondamental qu'aucun test ulterieur ne donnera de signal utile ? Si la reponse est oui, le build est rejete immediatement et le reste du pipeline est saute, faisant emerger la regression en secondes plutot qu'apres un long full run.

Origine et sens du terme

Le nom vient de l'ingenierie hardware. Quand un ingenieur mettait sous tension une carte fraichement assemblee pour la premiere fois, la preoccupation etait simple : si de la fumee sortait, la carte etait defectueuse et il etait inutile de poursuivre tout autre test. Le software a repris la metaphore presque telle quelle. Un smoke test est la premiere mise sous tension d'un build. Il ne mesure ni la qualite, ni la correction, ni la completude. Il confirme seulement que le build est assez intact pour justifier le temps et le cout des etapes de test plus profondes qui suivent. C'est pourquoi le smoke testing s'appelle aussi build verification testing (BVT) ou build acceptance testing.

Ce que le smoke testing couvre et ce qu'il ne couvre pas

Un smoke test touche volontairement la largeur, pas la profondeur. Il parcourt les chemins les plus larges et critiques pour le business et confirme que chacun est vivant, sans sonder les edge cases a l'interieur.

• Demarrage de l'application. Le processus boote sans crasher et le health endpoint renvoie 200.
• User flows critiques. Sign-in, le chemin de feature principal et le checkout d'une app de commerce atteignent un etat de succes.
• Handshake d'integration. L'app se connecte a sa base de donnees, son cache et sa message queue sans timeout au boot.
• Disponibilite des assets statiques. Le bundle JavaScript principal et le CSS chargent depuis le CDN avec un 200, pas un 404 du a un hash perime.
• Sante de la configuration. Les variables d'environnement requises se resolvent et il n'y a pas de undefined dans la sortie rendue.

Ce qu'un smoke test ne couvre pas : erreurs de validation, chaque branche d'un workflow, valeurs limites, assertions de securite ou comportement sous charge. Cela appartient au regression testing, au testing fonctionnel ou a un load test dedie. Surcharger une suite de smoke avec ces preoccupations est la facon la plus courante de transformer par accident un gate de 30 secondes en une mini regression suite lente.

Quand tourne le smoke testing

1. A chaque build CI. C'est la premiere etape du pipeline. S'il echoue, le pipeline s'arrete et aucune etape en aval ne tourne.
2. Post-deploy vers staging ou production. Il confirme que le deploy est reellement monte avant que le trafic n'y soit route. Les rollouts blue-green et canary gatent le cut-over sur un smoke test reussi.
3. Apres des changements d'infrastructure. Un nouvel enregistrement DNS, un certificat TLS ou une cible de failover peuvent casser l'integration meme si le code est inchange. Smoke verifie le chemin end-to-end.
4. Avant un load test. Aucun interet a lancer un load test de 30 minutes contre un build dont le login est deja casse. Smoke d'abord, load ensuite.

Smoke testing vs sanity testing

Le smoke et le sanity testing sont souvent confondus car les deux sont rapides et les deux gatent un travail plus profond. La difference est le scope et l'intention. Le smoke testing est large et superficiel : il touche de nombreuses features critiques une fois chacune pour confirmer que tout le build est stable. Le sanity testing est etroit et un peu plus profond : apres un petit changement ou un bugfix, il verifie qu'une zone precise se comporte bien maintenant, sans reverifier tout le systeme. Le smoke est generalement scripte et tourne a chaque build ; le sanity est souvent une verification ciblee, parfois manuelle, sur un release candidate precis.

Smoke testing vs regression testing

Le regression testing repond a une question differente du smoke : non pas "le build est-il executable du tout ?", mais "ce changement a-t-il casse quelque chose qui fonctionnait avant ?" Les suites de regression sont larges et profondes, couvrent de nombreuses features et edge cases et prennent des minutes a des heures. Smoke est le gate rapide qui tourne en premier ; regression est le passage minutieux qui suit. Le tableau place les trois pratiques cote a cote.

Dimension	Smoke testing	Sanity testing	Regression testing
Question posee	Le build est-il executable ?	Ce fix fonctionne-t-il ?	Le changement a-t-il casse l'existant ?
Scope	Large, tous les chemins critiques	Etroit, une zone changee	Large et profond, nombreuses features
Profondeur	Superficiel, un passage chacun	Cible, profondeur moyenne	Profond, edge cases inclus
Duree typique	Secondes a quelques minutes	Minutes	Minutes a heures
Automatisation	Presque toujours scripte	Souvent manuel ou cible	Generalement automatise
Quand il tourne	En premier, a chaque build	Apres un changement precis	Apres le pass smoke

Smoke tests manuels vs automatises

Tot dans un projet, un smoke test manuel peut etre une courte checklist ecrite qu'un developpeur parcourt a la main : ouvrir l'app, se loguer, charger l'ecran principal, passer une commande. C'est bon marche a demarrer et sans tooling, mais cela ne passe pas a l'echelle et ne peut pas gater un pipeline automatise. Des que le build tourne en CI, la suite de smoke devrait etre automatisee pour bloquer un deploy sans humain dans la boucle. Les smoke tests automatises sont du code : une poignee de requetes HTTP avec des assertions sur le status et le body pour les services, ou un court script de navigateur pour les flows cote utilisateur. La regle : ce que vous verifieriez a la main a chaque release est candidat a un smoke test automatise.

Comment concevoir une suite de smoke test

• Couvrez la largeur, pas la profondeur. Choisissez les cinq a quinze chemins dont l'echec rendrait tout le release sans valeur et verifiez chacun exactement une fois.
• Restez rapide. Visez des secondes, pas des minutes. Si la suite depasse quelques minutes, elle est devenue une regression suite.
• Soyez deterministe. Des smoke tests flaky detruisent la confiance dans le pipeline. Eliminez les dependances de timing et ne faites retry que sur des erreurs reseau vraiment transitoires.
• Bloquez le build. Un smoke test echoue doit arreter le pipeline. Il n'y a pas de statut smoke jaune.
• Gardez-le bon marche a ecrire. Quelques checks HTTP plus une courte assertion de navigateur suffisent.

Smoke testing pour les APIs et les web apps

Pour les services HTTP, un court script avec 5 a 15 requetes critical-path est un harness de smoke solide. Dans un outil comme k6 vous fixez un virtual user et une iteration et ajoutez des assertions check() sur le status et le body ; dans JMeter vous utilisez un Thread Group avec un utilisateur et un loop et une Response Assertion par sampler. Point cle : un smoke test qui tourne sur le portable d'un developpeur ne prouve pas que la chaine CDN, DNS et TLS de production fonctionne. Lancer les memes checks depuis une vraie region cloud contre l'endpoint public le fait. C'est ici que le smoke testing continu et le monitoring se recoupent : un moniteur d'API qui frappe vos endpoints critiques de facon planifiee depuis le cloud, comme ceux que vous pouvez construire dans LoadFocus API monitoring, est en pratique un smoke test qui ne s'arrete jamais, et detecte un deploy casse ou un certificat expire en minutes. Les equipes qui veulent le gate cable directement dans le pipeline peuvent lancer les memes checks critical-path depuis LoadFocus avant de promouvoir un build vers un load test complet.

Benefices et limites

Le benefice du smoke testing est un rejet precoce, bon marche et a haute confiance des builds casses. Il echoue vite, protege les etapes de test plus couteuses d'un effort gaspille et donne a chaque deploy un signal clair go ou no-go. Sa limite est exactement son design : il est superficiel a dessein, donc il n'attrapera jamais un bug de logique subtil, une erreur de limite ou une fuite memoire lente. Un smoke test qui passe signifie "le build merite plus de testing", pas "le build est correct".

Bonnes pratiques

• Lancez-le en premier et partout. Faites du smoke le gate d'ouverture de la CI et repetez-le apres chaque deploy vers un nouvel environnement.
• Gardez-le rigoureusement petit. Resistez a l'envie d'ajouter "juste un check de plus" ; une suite de smoke gonflee finit sautee.
• Testez depuis ou sont les utilisateurs. Preferez lancer le smoke post-deploy depuis le cloud contre des endpoints publics, pas depuis un build agent dans votre propre reseau.
• Alertez fort en cas d'echec. Un smoke test echoue doit bloquer, jamais passer en silence un avertissement en aval.
• Revisez la suite quand le produit change. Quand un nouveau flow critique arrive, ajoutez-le au smoke ; quand un chemin est retire, enlevez-le.

FAQ sur le smoke testing

Le smoke testing est-il la meme chose que le build verification testing ?

Oui. Build verification testing (BVT) et build acceptance testing sont les noms formels de la meme pratique : un ensemble rapide de checks qui confirme qu'un nouveau build est assez stable pour passer a un testing plus profond. Le terme smoke testing est plus courant au quotidien.

Combien de temps un smoke test devrait-il prendre ?

Des secondes a quelques minutes au plus. Tout l'interet est d'echouer vite et de gater le pipeline. Si votre suite de smoke prend dix minutes, elle a derive vers le territoire de la regression et devrait etre scindee.

Les smoke tests doivent-ils etre automatises ou manuels ?

Automatises la ou un pipeline existe, car un gate qui bloque le build ne peut pas dependre de la disponibilite d'un humain. Une checklist manuelle est un bon point de depart pour un jeune projet, mais tout check repete a chaque release devrait devenir un smoke test automatise.

Quelle est la difference entre smoke testing et sanity testing ?

Le smoke testing est large et superficiel et tourne a chaque build pour confirmer la stabilite globale. Le sanity testing est etroit et un peu plus profond et tourne apres un changement precis pour confirmer qu'une zone fonctionne maintenant.

Les smoke tests peuvent-ils tourner contre la production ?

Oui, et ils le devraient. Les smoke tests post-deploy contre staging ou production confirment que le release est reellement monte avant que le trafic ne soit route. Les lancer en continu depuis le cloud transforme le smoke testing en verification de production toujours active.

Un smoke test qui passe signifie-t-il que le logiciel est sans bug ?

Non. Un smoke test qui passe signifie seulement que le build est assez stable pour justifier plus de testing. Il est superficiel par conception et ne peut pas attraper les erreurs de logique en edge case, les bugs de limite ou les problemes de performance.