TLDR
- Un test de non-régression vérifie qu'une modification n'a pas altéré des fonctionnalités qui fonctionnaient auparavant.
- Une régression touche un comportement qui fonctionnait avant une modification et ne fonctionne plus après.
- Non-régression, retest, smoke test et test fonctionnel ne répondent pas à la même question.
- Quatre stratégies déterminent les tests à relancer : campagne complète, sélection ciblée, priorisation ou analyse du périmètre impacté.
- Retrouvez leurs différences dans le tableau comparatif.
Les tests de non-régression (TNR) soulèvent une question récurrente dans les échanges entre développeurs et testeurs : qu'est-ce qui les distingue réellement des autres tests ? Le terme test de régression ajoute à la confusion. Les deux termes désignent pourtant la même pratique.
Le flou n'est pas qu'une affaire de mots. Il se retrouve dans le choix des scénarios, la répartition des responsabilités et la maintenance. Quand personne ne sait quel risque couvre chaque test, les rapports finissent par perdre leur valeur.
L'exemple d'un panier e-commerce montre ce qu'une campagne détecte, et surtout ce qu'elle laisse passer. Reste à distinguer les TNR du retest et du smoke test, à décider quand les lancer, puis à comprendre pourquoi leurs résultats finissent parfois par ne plus convaincre personne.
Qu'est-ce qu'un test de non-régression ?
Un test de non-régression consiste à relancer des tests existants après une modification pour vérifier que ce qui fonctionnait avant fonctionne toujours.
En anglais : regression testing.
Régression ou non-régression : quelle différence ?
Les deux expressions désignent la même pratique. « Test de régression », terme utilisé par l'ISTQB et issu de l'anglais regression test, nomme le défaut que l'on cherche à détecter. « Test de non-régression », plus courant en France, désigne le résultat attendu : l'absence de régression. Même test, deux points de vue.
Une régression est un retour en arrière : une fonctionnalité qui marchait cesse de fonctionner après un changement du logiciel. C'est un comportement auparavant correct qu'une modification a dégradé.
La non-régression n'est donc pas un type de test à part entière. Un test unitaire, un test de bout en bout (E2E) ou un test d'API devient un test de non-régression lorsqu'on le relance pour vérifier qu'une évolution n'a pas cassé l'existant.
Cette notion n'a rien à voir avec la régression linéaire ou logistique en statistiques, ni avec le principe de non-régression du droit de l'environnement.
Pourquoi les régressions arrivent
Une modification casse parfois une fonctionnalité sans toucher à son code. Cinq causes reviennent :
- Le couplage : deux fonctionnalités partagent un composant. Modifier le calcul des remises peut perturber celui des frais de livraison.
- L'état partagé : plusieurs parcours utilisent les mêmes données. Un panier et un module de paiement écrivent dans le même champ.
- Les contrats implicites : un composant dépend d'un comportement jamais documenté. Une API change l'ordre de ses résultats et perturbe le service qui les exploite.
- La dérive de configuration : le code reste identique, mais l'environnement change. Un nouveau réglage de cache provoque l'affichage de données périmées.
- Les montées de version des dépendances : une bibliothèque modifie son comportement par défaut. Une mise à jour change la validation des dates dans un formulaire.
Ces dépendances et leurs effets ne sont pas nécessairement visibles dans la revue du code modifié. C'est précisément pourquoi les équipes relancent des tests : examiner le diff ne suffit pas à prévoir toutes les conséquences d'un changement.
Un exemple concret de test de non-régression
Un site e-commerce accepte déjà les codes promotionnels. L'équipe ajoute le paiement par carte-cadeau. Les tests exécutés après cette modification donnent les résultats suivants.
Le test de non-régression existant est passé. Pourtant, un défaut subsiste dans le panier : la combinaison des deux moyens de réduction produit un montant incorrect.
Le problème vient de l'état partagé : les deux fonctionnalités modifient le même champ du panier. Aucun scénario ne vérifiait leur interaction.
Tous les tests existants sont au vert, pourtant le calcul du panier est faux. Compter les tests réussis ne dit rien des combinaisons oubliées.
Non-régression, retest, smoke test, test fonctionnel : les différences
Vérifier l'existant, confirmer une correction, contrôler une nouveauté : ces opérations ne poursuivent pas le même objectif.
Smoke test ou non-régression ? Le premier demande « est-ce que ça démarre ? », le second « est-ce que ça marche encore ? ». Un smoke test prend généralement quelques minutes ; une campagne complète de non-régression peut durer plusieurs heures.
Retest ou non-régression ? Après un correctif, le retest vérifie le défaut corrigé. La non-régression contrôle les autres comportements susceptibles d'avoir été affectés. Les deux sont complémentaires.
Test fonctionnel ou non-régression ? Ces notions ne s'excluent pas. Un test fonctionnel peut être relancé après une modification pour rechercher une régression.
La non-régression n'est pas une catégorie de test distincte : elle décrit le moment et l'intention du contrôle.
Quand lancer les tests de non-régression ?
Les tests de non-régression se lancent après toute évolution susceptible de modifier le comportement d'un logiciel, même lorsque les fonctionnalités concernées n'ont pas été directement modifiées.
Six événements peuvent déclencher une campagne :
- Une correction de défaut.
- L'ajout d'une nouvelle fonctionnalité.
- Un refactoring du code.
- Une montée de version d'une dépendance.
- Un changement de configuration ou d'environnement.
- Une fusion de branche (merge).
Dans votre pipeline CI/CD, la fréquence et le périmètre des tests dépendent du moment :
- À chaque commit : les tests unitaires et un sous-ensemble de smoke tests.
- À chaque merge : les tests couvrant le périmètre impacté.
- Avant la mise en production : la campagne complète de non-régression.
- La nuit : les tests trop longs pour être exécutés dans le pipeline de livraison.
Cette cadence s'inscrit dans les tests continus dans un pipeline CI/CD sans imposer l'exécution de toute la campagne après chaque modification.
En Agile, la non-régression n'est pas une phase réservée à la fin du sprint : elle fait partie de la Definition of Done. La fréquence des livraisons fixe la durée maximale acceptable des tests : une équipe qui déploie trois fois par jour ne peut pas attendre six heures pour valider chaque mise en production, quelle que soit la couverture de sa campagne.
Qui fait les tests de non-régression ?
La responsabilité des tests de non-régression dépend du niveau de test et des fonctionnalités concernées :
- Les développeurs écrivent les tests unitaires et les tests d'intégration.
- Les équipes QA couvrent le comportement du système et les parcours utilisateurs.
- La MOA, les product owners et les équipes métier définissent et valident les scénarios de recette.
Qui exécute les TNR ? Lorsque la campagne est automatisée, c'est le pipeline CI/CD qui déclenche les tests. Si l'équipe doit encore désigner la personne chargée de lancer la campagne, son exécution repose au moins en partie sur des interventions manuelles.
Les tests de non-régression font-ils partie de la recette ? Pas exactement. La recette vérifie qu'une fonctionnalité répond aux attentes métier ; la non-régression contrôle que les comportements existants fonctionnent toujours. En pratique, un cahier de recette peut inclure des TNR sur les parcours critiques, mais les critères de validation restent distincts.
Quelle part de la campagne relancer ?
Faut-il relancer tous les tests de non-régression après chaque modification ? Pas nécessairement. Le bon périmètre dépend du risque associé au changement et du temps disponible avant la livraison.
Ce choix se réévalue à chaque changement, selon sa nature et le risque de régression.
Pourquoi on ne fait plus confiance à sa campagne de TNR
Une campagne de tests de non-régression ne devient pas inutile du jour au lendemain. Les exécutions continuent, les rapports s'accumulent, puis les équipes cessent de croire les résultats. Voici comment la confiance se dégrade.
1. Les tests instables (flaky tests)
Un test échoue une fois sur cinq alors que le code n'a pas changé. L'équipe commence par le relancer, puis le fait systématiquement, jusqu'à ne plus examiner ses échecs. Un seul test instable peut suffire à jeter le doute sur tout le rapport.
2. La durée d'exécution qui augmente
À chaque version, de nouveaux tests s'ajoutent sans que les anciens soient réévalués. La campagne finit par dépasser la fenêtre de livraison. On cesse alors de l'exécuter avant chaque mise en production pour la lancer uniquement « quand on a le temps ».
3. Les tests désactivés « temporairement »
Un test échoue, bloque le pipeline et se retrouve désactivé en attendant une correction. Quelques sprints plus tard, il l'est toujours. Le nombre de tests ignorés (skipped) et leur ancienneté en disent alors davantage que le nombre total de tests.
4. La maintenance invisible
Une modification d'interface casse des tests censés vérifier des règles métier, simplement parce qu'ils dépendent de sélecteurs ou de parcours trop fragiles. L'équipe passe du temps à réparer une suite de tests cassée, sans avoir prévu cette charge. Plus la campagne grossit, plus cette maintenance pèse. Les tests auto-réparants de Thunders peuvent limiter une partie de ces interventions, mais pas les supprimer. Il faut aussi mesurer ce que coûte vraiment cette maintenance.
5. La couverture de façade
La campagne compte 2 000 tests, mais la majorité porte sur des écrans secondaires. Le parcours de paiement, lui, reste insuffisamment couvert. Le nombre de tests augmente sans réduire le risque sur les fonctionnalités les plus critiques.
Une campagne à laquelle l'équipe ne fait plus confiance peut devenir pire qu'une absence de campagne : elle consomme du temps et des ressources tout en donnant une fausse impression de sécurité.
Cinq signaux d'alerte sur une campagne de non-régression
Cinq indicateurs signalent cette dégradation :
- Le taux de tests instables dépasse quelques pour cent : mesurer la part des exécutions dont le résultat change sans modification du code.
- La campagne complète ne tourne plus avant chaque mise en production : comparer sa durée réelle à la fenêtre de livraison disponible.
- Des tests restent désactivés plus d'un sprint : suivre le nombre de tests ignorés (skipped) et l'ancienneté du plus ancien.
- Des défauts atteignent la production sur des parcours supposés couverts : identifier les incidents pour lesquels un test existait et avait pourtant réussi.
- Personne ne sait précisément ce que couvre la campagne : vérifier la traçabilité entre exigences, parcours critiques et cas de test.
Pour interpréter ces signaux, l'analyse des échecs aide à distinguer les défauts réels des résultats instables.
Mieux vaut 300 tests fiables sur les parcours qui comptent que 3 000 tests qu'il faut relancer trois fois avant de les croire.
Tests de non-régression manuels ou automatisés ?
Les tests de non-régression sont particulièrement adaptés à l'automatisation : ils vérifient des comportements connus et doivent être relancés après chaque évolution du logiciel.
L'automatisation est surtout pertinente pour les scénarios répétitifs, déterministes et fréquents. Un test qui contrôle le calcul d'un total de commande ou la réponse d'une API peut s'exécuter à chaque version, sans intervention humaine. C'est pourquoi la non-régression figure parmi les premiers candidats à l'automatisation des tests.
Les tests manuels restent utiles pour l'exploration de comportements imprévus, l'appréciation visuelle ou ergonomique et les parcours dont l'interface change chaque semaine. Dans ces situations, maintenir un script automatisé peut coûter davantage que réaliser le contrôle manuellement.
Peut-on automatiser 100 % des tests de non-régression ? Non, et ce n'est pas l'objectif. L'objectif est d'élargir la couverture sans augmenter proportionnellement le volume de vérifications manuelles.
Quelles solutions pour automatiser les tests de non-régression ?
Pour choisir une solution, la vraie question n’est pas de savoir combien de tests elle permet d’écrire. C’est de savoir qui pourra encore les maintenir dans deux ans. Trois familles d’outils coexistent.
Les frameworks open source : Selenium, Playwright, Cypress. Gratuits et très répandus, ils exécutent des scripts écrits par des développeurs. Ils donnent un contrôle total, mais chaque test est du code à maintenir. C’est là que naît la maintenance invisible décrite plus haut.
Les plateformes d’automatisation commerciales, comme Katalon ou Tricentis Tosca. Elles ajoutent l’enregistrement de parcours, des rapports et des composants réutilisables, pour les équipes qui ne veulent pas tout coder. La plupart dépendent encore de sélecteurs ou de modèles d’objets à mettre à jour à chaque évolution de l’interface.
Les plateformes de test pilotées par l’IA, comme Thunders. Thunders automatise les tests de non-régression en langage naturel sur les applications web, mobiles, les API et SAP. Un scénario s’écrit comme une consigne : « ajoute un code promo et une carte-cadeau au panier, vérifie que la remise n’est appliquée qu’une fois ». Des agents IA l’exécutent ensuite en interprétant l’intention à l’écran, sans générer de script. Cette approche répond à trois des dérives décrites plus haut :
- La maintenance. Les tests reposent sur l’intention, pas sur des sélecteurs, et se réparent quand l’interface change.
- L’instabilité. L’analyse des échecs sépare les défauts réels des résultats instables et crée le ticket Jira avec les étapes de reproduction.
- La durée. Les tests tournent en parallèle sur Chrome, Firefox, Safari et Edge, dans le pipeline (GitHub Actions, Jenkins, CircleCI, Azure DevOps).
Les équipes métier peuvent aussi écrire elles-mêmes leurs scénarios de recette, et les tests Selenium, Cypress ou Playwright existants peuvent être convertis.
Comment faire des tests de non-régression qui tiennent dans la durée
Pour construire une campagne de tests de non-régression fiable, quatre étapes aident à cibler les scénarios utiles :
- Partir des parcours réels, comme la commande ou le paiement, plutôt que d'établir une liste de tests écran par écran.
- Automatiser en priorité les scénarios les plus risqués : ceux qui échouent souvent ou dont la défaillance coûte le plus cher.
- Intégrer les tests au pipeline CI/CD dès le départ, sans attendre que la campagne soit « complète ».
- Prévoir un budget de maintenance dès le départ : une campagne n'est utile que si ses tests restent fiables au fil des versions.
Une campagne utile fournit un résultat crédible avant chaque livraison. Le guide explique comment automatiser votre campagne de non-régression.
