Smoke test vs Sanity test : arrêter de les confondre
Si vous travaillez dans le développement logiciel ou le Quality Engineering, vous avez probablement déjà entendu parler des termes « smoke test » et « sanity test ». Et si vous êtes comme la plupart des gens, vous les avez peut-être même confondus. C'est tout à fait normal ! Ces deux types de tests se ressemblent beaucoup en apparence : ils sont rapides, ils visent à vérifier la stabilité d'une application, et ils font partie des pratiques essentielles en assurance qualité.
Pourtant, ils répondent à des questions différentes et interviennent à des moments distincts du cycle de développement. Confondre les deux peut mener à des inefficacités dans votre processus de test, voire à laisser passer des bugs critiques. Dans cet article, je vais vous expliquer clairement ce qui différencie le smoke test du sanity test, avec des exemples concrets pour que vous ne les confondiez plus jamais.
Qu'est-ce qu'un Smoke Test ?
Le smoke test, aussi appelé « test de vérification de build » ou « build verification test », est votre premier contrôle de santé d'une nouvelle version logicielle. Imaginez que vous venez de recevoir une nouvelle build de votre application. Avant de vous lancer dans des tests approfondis qui vont prendre des heures, vous voulez savoir une chose simple : est-ce que cette build est suffisamment stable pour que ça vaille la peine de continuer à la tester ?
C'est exactement le rôle du smoke test. Il vérifie que les fonctionnalités les plus critiques de votre application fonctionnent au niveau le plus basique. Si le smoke test échoue, cela signifie que la build a des problèmes majeurs et qu'elle doit retourner chez les développeurs avant tout autre test.
Caractéristiques du Smoke Test
Le smoke test a une portée large mais superficielle. Il touche l'ensemble du système pour vérifier que rien ne « fume » littéralement. D'où son nom, qui vient de la pratique du test matériel où l'on allumait un nouvel appareil pour la première fois et on considérait que c'était un succès s'il ne prenait pas feu.
En pratique, le smoke test peut être défini comme une suite de tests qui couvre la fonctionnalité principale d’un composant ou d’un système, afin de déterminer s’il “fonctionne correctement” avant de démarrer la campagne de test prévue
Ce type de test est généralement automatisé et intégré dans les pipelines d'intégration continue. Il est exécuté fréquemment, souvent après chaque nouvelle build ou déploiement. Les cas de test sont prédéfinis et documentés, ce qui permet de maintenir une cohérence dans les vérifications.
Exemple Concret de Smoke Test
Prenons l'exemple d'une plateforme e-commerce. Vous venez de recevoir une nouvelle build. Votre smoke test va vérifier des choses comme :
- L'application se lance correctement sans erreur
- La page d'accueil s'affiche
- Un utilisateur peut se connecter avec des identifiants valides
- La recherche de produit retourne des résultats
- Un produit peut être ajouté au panier
- Le processus de paiement peut être initié
Notez que le smoke test ne vérifie pas tous les détails. Par exemple, il ne teste pas si tous les filtres de recherche fonctionnent, ou si toutes les méthodes de paiement sont opérationnelles. Il vérifie simplement que les flux principaux ne sont pas complètement cassés.
Un autre exemple concret serait une calculatrice. Le smoke test vérifierait que 1 + 1 = 2. Si le résultat est 3, inutile de tester si les fonctions trigonométriques fonctionnent. La build doit retourner en développement immédiatement.
Qu'est-ce qu'un Sanity Test ?
Le sanity test intervient dans un contexte différent. Vous avez une build qui est déjà stable et qui a passé les smoke tests. Les développeurs viennent d'apporter des modifications mineures : peut-être un bug fix, l'ajout d'une petite fonctionnalité, ou une amélioration de performance. Le sanity test vérifie que ces changements spécifiques fonctionnent comme prévu et qu'ils n'ont pas introduit de nouveaux problèmes. il s’agit de tests ciblés.
Certes, le sanity test a une définition qui met souvent le bazar, parce que selon certains glossaires, “sanity test” ont par le passé renvoyés directement au “smoke test” . Mais, il s’agit bel et bien de tests avec des objectifs différents.
Mais dans la pratique, le smoke test qui couvre large, le sanity test est ciblé et profond. Il se concentre uniquement sur les zones impactées par les modifications récentes. C'est un contrôle de « bon sens » pour s'assurer que les changements ont du sens et qu'ils n'ont pas cassé ce qui fonctionnait déjà.
Caractéristiques du Sanity Test
Le sanity test a une portée étroite mais un examen plus détaillé que le smoke test. Il est généralement effectué manuellement, car il nécessite une compréhension approfondie des changements apportés. Les cas de test ne sont souvent pas documentés à l'avance, car ils dépendent de la nature spécifique des modifications.
Ce type de test est exécuté après avoir reçu une build stable avec des changements mineurs. Il fait partie du processus de regression testing et aide à décider si des tests de régression plus complets sont nécessaires. Si le sanity test échoue, la build est rejetée pour éviter de perdre du temps sur des tests plus rigoureux.
Exemple Concret de Sanity Test
Reprenons notre plateforme e-commerce. Les développeurs ont corrigé un bug où le champ de mot de passe sur la page de connexion acceptait des mots de passe de moins de 6 caractères, alors que la politique de sécurité exige un minimum de 6 caractères.
Votre sanity test va se concentrer spécifiquement sur cette fonctionnalité :
- Accéder à la page de connexion
- Tenter de créer un compte avec un mot de passe de 5 caractères (doit être rejeté)
- Créer un compte avec un mot de passe de 6 caractères (doit être accepté)
- Vérifier que la connexion fonctionne correctement avec le nouveau compte
- S'assurer que d'autres fonctionnalités de la page de connexion ne sont pas affectées
Le sanity test ne vérifie pas l'ensemble de l'application. Il se concentre uniquement sur le système de mot de passe et ses interactions directes. C'est un test rapide mais ciblé pour confirmer que le fix fonctionne et qu'il n'a pas causé de problèmes collatéraux.
Autre exemple : si une application de réservation de taxi a amélioré la vitesse de chargement d'une page spécifique, le sanity test vérifiera que cette page se charge effectivement plus rapidement, tout en s'assurant que les fonctionnalités de cette page (comme la réservation d'un trajet) fonctionnent toujours normalement.
Les différences clés : Smoke Test vs Sanity Test
Maintenant que nous avons exploré chaque type de test séparément, clarifions les différences fondamentales qui les distinguent. Comprendre ces nuances vous permettra de savoir exactement quel test utiliser et quand.
1. Objectif et portée
Le smoke test vérifie la stabilité globale d'une nouvelle build. Son objectif est de répondre à la question : « Cette build est-elle assez stable pour justifier des tests plus approfondis ? » Il couvre l'ensemble du système mais de manière superficielle.
Le sanity test vérifie la rationalité de changements spécifiques. Son objectif est de répondre à : « Les modifications récentes fonctionnent-elles comme prévu sans casser ce qui existait ? » Il cible des fonctionnalités spécifiques mais les examine en profondeur.
2. Moment d'exécution
Le smoke test est exécuté en premier, dès qu'une nouvelle build est disponible. C'est votre première ligne de défense. Si une build échoue au smoke test, elle ne passe même pas à l'étape suivante.
Le sanity test intervient plus tard, après que la build a passé les smoke tests et est considérée comme stable. Il est effectué lorsque des changements mineurs sont apportés à cette build stable, généralement avant ou après les tests de régression complets.
3. Niveau de documentation
Le smoke test est généralement bien documenté et scripté. Les cas de test sont prédéfinis et standardisés, ce qui facilite l'automatisation et assure la cohérence entre les builds.
Le sanity test est souvent non scripté et informel. Il repose sur la compréhension du testeur des changements apportés. Cette flexibilité permet d'adapter rapidement les tests aux modifications spécifiques, mais peut rendre la reproductibilité plus difficile.
4. Automatisation
Le smoke test est idéal pour l'automatisation. Puisque les cas de test sont standardisés et répétitifs, il est généralement intégré dans les pipelines d'intégration continue et s'exécute automatiquement à chaque nouvelle build.
Le sanity test est majoritairement manuel. Sa nature ciblée et variable rend l'automatisation moins pratique et moins rentable. Cependant, dans certains cas, des sanity tests automatisés peuvent être créés pour des changements fréquents et prévisibles.
5. Profondeur vs largeur
Le smoke test privilégie la largeur : il touche à de nombreuses fonctionnalités mais reste en surface. C'est un balayage rapide de l'ensemble du système.
Le sanity test privilégie la profondeur : il se concentre sur un nombre limité de fonctionnalités mais les examine plus minutieusement pour s'assurer qu'elles fonctionnent correctement après les modifications.
Comment utiliser les deux tests ensemble
La beauté de ces deux types de tests, c'est qu'ils ne s'excluent pas mutuellement. Au contraire, ils se complètent parfaitement dans un processus de Quality Engineering bien structuré.
Voici le flux typique dans un cycle de développement. Quand une nouvelle build arrive, vous commencez par exécuter le smoke test. Si ce test échoue, la build retourne immédiatement en développement. Pas besoin d'aller plus loin. Si le smoke test passe, la build est considérée comme stable et peut avancer.
Ensuite, si des modifications mineures ou des corrections de bugs ont été apportées à cette build stable, vous effectuez un sanity test pour vérifier ces changements spécifiques. Si le sanity test échoue, la build retourne en développement pour correction. S'il passe, vous pouvez procéder à des tests plus approfondis comme les tests de régression complets, les tests d'intégration, et les tests d'acceptation utilisateur.
Cette approche séquentielle agit comme un système de filtres. Chaque niveau de test capture des problèmes différents, empêchant les défauts de se propager plus loin dans le cycle de développement. Le smoke test attrape les problèmes majeurs qui rendraient la build complètement inutilisable. Le sanity test attrape les problèmes liés aux changements récents. Et les tests suivants s'assurent que tout fonctionne de manière cohérente et complète.
Cette stratégie vous fait gagner un temps précieux et des ressources considérables. Imaginez si vous lanciez directement des tests de régression complets sur une build instable. Vous perdriez des heures, voire des jours, sur une build qui aurait été rejetée en quelques minutes avec un simple smoke test.
Erreurs courantes à éviter
Même avec une bonne compréhension théorique, il est facile de tomber dans certains pièges lors de l'implémentation de ces tests. Voici les erreurs les plus courantes que je rencontre.
Première erreur : confondre les deux types de tests et les utiliser de manière interchangeable. Certaines équipes appellent « smoke test » ce qui est en réalité un sanity test, et vice versa. Cette confusion crée des malentendus dans l'équipe et peut mener à des lacunes dans la couverture de test. Soyez précis dans votre terminologie.
Deuxième erreur : rendre les smoke tests trop exhaustifs. Le but d'un smoke test est d'être rapide. Si votre smoke test prend plusieurs heures, c'est qu'il est devenu un test de régression. Gardez-le léger et concentré sur les fonctionnalités vraiment critiques.
Troisième erreur : négliger la maintenance des tests. Les smoke tests automatisés doivent être mis à jour à mesure que votre application évolue. Un smoke test obsolète peut donner de faux positifs ou de faux négatifs, ce qui nuit à la confiance de l'équipe dans les résultats.
Quatrième erreur : effectuer des sanity tests sans comprendre les changements. Le sanity test repose fortement sur la compréhension du testeur. Si vous ne savez pas exactement ce qui a changé dans la build, vous risquez de passer à côté de zones critiques à tester ou de perdre du temps sur des zones non affectées.
Cinquième erreur : s'appuyer uniquement sur ces tests. Le smoke test et le sanity test sont des portes d'entrée, pas des tests complets. Ils ne remplacent jamais les tests fonctionnels, les tests de régression, les tests d'intégration ou les tests d'acceptation utilisateur. Utilisez-les comme des filtres préliminaires, pas comme votre seule stratégie de test.
A Retenir
Le smoke test et le sanity test sont deux piliers fondamentaux d'une stratégie de Quality Engineering efficace. Bien qu'ils se ressemblent à première vue, ils jouent des rôles distincts et complémentaires dans le cycle de développement logiciel.
Le smoke test est votre gardien de première ligne. Il vérifie rapidement et largement que votre nouvelle build ne va pas partir en fumée. Le sanity test, quant à lui, est votre vérificateur de bon sens. Il s'assure que les changements récents ont été implémentés rationnellement et qu'ils n'ont pas introduit de nouveaux problèmes.
En comprenant clairement les différences entre ces deux types de tests et en les utilisant correctement, vous optimisez votre processus de test, économisez du temps et des ressources, et améliorez significativement la qualité de vos livraisons logicielles. N'oubliez pas : le smoke test vérifie la stabilité globale d'une nouvelle build, tandis que le sanity test valide des changements spécifiques sur une build stable.
Maintenant que vous connaissez les nuances entre ces deux pratiques essentielles, vous ne les confondrez plus jamais. Et surtout, vous saurez exactement quand et comment les utiliser pour maximiser l'efficacité de votre équipe QA.
FAQ
1. Peut-on faire un sanity test sans faire de smoke test ?
Techniquement oui, mais ce n'est pas recommandé. Le smoke test vérifie d'abord que la build est fondamentalement stable. Si vous sautez cette étape, vous pourriez perdre du temps à effectuer des sanity tests ciblés sur une build qui a des problèmes majeurs ailleurs. Il est plus efficace de suivre l'ordre logique : smoke test d'abord, puis sanity test.
2. Combien de temps devraient durer ces tests ?
Un smoke test devrait idéalement prendre entre 5 et 30 minutes maximum. S'il prend plus longtemps, il est probablement trop complet. Pour le sanity test, la durée dépend de l'ampleur des changements, mais généralement il ne devrait pas dépasser 1 à 2 heures. Ces tests sont conçus pour être rapides et donner un feedback immédiat.
3. Qui devrait effectuer ces tests ?
Le smoke test peut être effectué par les développeurs ou les testeurs, mais il est généralement automatisé et exécuté par le système d'intégration continue. Le sanity test est typiquement effectué par les testeurs QA, car il nécessite une compréhension des changements récents et une expertise en test manuel.
4. Faut-il documenter les sanity tests ?
Bien que les sanity tests soient souvent non scriptés, il est quand même bénéfique de documenter au moins les zones testées et les résultats. Cela aide à la traçabilité et permet de reproduire les tests si nécessaire. Utilisez un outil de gestion de tests ou au minimum un simple document partagé pour noter ce qui a été vérifié.
5. Le sanity test remplace-t-il le test de régression ?
Non, absolument pas. Le sanity test est en fait un sous-ensemble très ciblé du test de régression. Il vérifie rapidement que les changements spécifiques fonctionnent, mais ne remplace pas un test de régression complet qui s'assure que l'ensemble de l'application fonctionne toujours correctement après les modifications.
6. Que faire si le smoke test échoue ?
Si le smoke test échoue, la build doit être rejetée et retournée immédiatement à l'équipe de développement. Il n'y a aucun intérêt à poursuivre les tests sur une build instable. Communiquez clairement les résultats du test, identifiez les fonctionnalités critiques qui ont échoué, et attendez une nouvelle build corrigée.
7. Peut-on combiner smoke test et sanity test en un seul test ?
Dans certaines organisations, les cas de test de smoke et de sanity sont combinés pour accélérer le processus. Cependant, cela peut créer de la confusion et diluer l'objectif de chaque type de test. Il est généralement préférable de les maintenir séparés pour plus de clarté, même si dans la pratique ils peuvent être exécutés de manière séquentielle dans le même cycle de test.