Qu'est-ce qu'un test de régression ? Vérifier que le correctif n'a rien cassé d'autre

Le test de régression consiste à vérifier que ce qui marchait marche encore, après un changement. Pas le changement lui-même - celui-là, on le teste en l’écrivant - mais tout ce qui l’entoure, que personne n’a touché et dont personne n’attendait qu’il soit affecté.

Le nom dit tout. Une régression est un pas en arrière : une fonctionnalité qui marchait dans la version précédente et qui ne marche plus dans celle-ci. Ces tests existent parce que le logiciel est relié par des chemins que personne ne garde en tête, et le code promotionnel réparé mardi partage une fonction avec le calcul de TVA que personne n’a regardé depuis mars.

Pourquoi c’est le travail de quelqu’un

Chaque changement a un rayon d’action plus large que son diff. Une fonction partagée, une colonne de base de données lue à six endroits, une règle CSS qui s’avère porteuse pour une page que son auteur n’avait jamais ouverte.

L’échec que cela évite est précis et coûteux : une version qui corrige un bug signalé et en introduit deux que personne n’a signalés. Ceux-là coûtent bien plus cher que le premier, parce que personne ne les cherche. Le bug signalé avait quelqu’un qui attendait le correctif ; les nouveaux sont découverts par les clients, quelques jours plus tard, sans aucune idée de ce qui a changé.

Ce qu’il faut vraiment retester

Vous ne pouvez pas tout retester à chaque changement, et les équipes qui essaient finissent avec une suite si lente qu’on la saute. Le test de régression est un problème de sélection, et la sélection se fait par le risque.

À retester sur presque n’importe quel changement :

• Les chemins qui rapportent de l’argent. Inscription, connexion, commande, paiement. Tout le reste peut attendre lundi ; pas ceux-là.
• Ce que le changement touche réellement, plus tout ce qui partage avec lui une fonction, une table ou un gabarit.
• Tout ce qui a déjà cassé. Un défaut revenu une fois reviendra encore, et un bug qui a régressé est le meilleur argument pour un test permanent.
• Les intégrations que vous ne maîtrisez pas. Tout ce qui atteint un autre service tombe pour des raisons qui n’ont rien à voir avec votre version.

Pas la peine à chaque fois : les écrans de réglages rarement ouverts, les outils d’administration à deux utilisateurs, tout ce dont la panne serait remarquée et signalée sans dommage.

Où le smoke test s’arrête et où celui-ci commence

Ils sont posés à des moments différents et répondent à des questions différentes.

Smoke test

Cette build mérite-t-elle d'être testée ? Cinq vérifications, quelques minutes, lancé en premier, à chaque build

Test de régression

Quelque chose qui marchait a-t-il cessé de marcher ? Des centaines de vérifications, plus long, lancé une fois que la build a fait ses preuves

Lancer une suite de régression contre une build incapable de connecter un utilisateur, c’est passer une heure à le prouver de quatre cents façons. Le smoke test passe en premier précisément pour cela.

À la main ou automatisé

L’automatisation est la réponse évidente, et la réponse incomplète.

Automatisez ce qui est stable, précieux et ennuyeux : les chemins de l’argent, les contrats d’API, les calculs à entrées connues et réponses connues. Ceux-là valent la peine d’être écrits une fois et lancés pour toujours, et ce sont les tests qui attrapent une régression à trois heures du matin sans que personne ne regarde.

Gardez une personne pour ce qu’un script ne sait pas juger. Si la mise en page est fausse et pas seulement différente. Si un message d’erreur a du sens. Si le parcours donne encore l’impression de fonctionner. Une comparaison de captures vous dira que onze pixels ont bougé ; elle ne vous dira pas que le bouton est passé sous la ligne de flottaison sur l’ordinateur portable le plus répandu chez vos utilisateurs.

La plupart des équipes finissent avec une suite automatisée pour les chemins qui ne doivent pas casser et une courte passe manuelle sur les zones que la version a touchées.

Comment une suite se dégrade

De trois façons, toutes courantes, et chacune finit par une suite qu’on ignore.

Elle devient lente. Une suite de quatre-vingt-dix minutes tourne la nuit plutôt qu’à chaque changement, et une régression trouvée le lendemain matin a déjà servi de fondation.

Elle devient instable. Un test qui échoue une fois sur dix apprend à tout le monde à le relancer, et l’habitude de relancer ne se distingue pas de l’absence de test. Une chose vraiment cassée se cache dans le bruit de celles qui sont seulement peu fiables.

Elle ne fait que grandir. On ajoute des tests pour chaque défaut et on n’en retire aucun, jusqu’à ce que la moitié de la suite couvre un comportement que le produit n’a plus. Supprimer des tests fait partie de leur entretien.

Quand une régression apparaît

Un test de régression en échec est un rapport de bug qui reste à écrire, et il part avec plus d’informations que la plupart des rapports n’en reçoivent jamais : vous savez que cela marchait avant, et souvent dans quelle version exactement cela a cessé.

Dites-le. « Marchait en 4.2.0, échoue en 4.3.0 » transforme une enquête en diff. C’est la phrase la plus utile d’un rapport de régression et celle qu’on oublie le plus souvent, parce que la personne qui écrit suppose que tout le monde le sait.

Pour une régression rencontrée à la main plutôt qu’attrapée par la suite, c’est le contexte qui manque en général.

Le reste de ce dont un bon rapport a besoin se trouve dans le guide du rapport de bug, et son modèle comporte une ligne pour la version qui marchait.

En bref

Le test de régression demande si le changement que vous avez fait en a cassé un que vous n’avez pas fait. Choisissez ce que vous retestez par le risque et non par l’ambition, mettez les chemins de l’argent sous automatisation, gardez une personne pour les jugements qu’un script ne peut pas rendre, et supprimez des tests aussi volontiers que vous en ajoutez. Quand vous en trouvez une, nommez la version où cela marchait encore.