Qu'est-ce que le regression testing ?

Qu'est-ce que le regression testing ?

Le regression testing est la pratique de relancer votre test suite existante contre chaque changement de code pour confirmer que rien qui marchait avant n'est cassé. Le mot "régression" signifie un pas en arrière : une feature qui passait hier et échoue aujourd'hui. Les regression tests attrapent ces pas en arrière avant qu'ils n'atteignent les utilisateurs.

Chaque bug livré devient la graine d'un regression test. Le fix atterrit avec un nouveau test qui reproduit le bug, et dès lors la suite asserte que ce bug ne revient jamais. Au fil des années, la regression suite devient la mémoire exécutable de chaque défaut que l'équipe a payé.

Regression testing vs smoke testing vs QA complet

Trois couches, scope croissant :

• Smoke testing : secondes. Le build est-il monté ? 5-15 checks critical-path. Gate uniquement.
• Regression testing : minutes à une heure. Quelque chose qui marchait est-il cassé ? Centaines à milliers de tests couvrant chaque feature livrée.
• QA complet / acceptance : heures, souvent manuel. Chaque flow respecte-t-il la spec pour le release à venir ? Inclut checks exploratoires + manuels.

Regression s'assoit au milieu et est le type de test dans lequel la plupart des équipes investissent le plus, parce qu'il est automatisable, répétable et gate chaque merge.

Fonctionnelle vs visuelle vs régression de performance

• Régression fonctionnelle. Tests unit, integration, end-to-end. "Ajouter au panier ajoute encore un item." La majorité de toute regression suite.
• Régression visuelle. Comparaison de screenshot ; les diffs pixels marquent les changements CSS ou layout non intentionnés. Outils : Percy, Chromatic, toHaveScreenshot() de Playwright.
• Régression de performance. p95 latency à la charge attendue ne devrait pas se dégrader entre releases. Lancez un load test contre la baseline et le nouveau build ; assertez que latency, throughput et error rate n'ont pas empiré. Facile à sauter et la première chose à mordre en production.

Quand exécuter des regression tests

1. À chaque pull request. Avant le merge. Le PR ne merge pas sauf si regression passe.
2. À chaque commit sur main. Attrape les issues d'intégration de PRs concurrents qui passaient individuellement.
3. Pre-release. Un run complet de regression contre le release candidate avant le deploy. Souvent plus lent / plus approfondi que le run per-PR.
4. Nocturne. Les parties chères de la suite (tests browser, régression de performance, intégration longue durée) tournent la nuit sans bloquer le flow développeur.

Pratiques clés de regression testing

1. Chaque bug fixé obtient un test. Le fix et le regression test atterrissent dans le même commit. Sans exception.
2. Les tests sont déterministes. Les regression tests flaky entraînent l'équipe à ignorer les échecs. Éliminez les suppositions de timing, mockez les services externes, fixez ou supprimez les flakes en une semaine.
3. Les tests tournent vite. Un run complet de regression bloquant les PR devrait finir en moins de 10 minutes ; sinon les développeurs changent de contexte et perdent leur flow. Parallélisez.
4. La performance fait partie de regression. Un load test dans CI/CD avec assertions sur p95 + error rate attrape le drift lent que les tests fonctionnels manquent.

Comment exécuter régression de performance

Prenez le même script que vous utilisez pour load testing et exécutez-le contre la fois le build baseline et le nouveau build à charge identique. Comparez p95, p99, throughput et error rate.

Dans JMeter, sauvegardez l'output JTL et diffez les métriques agrégées. Dans k6, utilisez thresholds dans le script : http_req_duration: ['p(95)<800'] casse le build quand p95 dépasse 800 ms. Les thresholds échoués fixent l'exit code, donc CI attrape la régression automatiquement.

Pour une charge multi-région contre un vrai edge CDN, exécutez depuis LoadFocus. La régression de performance qui a tourné depuis une seule machine locale manque les régressions dans les chemins géo-distribués (DNS, edge cache, failover régional de DB).

Si votre équipe n'a pas le temps de construire la régression de performance dans CI, LoadFocus propose des load testing services où des ingénieurs conçoivent les scénarios de régression, les câblent dans votre pipeline et triagent les échecs contre des baselines historiques.