Qu'est-ce que le regression testing ?

Qu'est-ce que le regression testing ?

Le regression testing (test de non-régression) consiste à relancer les tests existants après une modification pour confirmer que ce qui fonctionnait fonctionne toujours. Une régression est un pas en arrière : une fonction qui passait hier échoue aujourd'hui. Corriger un bug, ajouter une fonctionnalité, refactoriser, mettre à jour une dépendance ou changer la configuration peut en provoquer une, et les tests de non-régression attrapent ces casses involontaires avant qu'elles n'atteignent les utilisateurs.

Une suite de non-régression mature devient la mémoire exécutable du produit : chaque défaut livré laisse un test qui le reproduit, si bien que le même bug ne revient pas en silence. Elle complète les tests de charge dans le pipeline : la non-régression fonctionnelle vérifie l'exactitude, celle de performance la vitesse.

Pourquoi les régressions surviennent

• Code partagé et effets de bord. Une fonction utilitaire ou une colonne de base est utilisée par plus de modules que prévu, et une modification « locale » se propage.
• Corrections incomplètes. Le correctif résout le cas signalé mais casse un cas limite voisin ou réintroduit un ancien défaut.
• Refactorisation. L'intention est de garder le même comportement, mais des différences subtiles s'invitent dans l'ordre, les valeurs nulles et les chemins d'erreur.
• Dépendances et environnement. Mettre à jour une bibliothèque ou un runtime peut changer des valeurs par défaut, retirer des API ou modifier les performances.
• Conflits d'intégration. Deux changements qui passent séparément peuvent échouer une fois combinés sur la branche principale.

Ce que couvre le regression testing

Ce n'est pas une technique unique mais un objectif : tout test peut jouer ce rôle dès qu'il protège un comportement déjà vérifié. Une suite couvre typiquement :

• Les parcours utilisateur essentiels : inscription, connexion, paiement, recherche.
• Les règles métier : prix, taxes, permissions, remises.
• Les reproductions de bugs pour chaque défaut déjà corrigé.
• Les intégrations et API, où un changement de contrat casse les consommateurs externes.
• Le comportement non fonctionnel : temps de réponse, débit et taux d'erreurs sous charge.

Types de regression testing

• Non-régression unitaire. Tests rapides et isolés d'une fonction ; la base de la plupart des suites.
• Non-régression d'intégration. Vérifie que modules, services et base de données coopèrent toujours.
• Non-régression système et de bout en bout. Parcourt toute l'application, souvent via le navigateur, pour valider des parcours complets.
• Non-régression visuelle. Compare des captures d'écran pour repérer des changements de CSS ou de mise en page non voulus.
• Non-régression de performance. Rejoue un test de charge sur une nouvelle version et compare latence, débit et taux d'erreurs à une référence.

Regression testing et retesting

Le retesting (test de confirmation) rejoue exactement le cas qui échouait pour vérifier que le bug est corrigé. Le regression testing exécute la suite environnante pour vérifier que le correctif n'a rien cassé d'autre. L'un est ciblé, l'autre large et préventif. Les bonnes équipes font les deux après chaque correction.

Quand lancer les tests de non-régression

1. À chaque pull request. Pas de fusion tant que la suite n'est pas verte.
2. À chaque commit sur la branche principale. Cela révèle les problèmes d'intégration entre changements simultanés.
3. Après les correctifs et refactorisations.
4. Avant chaque version. Une passe complète est le dernier verrou avant la production. Un court test de fumée après le déploiement confirme que l'essentiel répond.
5. Selon un calendrier. Les vérifications lentes, comme les tests navigateur et de performance, tournent souvent la nuit.

Stratégies de sélection des tests

• Tout rejouer. L'option la plus sûre tant que la suite reste rapide.
• Non-régression sélective. Seuls les tests qui touchent le code modifié et ses dépendants ; plus rapide, avec un risque si la cartographie est incomplète.
• Non-régression priorisée. Les tests les plus risqués ou les plus souvent en échec passent en premier.

