À la base, le mot “régression” désigne “une évolution qui ramène à un stade antérieur”. En informatique, une régression a lieu dès lors qu’un changement de code a un impact sur le code existant. Cela peut être dû à la correction d’un bug, une mise à jour logicielle, ou encore le rajout d’une nouvelle fonctionnalité.
Par exemple, quand une nouvelle fonctionnalité est implémentée, si celle-ci perturbe le comportement des fonctionnalités précédemment existantes, alors il y a régression, car un bug a été introduit. Pour éviter cela, les équipes techniques mettent donc en place des tests spécifiques, qu’on appelle tests de régression ou tests de non-régression.
Selon la définition de l’ISTQB, un test de régression consiste à tester un programme préalablement testé, après une modification, pour s’assurer que des défauts n’ont pas été introduits ou découverts dans des parties non modifiées du logiciel, comme suites des modifications effectuées.
En résumé, un test de régression sert à vérifier que les modifications apportées sur le logiciel, le site ou l’application mobile, telles que l’ajout d’une nouvelle fonctionnalité ou une mise à jour, n’ont pas impacté les fonctionnalités précédemment existantes. Prenons l’exemple d’un vélo : si on change la roue, un test de régression consisterait à vérifier que malgré le changement de roue, les freins fonctionnent toujours (mais il n’est pas nécessaire de vérifier que la pompe à vélo s’accroche bien).
Quelle différence entre test régression et test de non-régression ? En réalité, il n’y en a pas, c’est exactement la même chose. On utilise les deux termes. L’ISTQB, par exemple, préfère le terme de test de régression. Mais beaucoup de personnes du milieu utilisent également le terme de test de non-régression, en France en tout cas. Tout est une question de choix et il est vrai que lorsqu’on ne vient pas du milieu, cela peut porter à confusion. Que voulez-vous, les Français sont des êtres complexes qui aiment jouer sur les mots !
Les tests fonctionnels permettent de vérifier qu’un logiciel (site web, application mobile, API…) fonctionne conformément aux spécifications déterminées par le client en amont. Sur un site e-commerce, cela consiste par exemple à vérifier que la connexion au compte ou encore que l’ajout au panier ou la sélection d’un mode de livraison n’entraîne pas de bug et qu’il n’y a pas de différences constatées avec les données fournies au préalable.
Les tests de régression, eux, sont effectués quand une nouvelle version du code est publiée, afin de vérifier que cela n’a pas provoqué d’erreur sur le reste du logiciel. Ils peuvent autant viser des fonctionnalités, que du non fonctionnel, comme la performance. Par exemple, si une mise à jour entraîne un temps de réponse du site ou de l’application plus long que d’habitude, on peut parler de régression.
Les tests de régression ou de non-régression peuvent être exécutés de plusieurs manières, en fonction du besoin visé ou des ressources de l’entreprise.
Les tests de régression correctifs, par exemple, réutilisent les tests existants, à condition qu’aucun changement important ait été apporté au produit.
Les tests de régression complets consistent à tester à nouveau tous les éléments du produit. Cela permet de vérifier toutes les modifications qui ont été apportées depuis le début.
Les tests de régression sélectifs, quant à eux, permettent de choisir certains tests dans un ensemble afin de n’inspecter que les parties du code qui ont été impactées.
Les tests de régression progressifs consistent à créer de nouveaux tests quand les tests établis ne sont plus utiles, par exemple lorsque les caractéristiques du produit sont modifiées.
Les tests de régression partiels sont effectués lorsque différents modules sont en cours de développement et sont sur le point d’être fusionnés avec la version principale du code.
Les tests de régression unitaires servent quant à eux à tester le code de façon individuelle, sans tenir compte des autres éléments.
Les tests de régression peuvent être exécutés à tous les niveaux du plan de test, et on conseille d’ailleurs de les faire le plus régulièrement possible, dès qu’une modification ou mise à jour est apportée, au plus tôt de la conception du produit.
Mais généralement, les tests de non-régression sont réalisés dès lors qu’il y a :
>> une correction qui est apportée au code pour résoudre des anomaliesLa première raison pour laquelle il faut faire des tests de régression, et qui devrait être la principale de tous les autres types de tests, est que cela permet de garantir la qualité du logiciel (site web, application mobile). Et, en offrant un produit de qualité, on améliore également l’expérience utilisateur et donc l’image de l’entreprise.
Ensuite, réaliser des tests de régression permet de réduire les risques associés à la mise à jour des applications, sites web, etc. C’est important car outre le fait que cela peut provoquer des bugs empêchant l’utilisation de certaines fonctionnalités (ce qui peut avoir un impact sur le chiffre d’affaires de l’entreprise et son image), cela peut aussi provoquer des failles de sécurité. Et là, c’est la crédibilité de l’entreprise qui est en jeu, ainsi que la confiance des utilisateurs en cette dernière.
Outre une histoire de qualité, de risque et d’image, l’intérêt d’exécuter des tests de régression régulièrement est d’économiser du temps et de l’argent, car il est toujours plus complexe et plus coûteux de devoir corriger un bug en production. Sans compter qu’il s’agit des tests les plus pertinents à automatiser et que l’automatisation permet de gagner également du temps et de l’argent, mais nous y reviendrons plus tard.
Enfin, dans le cadre de développement d’applications mobiles ou de logiciels SaaS, qui sont continuellement mis à jour afin de répondre aux exigences des clients, les tests de régression sont d’autant plus nécessaires.
Les tests de régression sont des tests très chronophages et répétitifs, qui prennent du temps. Et s’ils doivent être automatisés en majorité, certains cas de tests doivent être effectués manuellement. Qui plus est, certaines fonctionnalités complexes nécessitent des scénarios de tests complexes, et cela peut également retarder le délai d’exécution et donc de livraison. Bref, en raison de contraintes de temps et de budget, tous les tests de régression ne peuvent pas être exécutés et il convient donc de bien choisir ceux qu’il est important de réaliser en priorité.
Comme nous le disions plus haut, les tests de non-régression ont un réel intérêt à être automatisés et ce sont d’ailleurs les tests qu’on conseille souvent d’automatiser en priorité. Pourquoi ? Parce qu’ils sont répétitifs et chronophages. Ils sont exécutés à chaque déploiement de nouvelle fonctionnalité, de mise à jour logicielle et les faire tous manuellement prend du temps, beaucoup de temps, sans compter que cela requiert de faire beaucoup de choses faciles et l’enchaînement va être fatigant et devenir difficile. C’est là où l’automatisation des cas de tests de régression prend donc tout son sens.
Enfin, l’automatisation des tests permet d’identifier le plus tôt possible d’éventuelles régressions et surtout, cela permet de tenir les cadences de livraisons et d’améliorer ainsi le ROI. Cependant, il n’est pas nécessaire de tout automatiser et on conseille généralement de se concentrer en priorité sur les cas de tests qui présentent des défauts fréquents, des cas de tests qui vérifient des fonctionnalités essentielles, critiques du produit et des cas de tests qui vérifient des fonctionnalités qui ont subi des modifications nombreuses et récentes.