Glossaire · Fondamentaux du test
Test de régression
En anglais : Regression testing
Également appelé : test de non-régression, tests de non-régression, tests de régression, regression test
Définition
Relancer les tests existants après une modification pour confirmer que ce qui fonctionnait fonctionne toujours et que le correctif ou la fonctionnalité n'a rien cassé.
Le test de régression (souvent appelé test de non-régression en France) vérifie qu’une modification n’a pas cassé quelque chose qui fonctionnait auparavant. Une « régression » est une fonctionnalité qui marchait dans un build précédent et ne marche plus. On la détecte en relançant les tests du comportement existant après chaque correction de bug, nouvelle fonctionnalité, refactoring, montée de version d’une dépendance ou changement de configuration.
Exemple
Une équipe ajoute au tunnel de commande une option « payer avec une carte cadeau ». La nouvelle fonctionnalité a ses propres tests. Le test de régression pose une autre question : les paiements par carte bancaire, les codes de réduction, le calcul des taxes et les e-mails de commande se comportent-ils toujours exactement comme avant ? Une modification du module de calcul des prix, partagé par tous, pourrait facilement casser n’importe lequel d’entre eux sans toucher au nouveau chemin de code.
Choisir quoi exécuter
Lancer tous les tests à chaque commit est la stratégie la plus simple et, avec une suite automatisée rapide, c’est souvent la bonne. Quand la suite complète est trop lente ou en partie manuelle, les équipes font une sélection :
- Par risque. Les parcours critiques pour le métier (inscription, paiement, export de données) sont toujours exécutés.
- Par impact. Les zones qui partagent du code, des données ou des services avec la modification.
- Par historique. Les modules qui ont déjà régressé ont tendance à régresser à nouveau.
Un découpage courant : un sous-ensemble de régression rapide sur chaque pull request, et la suite complète la nuit ou avant une release.
Pourquoi c’est la première chose que les équipes automatisent
Les tests de régression rejouent encore et encore les mêmes étapes avec les mêmes résultats attendus, ce pour quoi l’automatisation est précisément faite. La régression manuelle grossit à chaque release alors que le temps disponible, lui, ne grossit pas : c’est donc elle qu’on sacrifie en premier. Une suite de régression automatisée dans la CI transforme « avons-nous cassé quelque chose ? » d’une semaine de vérifications manuelles en un simple résultat de pipeline.
Erreurs fréquentes
- Considérer la suite comme un fichier où l’on ne fait qu’ajouter. Les tests obsolètes et en double ralentissent chaque exécution. Relisez et élaguez.
- Tolérer les tests flaky. Si l’on relance systématiquement les échecs jusqu’à obtenir du vert, les vraies régressions disparaissent elles aussi à force de relances.
- Ne tester que par l’interface. L’essentiel de la couverture de régression est moins coûteux et plus stable au niveau unitaire et API.