Beaucoup d'équipes combinent : un sous-ensemble sélectif et priorisé à chaque pull request, et la passe complète la nuit et avant la livraison.

Manuel ou automatisé

La non-régression est répétitive par nature, donc le meilleur candidat à l'automatisation. Le manuel reste utile pour l'exploratoire, les fonctionnalités toutes neuves et les jugements d'ergonomie. Règle pratique : automatisez tout ce que vous répéterez.

Les suites de non-régression en CI/CD

La suite vit dans le pipeline de CI/CD : à chaque push, l'application est construite et les tests s'exécutent, et un échec bloque la fusion ou le déploiement. Pour que cela fonctionne, elle doit être assez rapide pour que l'équipe l'attende, déterministe pour qu'un rouge signifie toujours un vrai problème, et parallélisée. Une suite d'une heure ou instable finit par être ignorée.

Tests de non-régression de performance

Les tests fonctionnels confirment que les réponses sont justes, mais ne disent rien de la vitesse : une version peut tout réussir et doubler son temps de réponse. On rejoue donc le même test de charge sur la référence et sur la nouvelle version, et l'on compare p95, p99, débit et taux d'erreurs ; au-delà du seuil convenu, le build échoue.

Avec k6, cela s'écrit avec des seuils comme http_req_duration: ['p(95)<800'] ; un seuil franchi renvoie un code de sortie non nul et la CI détecte la régression toute seule. Lancer le test depuis plusieurs régions peut aussi révéler des régressions sur des chemins répartis géographiquement, comme le DNS, le cache en périphérie et le basculement régional ; les tests de charge LoadFocus s'exécutent depuis plus de 25 régions cloud. La surveillance d'API planifiée (surveillance d'API LoadFocus) prolonge la même idée en production. Pour un exemple concret, lisez détecter une régression de performance avec des tests automatisés ; pour comparer deux exécutions, le guide de comparaison à une référence. Le premier signal est souvent la latence.

Bonnes pratiques et défis

• Chaque bug devient un test. Le correctif et le test qui le reproduit arrivent dans le même changement.
• Traquez les tests instables. Un test qui passe puis échoue sans changement de code apprend à l'équipe à ignorer les échecs.
• Gardez la suite rapide. Parallélisez, sélectionnez à chaque pull request et gardez la suite complète pour la nuit et les livraisons.
• Élaguez. Les tests redondants ou obsolètes ralentissent la suite et masquent les échecs importants.
• Incluez la performance. Des vérifications sous charge attrapent la dérive lente.

Questions fréquentes sur le regression testing

Quel est l'objectif principal du regression testing ?

Confirmer que les changements récents n'ont pas cassé des fonctions qui marchaient, et détecter les effets de bord des correctifs, nouveautés, refactorisations et mises à jour avant qu'ils n'atteignent les utilisateurs.

Quelle différence entre regression testing et retesting ?

Le retesting rejoue le cas qui échouait pour confirmer un correctif. Le regression testing rejoue la suite plus large pour confirmer que le correctif n'a rien cassé d'autre.

À quelle fréquence lancer les tests de non-régression ?

Idéalement à chaque pull request et à chaque commit sur la branche principale via un pipeline CI/CD, plus une passe complète avant chaque version. Les vérifications coûteuses, comme les tests navigateur et de performance, sont souvent planifiées la nuit.

Peut-on tout automatiser ?

La non-régression fonctionnelle, d'intégration, visuelle et de performance est presque toujours automatisée. Le manuel reste utile pour l'exploratoire et les nouveautés sans couverture automatique stable.

Qu'est-ce que la non-régression de performance ?

Rejouer un test de charge sur chaque nouvelle version et comparer latence, débit et taux d'erreurs à une référence. Si cela se dégrade au-delà du seuil, le build échoue.

Pourquoi les tests deviennent-ils instables ?

Souvent à cause d'hypothèses de timing, de données de test partagées et de services externes peu fiables. C'est grave : un test qui échoue au hasard ruine la confiance dans toute la suite.