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 système est suffisamment stable pour mériter un testing plus profond. Le nom vient de la QA hardware : alimentez la carte ; si de la fumée sort, arrêtez. En software, il répond à une seule question : le build a-t-il cassé quelque chose de si fondamental qu'aucun test ultérieur ne donnera de signal utile ?

Un smoke test exerce uniquement les chemins les plus critiques. La home rend. Login fonctionne. Un endpoint core d'API renvoie 200. La connexion base de données ouvre. Si l'un de ces points échoue, le build est rejeté et le reste de la test suite est sauté, économisant des minutes CI et faisant émerger la régression en secondes plutôt qu'après un full run de 40 minutes.

Smoke testing vs regression testing vs QA complet

Trois cercles concentriques de couverture, chacun répond à une question différente :

• Smoke testing : le build est-il exécutable du tout ? Secondes à quelques minutes. Tourne en premier.
• Regression testing : ce changement a-t-il cassé quelque chose qui fonctionnait avant ? Minutes à une heure. Tourne après le pass smoke.
• QA complet / acceptance testing : chaque feature respecte-t-elle encore la spec ? Heures, souvent manuel. Tourne moins souvent.

Smoke est le gate. Le sauter signifie qu'une régression de deploy cassé se glisse dans la regression suite et brûle le budget CI entier avant que l'échec ne soit même reporté.

Ce que couvre un smoke test

• Démarrage d'application. Le processus boote sans crasher. Le health endpoint renvoie 200.
• User flows critiques. Sign-in, le chemin de feature principal, checkout (si commerce), un appel API contre l'endpoint le plus utilisé.
• Handshake d'intégration. L'app connecte à sa base de données, cache, message queue. Pas de timeouts au boot.
• Disponibilité des assets statiques. Le bundle JS principal et CSS chargent depuis le CDN avec un 200, pas un 404 d'un mismatch de hash périmé.
• Sanité de configuration. Les env vars requises résolvent. Pas de undefined dans le HTML rendu.

Ce que un smoke test ne couvre pas : edge cases, erreurs de validation, chaque branche d'un workflow, performance sous charge. Cela appartient à regression ou à un load test.

Quand exécuter un smoke test

1. À chaque build CI. Première étape du pipeline. S'il échoue, le pipeline s'arrête et rien d'autre ne tourne.
2. Post-deploy vers staging ou production. Confirme que le deploy est réellement monté avant que le trafic n'y soit routé. Les deploys blue-green gatent le cut-over sur le pass smoke.
3. Après changements d'infrastructure. Nouveau DNS, nouveau certificat TLS, nouvelle cible de failover base de données. Smoke vérifie que l'intégration fonctionne end-to-end.
4. Avant un load test de release-day. Aucun intérêt à exécuter un load test de 30 minutes contre un build dont le login est cassé. Smoke d'abord, load ensuite.

Caractéristiques clés d'un smoke test

• Rapide. Secondes, pas minutes. Si smoke prend 10 minutes, il cesse d'être smoke et devient une mini regression suite.
• Déterministe. Des smoke tests flaky détruisent la confiance dans le pipeline. Éliminez les dépendances timing, retry uniquement sur réseau transitoire.
• Bloque le build. Un smoke test échoué arrête le pipeline. Pas de statut smoke "jaune".
• Bon marché à autoriser. Cinq à quinze checks HTTP plus quelques assertions JS. Ne pas sur-ingénierer.

Comment exécuter un smoke test

Pour les services basés HTTP, un court script JMeter ou k6 avec 5-15 requêtes critical-path est un harness smoke solide. Dans k6, fixez vus: 1, iterations: 1 et ajoutez des assertions check() sur le status et le body. Dans JMeter, utilisez un Thread Group avec 1 utilisateur, 1 loop, et des Response Assertions sur chaque sampler.

Pour le smoke browser-side, un script Playwright ou Cypress de 60 secondes qui se loggue, atterrit sur le feature principal, et assertte sur un élément DOM connu est suffisant. Tout ce qui est plus long appartient à regression.

Pour le smoke deploy-time contre un vrai environnement cloud, exécutez depuis LoadFocus. Les smoke tests qui ont tourné sur un portable développeur ne vous disent pas si la chaîne CDN, DNS et TLS de production fonctionne ; smoke depuis une région cloud contre l'endpoint public oui.

Si votre équipe n'a pas le temps de concevoir et maintenir les harness smoke à travers plusieurs services, LoadFocus propose des load testing services où des ingénieurs construisent les scripts smoke, les câblent dans votre CI/CD et les maintiennent à jour à mesure que l'API surface évolue.