Un test de régression vérifie qu’un changement n’a pas cassé un parcours déjà accepté, avec des données et des résultats attendus.
Une modification locale peut toucher une règle partagée, un export ou un rôle. Les tests de régression donnent une mémoire au produit. Ils doivent couvrir les décisions importantes et les erreurs fréquentes, pas seulement les écrans faciles.
Choisir les parcours
Commencez par la création, la validation, la facturation, l’export et les intégrations qui bloquent l’activité. Ajoutez les parcours où une erreur expose une donnée ou crée un doublon. Les critères d’acceptation fournissent les résultats attendus.
Utiliser des données stables
Les données de test doivent être reproductibles et séparées de la production. Réinitialisez l’état après chaque scénario ou utilisez des identifiants uniques. Un test qui dépend d’un ancien résultat devient difficile à diagnostiquer.
Tester les rôles
Répétez un parcours avec un utilisateur autorisé, un utilisateur sans droit et un utilisateur appartenant à une autre entreprise. Vérifiez les API, les exports, les fichiers et les tâches planifiées. Masquer un bouton ne remplace pas un contrôle serveur.
Gérer les tests lents
Les tests rapides peuvent s’exécuter à chaque changement. Les tests d’intégration et de restauration peuvent suivre une fréquence différente. Documentez ce qui est couvert avant déploiement et ce qui exige une vérification manuelle.
Lire les échecs
Un échec doit indiquer le parcours, les données, la version et la différence. Ne relancez pas automatiquement un test sans comprendre une instabilité. Les indicateurs d’observabilité aident à distinguer le défaut produit d’une dépendance indisponible.
Sources : Google, tests logiciels, Atlassian, tests de régression.
Inclure les intégrations
Une régression peut apparaître lorsqu’un e-mail, un stockage de fichier ou un fournisseur de paiement change. Utilisez un environnement de test et des réponses simulées pour vérifier le contrat. Gardez aussi un petit nombre de tests avec le service réel lorsque son comportement ne peut pas être simulé correctement.
Vérifiez les délais, les reprises et les doublons. Un test qui réussit seulement lorsque le service répond instantanément ne décrit pas le parcours de production. Les résultats doivent préciser la version du fournisseur et le jeu de données utilisé.
Documenter l’acceptation
Chaque test important doit indiquer son prérequis, l’action et le résultat attendu. Une personne différente doit pouvoir le rejouer sans demander le contexte de l’auteur. Les résultats sauvegardés peuvent contenir des données sensibles ; utilisez des identifiants fictifs et limitez l’accès.
Après une correction, rejouez le scénario qui a échoué et les parcours qui partagent la même règle. Une nouvelle version de la base ou du navigateur peut changer le résultat. Notez l’environnement, la date et les dépendances afin de distinguer une régression d’un problème de test.
Les tests de sécurité doivent aussi vérifier les refus. Une personne sans rôle ne doit pas lire une ressource par une URL directe ou un export. Utilisez deux entreprises fictives et des identifiants proches pour détecter un filtre oublié.
Construire une sélection stable
Une suite de régression ne doit pas contenir uniquement les tests qui ont échoué récemment. Ajoutez les parcours acceptés, les erreurs à fort impact et les conditions qui ont déjà causé un incident. Chaque test doit avoir une raison d’exister et un résultat lisible.
Séparez les tests qui vérifient une règle locale, une interaction entre modules et un parcours complet. Cette séparation accélère le diagnostic. Un test de formulaire ne doit pas échouer uniquement parce qu’un fournisseur de notification est indisponible, sauf si cette dépendance fait partie du comportement vérifié.
Vérifier les données persistantes
Un changement de code peut modifier une migration, un index ou un format de fichier. Testez l’installation sur une base vide et la mise à niveau d’une base représentative. Vérifiez que les anciennes données apparaissent avec les mêmes droits et les mêmes montants.
Les plans de retour arrière doivent être testés séparément. Un test vert sur le nouveau code ne prouve pas qu’une ancienne version peut relire les données après une interruption.
Traiter les tests instables
Un test instable ne doit pas être désactivé sans enquête. Notez la fréquence, l’environnement, les données et le délai. Une horloge, une tâche concurrente ou un service partagé peut expliquer l’échec. Si le test est temporairement isolé, donnez-lui un propriétaire et une date de retour.
Les tests qui dépendent de l’heure doivent utiliser une horloge contrôlée lorsque le temps n’est pas le sujet. Les appels externes doivent utiliser un simulateur ou un environnement de test. Les exemples de fichiers et de messages doivent rester anonymes et versionnés.
Relier la recette au déploiement
Avant une mise en service, indiquez les tests exécutés, les résultats et les exceptions acceptées. Après le déploiement, comparez les erreurs et les temps du parcours avec la version précédente. Une régression peut apparaître seulement avec le volume réel ou un rôle rare.
La suite doit évoluer avec le produit. Retirez les tests d’une fonction supprimée et ajoutez un cas lorsqu’une nouvelle règle devient durable. La suite reste alors une description exécutable du comportement attendu.