Définition
Les smoke tests, sont par définition de l’ISTQB :
Une suite de tests qui couvre les principales fonctionnalités d’un composant ou d’un système afin de déterminer s’il est opérationnel avant le début des tests planifiés. (SYN : test fumigatoire)
Vous les avez surement déjà croisés et très certainement sous un autre nom car ils sont si importants qu’ils sont le droit à de très nombreux noms selon les équipes. Les termes les plus répandus sont : « test vitaux », « sanity tests », « kit de survie » ou encore « tests de recevabilité ».
Quelle que soit leur dénomination on remarque une sorte d’urgence ou de minium « vital » que ces derniers sont censés assurer.
Le terme de « smoke », fumée en anglais, viendrait de tests de branchements de circuits imprimés. On vérifiait qu’ils ne se mettaient pas à « fumer » pour s’assurer que la mise sous tension n’avait pas grillé le circuit. Dans le cas de la présence de fumée le circuit était « mort » à cause d’un défaut qui lui avait été fatal et il était inutile de faire des tests.
L’objectif des smoke tests
L’idée derrière les tests « vitaux » est la même tout comme le terme de « recevabilité » qui cherche à s’assurer que le logiciel reçu est d’une qualité suffisante pour être recevable. On n’accepte pas un colis qui arrive totalement détruit !
Concrètement les smoke tests reviennent à faire une première vérification de la qualité d’un logiciel livré. Cette première vérification doit assurer l’absence de bugs « critiques ». Par bug « critique » il faut entendre des bugs qui rendent tout le logiciel (ou une partie importante de celui-ci) inutilisable.
Ces tests doivent être exécutés à chaque nouvelle livraison du logiciel et il est donc essentiel que l’exécution de ces derniers soient rapide… sous peine de faire perdre beaucoup de temps voire plus qu’ils n’en font gagner !
Le contenu d’une campagne de smoke tests
Vous l’aurez compris une campagne de smoke test doit répondre à 2 impératifs qui sont une rapidité d’exécution et une utilisabilité des fonctions de bases du logiciel testé.
Il est essentiel pour un testeur d’arriver à déterminer ce « minimum vital » de tests afin de répondre à l’exigence d’utilisabilité du logiciel tout en utilisant aussi peu de temps que possible.
Afin de réussir cela il est essentiel pour le testeur d’être capable d’identifier les fonctionnalités principales du logiciel. Par fonctionnalité principale d’entends ici un nombre assez restreint. Je devrais d’ailleurs parler de Macro-fonctionnalité. Si l’on travail en Agile, ces macro-fonctionnalités pourraient être des « Epics » ou des « Features ».
Lorsque ces fonctionnalités sont identifiées il est alors temps de déterminer s’il y a un intérêt « vital » pour que chacune de ces fonctionnalités soit utilisable. La réponse est dans la quasi-totalité des cas « oui » mais il est toujours intéressant de se poser la question. Pour une application mail mobile, on peut par exemple se poser la question de la pertinence d’avoir un smoke test pour la gestion des options de messagerie ou encore sur la gestion des dossiers.
Lorsque notre sélection de macro-fonctionnalités est faire il est alors primordial d’identifier les parcours clés de chacune de ces fonctionnalités. On peut aussi les parcours « nominaux ». Concrètement c’est les parcours les plus simples et normalement les plus utilisés.
Lorsque que cette sélection est terminée on a alors la base de notre campagne de smoke test.
Attention, je n’ai parlé dans ce paragraphe que des tests systèmes fonctionnels. Il peut être « vital » d’intégrer des tests non fonctionnels et il est important d’intégrer des tests de niveau inférieurs. D’ailleurs, les tests unitaires (généralement les tests composants) et tests d’API (généralement des tests d’intégration) sont des tests très rapides et qui couvrent bien le logiciel ce qui est un atout considérable pour les smoke tests.
La « forme » des smoke tests
Les smokes tests doivent :
- Être exécutés très souvent
- Être exécutés rapidement
Ils sont une cible parfaite pour l’automatisation. Dans l’idéal ils doivent donc être automatisés ou être les premiers tests à être automatiser. De plus, automatiser ces tests permet d’avoir une couverture des méthodes intéressante avec les tests automatisés ce qui est souvent plus intéressant que de n’avoir qu’une ou 2 fonctionnalités très automatisées et les autres non.
Il est souvent très intéressant de pousser plus loin cette automatisation en intégrant l’ensemble des smoke tests (cela inclut les tests des testeurs dont l’article parle principalement et les niveaux de test (au sens ISTQB) inférieur) à la chaîne de CI/CD.
Conclusion
Les smoke tests sont primordiaux ! Ils permettent de gagner beaucoup de temps notamment car ils sont une mise en pratique du tester tôt.
Néanmoins avoir une campagne de smoke test efficace n’est pas un exercice facile. Outre le fait que les tests de composants et d’intégration doivent être inclus, le choix des tests système est un travail qui est plus complexe qu’il en a l’air. Le testeur et les membres de son équipe se doivent d’attacher une attention particulière à la sélection de ces tests ainsi, lorsque c’est possible à leur automatisation… tout en n’oubliant que ces tests ne sont pas figés dans le marbre, que la campagne doit vivre et évoluer avec le logiciel testé.
Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
N’hésitez pas à faire vos propres retours d’expérience en commentaire.
