Qu'est-ce que le smoke testing ? Les cinq minutes qui décident si l'on continue à tester

Un smoke test est un passage court et superficiel sur les choses qu’une build doit savoir faire avant que quiconque y consacre du temps. Est-ce qu’elle démarre. Est-ce que quelqu’un peut se connecter. Est-ce que la page principale s’affiche. Est-ce qu’un enregistrement se sauvegarde. Si l’un de ces points échoue, la build est rejetée et personne ne regarde plus loin, parce que tout ce qui viendrait ensuite reviendrait à tester une build qui ne méritait pas d’être testée.

Il n’est délibérément pas exhaustif. L’exhaustivité, c’est le rôle du reste de la suite, et la lancer contre une build cassée gâche une journée à prouver de quarante façons que la connexion est en panne.

D’où vient le nom

Du matériel, et l’histoire est littérale. Vous assemblez une carte, vous la mettez sous tension et vous guettez la fumée. S’il y a de la fumée, inutile de mesurer quoi que ce soit : la panne est grossière et immédiate, et la carte repart. Les plombiers emploient la même expression pour envoyer de la fumée dans les canalisations et trouver les fuites avant de refermer les murs.

Le logiciel a emprunté le terme pour la même raison. Une build incapable de connecter un utilisateur a fait de la fumée, et la bonne réaction est de s’arrêter.

Ce qu’un smoke test n’est pas

Trois termes sont employés indifféremment dans les mêlées quotidiennes et ce sont trois choses différentes.

Smoke test

Cette build mérite-t-elle d'être testée ? Large et superficiel, lancé en premier, à chaque build

Test de régression

Quelque chose qui marchait a-t-il cessé de marcher ? Profond et lent, lancé quand il y a du temps

Un test de cohérence est le troisième : une vérification étroite qu’un correctif précis fonctionne vraiment, lancée après l’intégration d’un changement plutôt qu’avant le début des tests. Le smoke est large et superficiel ; la cohérence est étroite et superficielle ; la régression est large et profonde.

La différence pratique tient à ce qui se passe en cas d’échec. Un test de régression qui échoue est un bug à déclarer. Un smoke test qui échoue est une décision : cette build s’arrête ici.

Ce qu’on y met

La règle qui garde une suite de smoke utile, c’est que tout ce qu’elle contient doit être une chose dont l’échec rend la suite des tests inutile. La liste est bien plus courte qu’il n’y paraît.

Une suite typique pour une application web :

1. L'application démarre et la page d'accueil renvoie 200
2. Un utilisateur connu peut se connecter
3. La liste principale se charge et affiche des données
4. Un enregistrement peut être créé puis relu
5. Un utilisateur connecté peut se déconnecter

Cinq vérifications, une ou deux minutes, et aucune assertion sur le comportement au-delà de « cela s’est produit ». Pas de cas limites, pas de messages de validation, pas de matrices de permissions. Tout cela appartient à la suite qui tourne ensuite.

Deux modes d’échec méritent d’être nommés, car les deux sont fréquents. Une suite qui grossit jusqu’à quatre-vingts vérifications n’est plus un smoke test, c’est une suite de régression lente sous un mauvais nom, et les gens commencent à la sauter. Une suite qui ne teste que la page d’accueil n’en est pas un non plus : elle passera sur une build où rien d’autre ne fonctionne.

Quand il tourne, et qui le regarde

À chaque build, avant tout le reste, et automatiquement. Un smoke test qu’il faut penser à lancer est un smoke test que personne ne lance l’après-midi où il aurait servi.

L’arrangement habituel est une étape d’intégration continue qui tourne après le déploiement vers un environnement de test et conditionne tout ce qui suit. En cas d’échec, le pipeline s’arrête, la build n’est pas promue, et l’équipe est prévenue immédiatement : quelques minutes après le commit, pendant que la personne qui l’a écrit se souvient encore de ce qu’elle a changé.

Cette immédiateté fait l’essentiel de la valeur. Le même défaut trouvé un jour plus tard coûte à quelqu’un une heure de reconstitution avant même de pouvoir commencer.

Écrire le premier

Partez du chemin le plus court qu’un vrai utilisateur emprunte dans votre produit, et vérifiez seulement que chaque étape aboutit.

• Choisissez cinq choses, pas cinquante. Si vous ne pouvez pas défendre l’idée qu’un échec rend la suite des tests inutile, ce n’est pas une vérification de smoke.
• Utilisez un compte connu et des données connues. Un smoke test qui dépend de ce qui traîne dans la base échouera pour des raisons qui ne concernent pas la build.
• Vérifiez l’existence, pas l’exactitude. « Le total de la facture est 45,00 » appartient ailleurs. « Une page de facture s’est affichée » appartient ici.
• Gardez-le sous les cinq minutes. Dès qu’il coûte davantage, quelqu’un le sortira du chemin critique, et il cessera de conditionner quoi que ce soit.
• Échouez bruyamment. Un pipeline rouge dont personne n’est informé est un pipeline vert avec des étapes en plus.

Quand il échoue

Un smoke test qui échoue n’est pas un rapport de bug. C’est le signal qu’il en faut un, et les deux sont faciles à confondre : « le smoke test 3 a échoué » n’apprend rien à la personne qui le reprend sur ce qui s’est passé.

Ce qu’il lui faut est ce qu’il faut à n’importe quel défaut : ce qui était attendu, ce qui s’est produit à la place, dans quel environnement, avec tout ce que le navigateur ou le runner a enregistré sur le moment. Notre guide pour écrire un rapport de bug qui sera corrigé en est la version longue, et son modèle est un fichier que vous pouvez remettre à qui assure le tri.

Pour une panne rencontrée à la main plutôt qu’attrapée par le pipeline, le contexte est la partie qui manque le plus souvent.

La version courte

Un smoke test répond à une seule question : cette build mérite-t-elle le temps de quelqu’un ? Cinq vérifications, lancées en premier, lancées toujours, et un échec arrête la chaîne au lieu de remplir l’outil de suivi. Tout le reste de ce que vous voulez savoir sur la build est une question qui ne vaut d’être posée qu’une fois celle-ci répondue par oui.