Tests de non-régression (TNR) : définition, méthode et automatisation

Un correctif de bug qui en réintroduit trois autres, une mise à jour qui casse le paiement pendant deux jours sans que personne ne le remarque : voilà ce que les tests de non-régression servent à éviter. Ce guide donne une définition claire, la méthode pour construire une suite fiable, et la ligne de partage entre ce qu'on automatise et ce qu'on garde à la main.

1. Qu'est-ce qu'un test de non-régression ?

Un test de non-régression (TNR) vérifie qu'une modification du code n'a pas cassé une fonctionnalité qui marchait auparavant. On l'appelle « non-régression » parce que son but est de prouver l'absence de régression, c'est-à-dire d'un retour en arrière de la qualité.

Une régression, concrètement, c'est un effet de bord : vous corrigez un bug sur la page panier, et sans le vouloir vous cassez le code promo. Vous ajoutez une nouvelle méthode de paiement, et l'ancienne cesse de fonctionner. Le changement était correct en apparence, mais il a touché une partie de l'application que vous ne surveilliez pas. Le TNR est le filet qui attrape ces effets de bord avant vos utilisateurs.

2. TNR et tests de régression : le vocabulaire, sans piège

Beaucoup s'emmêlent entre « test de régression » et « test de non-régression ». En pratique, les deux désignent la même activité. La nuance est une question d'angle : « test de régression » insiste sur le fait de chercher les régressions, « test de non-régression » sur l'objectif de démontrer qu'il n'y en a pas. En France, l'usage et l'acronyme TNR dominent largement. Ne perdez pas de temps sur ce faux débat.

En revanche, il est utile de situer le TNR parmi les autres familles de tests :

• Tests unitaires : vérifient une fonction isolée. Rapides, nombreux, écrits par les développeurs.
• Tests d'intégration : vérifient que plusieurs briques marchent ensemble.
• Tests de bout en bout (E2E) : rejouent un parcours utilisateur complet dans un vrai navigateur.
• Tests de non-régression : ce n'est pas une famille à part, c'est un usage. On fait de la non-régression en rejouant régulièrement un sous-ensemble des tests ci-dessus, généralement les tests E2E des parcours critiques.

Autrement dit, le TNR est moins une technique qu'une discipline : rejouer la couverture existante à chaque changement. C'est ce qui le rend inséparable de l'automatisation.

3. Quand lancer des tests de non-régression

Il y a trois moments clés, du minimum vital au plus mature :

1. Avant chaque mise en production. C'est le minimum. Ne jamais livrer sans rejouer les parcours critiques.
2. À chaque intégration de code, en CI. Chaque fusion de code déclenche la suite. Les régressions sont attrapées en minutes, pas en jours, et par la personne qui les a introduites.
3. En continu sur la production. Certaines régressions ne viennent pas de votre code mais de l'extérieur : un prestataire de paiement qui change son API, un service tiers en panne, un certificat expiré. Seul un rejeu régulier en production les détecte. C'est le rôle du monitoring synthétique, que nous distinguons de la CI dans CI ou monitoring synthétique.

4. Manuel ou automatisé ?

Un TNR manuel existe : une personne suit une liste de vérifications à la main avant chaque livraison. Ça marche au début, puis ça devient intenable. Chaque nouvelle fonctionnalité allonge la liste, la vérification prend des heures, et la lassitude fait sauter des étapes. La non-régression manuelle ne passe pas à l'échelle.

L'automatisation est la réponse naturelle, parce que le propre d'un TNR est d'être répétitif et identique d'une fois sur l'autre : exactement ce qu'une machine fait mieux qu'un humain. On automatise ce qui est stable et rejoué souvent, on garde en manuel ce qui demande du jugement.

5. Construire une suite de TNR fiable

Une bonne suite de non-régression ne cherche pas à tout couvrir. Elle couvre le bon 20 % qui protège 80 % de la valeur. La méthode :

1. Listez vos parcours critiques. Ceux dont la panne coûte de l'argent ou de la réputation : connexion, paiement, création de compte, recherche, tunnel de commande. Notre article les parcours critiques d'un e-commerce donne une liste de départ.
2. Écrivez un scénario par parcours, du point de vue de l'utilisateur. Le test doit refléter ce que fait une vraie personne, pas la structure interne du code.
3. Rendez vos tests robustes aux changements cosmétiques. Un test qui casse dès qu'on déplace un bouton n'est pas un TNR, c'est une nuisance. Ancrez vos sélecteurs sur des identifiants stables plutôt que sur la mise en page. C'est tout l'objet des attributs data-testid.
4. Isolez les données de test. Un TNR doit pouvoir tourner cent fois sans polluer votre production ni dépendre d'un état laissé par la fois précédente.
5. Branchez l'alerte sur la bonne personne. Un test qui échoue sans prévenir personne ne sert à rien. La sortie d'un TNR, c'est une notification actionnable.

6. Les pièges qui tuent une suite de TNR

La plupart des initiatives de non-régression ne meurent pas d'un manque de tests, mais d'un excès de bruit. Les trois pièges à connaître :

Les tests instables (flaky)

Un test flaky passe ou échoue au hasard, sans que rien n'ait changé. Quelques tests instables suffisent à décrédibiliser toute la suite : l'équipe finit par ignorer les alertes, et le jour où une vraie régression passe, personne ne regarde. Un test instable doit être réparé ou retiré, jamais toléré.

La maintenance sous-estimée

Une suite de tests est un actif vivant. Chaque évolution du produit demande de mettre à jour les scénarios concernés. Sans temps dédié à cette maintenance, la suite se désynchronise du produit en quelques mois et devient un cimetière. C'est le poste de coût le plus sous-évalué de toute stratégie de tests.

La couverture pour la couverture

Viser un pourcentage de couverture pousse à écrire des tests sans valeur juste pour faire du chiffre. Mieux vaut dix scénarios critiques impeccablement maintenus que deux cents tests fragiles que personne ne lit.

7. Internaliser ou externaliser ses TNR

Les tests de non-régression sont précisément le type de tâche qu'on externalise le plus volontiers, pour une raison simple : ils sont répétitifs, à faible valeur ajoutée créative, mais coûteux à maintenir. Beaucoup d'équipes gardent les tests unitaires et l'exploratoire en interne, et confient la non-régression des parcours critiques à un service spécialisé.

Si vous vous posez la question du modèle (garder la main, plateforme en self-service, ou service managé qui écrit et maintient à votre place), nous l'avons traitée en détail dans le guide de l'externalisation des tests automatisés. C'est le prolongement naturel de cet article.

8. FAQ

Quelle est la différence entre test de régression et test de non-régression ?

En pratique, aucune : les deux désignent la même activité, vérifier qu'une modification n'a rien cassé. « Régression » met l'accent sur ce qu'on cherche, « non-régression » sur ce qu'on veut prouver. Les équipes françaises emploient majoritairement TNR.

Faut-il automatiser tous les tests de non-régression ?

Non. On automatise en priorité les parcours stables, critiques et rejoués souvent. Ce qui change en permanence ou demande un jugement humain reste plus efficace en manuel ou en exploratoire.

À quelle fréquence lancer les TNR ?

Au minimum avant chaque mise en production. Les équipes matures les lancent à chaque intégration de code en CI, puis en continu sur la production pour attraper aussi les régressions dues aux dépendances externes.

Combien de temps pour mettre en place une suite de TNR ?

Pour une dizaine de parcours critiques, comptez de quelques jours à deux semaines selon la complexité et la stabilité de l'interface. L'essentiel du travail n'est pas l'écriture initiale, c'est la maintenance dans la durée.