Qu'est-ce qu'un test de régression ?

Qu'est-ce qu'un test de régression ? 

L'ISTBQ propose cette définition du test de régression : "un test d'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 les parties non modifiées du logiciel à la suite des modifications apportées. Ces tests sont effectués lorsque le logiciel ou son environnement est modifié.''

Cette définition met en évidence des principes importants comme le fait de tester un logiciel qui a déjà été testé auparavant, ou de modifier ultérieurement ce même logiciel. Nous reviendrons sur ces notions dans la suite de l'article. Néanmoins, comme toute définition, elle ne peut répondre à toutes nos questions étymologiques et opérationnelles.

‍

Commençons par l'aspect étymologique d'un test de régression

Comme vous l'avez probablement remarqué, il est difficile de parler de "test de régression" en France sans qu'on vous demande : "Vous parlez de test de non-régression ?".

Nous touchons là à un sujet sensible et tout à fait spécifique à la France. 

Le terme le plus souvent utilisé en dehors de la France est "tests de régression". Cette étymologie implique qu'il peut y avoir des régressions même si on n'en trouve pas. Cela renvoie au principe bien connu des tests : "les tests exhaustifs sont impossibles".

En France, on utilise presque exclusivement le terme de "non-régression", même lorsqu'on travaille dans un environnement anglophone. Cette terminologie me dérange, car elle implique qu'après avoir exécuté ces tests, nous pouvons garantir qu'il n'y a pas de régression. Ceci est en contradiction avec le principe mentionné plus haut. Cela conduit à des malentendus et j'ai souvent reçu des remarques sur le ton du reproche du type : " vous avez fait la non-régression sur cette application, alors pourquoi n'avez-vous pas détecté cette régression ? " avec une réelle déception, car la personne pensait vraiment qu'il n'y avait pas de régression lors de la mise en production.

‍

Parlons maintenant du contexte opérationnel 

Définition d'une campagne de régression

Un test de régression est rarement isolé ! Il fait partie d'un ensemble cohérent de plusieurs tests, chacun ayant ses propres caractéristiques et objectifs. Cet ensemble représente la campagne de régression (ou de "non-régression").

L'objectif d'une campagne de régression est de vérifier si les changements apportés au logiciel (ou à son environnement) n'ont pas provoqué de régressions majeures, des bugs dans les fonctionnalités déjà en place, et donc si ces changements ont provoqué des régressions majeures.

Vous pouvez remarquer 2 points importants dans la description de l'objectif d'une campagne de régression :

• Premièrement, dans la définition de l'ISTQB, les campagnes de régression (et donc les tests de régression) n'existent que sur les parties existantes du logiciel. L'utilisation de l'expression "testé précédemment" souligne cette idée. Le but d'une campagne de régression n'est pas de découvrir s'il y a bugs dans les nouvelles fonctionnalités, ou même si les bugs existants ont été corrigés. Le but d'une campagne de régression est de détecter des changements significatifs dans le comportement du logiciel.
• Le deuxième point consiste à souligner que l'objectif n'est jamais de trouver toutes les régressions. L'objectif est de détecter les régressions majeures, celles qui auront un impact sur nos utilisateurs. Il est particulièrement important de s'en souvenir, car une campagne de régression peut rapidement devenir très coûteuse à mener, maintenirou à mettre à niveau. De même, le but n'est pas de vérifier si l'ensemble du produit correspond à ce que l'on attend en entrant dans les détails... Ces vérifications ont été faites en amont.

Voyons notre logiciel comme s'il était construit avec une architecture bâtie avec des briques de bois. La campagne de régression, réalisée par des tests de régression, vise à vérifier que l'ajout d'une ou plusieurs nouvelles briques n'a pas compromis la partie déjà construite en ayant, par exemple, effondré une partie, déséquilibré une autre ou modifié le positionnement de certaines briques... et ce de manière significative.

Il reste un élément "vague" qui ne peut être plus précis, c'est la notion de "majeur" ou "significatif". Cet élément, pour être correctement identifié, doit nécessairement être filtré par le contexte. Un bug peut être majeur pour un produit et totalement mineur pour un autre... comme le dit l'un des principes du test : le test dépend du contexte.

Maintenant que nous avons défini les objectifs du test de régression et de la campagne qu'il compose, je pense qu'il est important de parler de sa construction et de maintenance.

Construire et maintenir votre campagne de tests de régression

Afin de bien comprendre la construction et le site maintenance d'une campagne de régression, voici une image intéressante pour l'illustrer :

Ce dernier a été conçu pour un cycle Agile, mais peut également être adapté à un cycle en V, notamment pour les 2ème et 3ème colonnes.

Des modifications ont été apportées ici. Il est essentiel de valider que les changements font ce que nous voulons. Pour ce faire, nous allons tester en profondeur ces changements, qui peuvent être de nouvelles fonctionnalités, des corrections de bug ou des mises à jour techniques.

Lorsque cette validation est faite, il est alors important d'exécuter et d'analyser les résultats de la campagne de régression. Lorsque la régression et les changements sont ajoutés au produit en production, ils deviennent une partie du produit qui doit être couverte par la régression. Des tests de régression couvrant ces changements doivent alors être ajoutés si nécessaire pour enrichir la campagne de régression.

Cependant, l'enrichissement de la campagne de régression ne suffit pas pour maintenirla campagne de régression. Il est évidemment nécessaire de maintenirles tests de régression qui composent la campagne ! De même, l'enrichissement et maintenance deviennent rapidement insuffisants, et il devient rapidement nécessaire de faire évoluer sa campagne de tests si l'on veut éviter d'avoir à gérer le paradoxe du pesticide (autre principe de test !).

Pour lutter contre le paradoxe des pesticides, il est essentiel de faire évoluer votre campagne de tests... ce qui est souvent plus facile à dire qu'à faire. Il existe plusieurs façons de faire évoluer votre campagne de régression en travaillant sur ces tests. Par exemple, il est possible de :

• Proposer de nouveaux tests sur les fonctionnalités de legacy (souvent liés à bugs identifié et corrigé)
• Modifier les données ou le parcours de certains tests (tout en gardant leur objectif) qui ne détectent pas bugs

Tout cela est bien beau, mais il arrive régulièrement que cela devienne opérationnellement impossible à faire ! La raison est simple, avec le processus décrit, un effet boule de neige est créé, et la campagne de régression devient de plus en plus grande avec de plus en plus de tests. Cela pose des problèmes à plusieurs niveaux :

• Le temps d'exécution est de plus en plus long 
• Maintenance le temps devient de plus en plus long aussi
• Le temps d'analyse est également de plus en plus long
• Le coût d'une campagne est de plus en plus important

Afin d'éviter cela, il existe de nombreuses solutions techniques telles que l'automatisation ou la parallélisation, une bonne factorisation des tests... Ces solutions techniques peuvent cependant être insuffisantes, et il est souvent nécessaire de retirer certains tests de la campagne de régression. Ceci peut être fait de 2 façons :

• Hiérarchisation des tests en exécutant à chaque fois les tests les plus prioritaires, puis en sélectionnant les tests de régression sur la base d'une étude de risque (ceci diminue le temps d'exécution, le temps d'analyse et le coût, mais n'a pas d'impact sur le temps maintenance ).
• Le retrait pur et simple des tests de régression de sa campagne.

Au final, les tests de régression d'une campagne de régression correspondent en grande partie aux tests effectués lors de la validation du produit avec des tests originaux liés à la vie du logiciel :

Les tests de régression doivent-ils être automatisés ou manuels ?

Le sujet de l'automatisation des tests de régression était une vraie question à laquelle on répondait souvent " non " pour des raisons budgétaires, avant la généralisation des méthodologies Agiles. La démocratisation du développement itératif a multiplié le besoin d'exécuter des tests de régression à travers des campagnes de régression qui, idéalement, sont exécutées au moins une fois par User Story et donc plusieurs fois par sprint de quelques semaines.

L'automatisation de la régression devient alors une nécessité... surtout si l'on veut s'orienter vers le déploiement continu. 

Les seuls obstacles à l'automatisation des campagnes de régression sont désormais plutôt du côté de la possibilité de le faire.

Cette impossibilité peut avoir 2 causes :

Une impossibilité technique (ou un coût trop élevé) d'exécuter certains tests

Cette impossibilité est souvent liée à l'outil de test utilisé... Je me souviens avoir choisi de ne pas automatiser un test de régression, surtout dans une campagne en contenant 200, car même si c'était techniquement faisable, cela demandait plusieurs jours de développement pour un test qui se faisait en 30 secondes.

Une solution comme Agilitest vous permet d'automatiser sur de nombreuses technologies et de faire des tests multicanaux. Il est rare de trouver des scénarios impossibles à automatiser (même si c'est possible, par exemple, des tests graphiques avancés). Par expérience, je peux même dire qu'avec Agilitest il est possible d'automatiser des tests ou même des processus qui semblaient auparavant presque impossibles à automatiser.

Une impossibilité liée aux compétences de l'équipe

Cette impossibilité est désormais beaucoup plus fréquente que l'impossibilité technique (si l'on exclut la partie chiffrage). L'automatisation est souvent technique, surtout avec des outils non conçus pour des testeurs au profil fonctionnel et peu technique. Heureusement, il existe aujourd'hui sur le marché des outils accessibles et efficaces qui permettent de surmonter ces difficultés. Parmi ces outils, il y a évidemment Agilitest qui a été initialement conçu pour ces profils de testeurs ! Les retours des clients d'Agilitest sont très bons et Agilitest est adopté dès qu'il est essayé (aucun désabonnement enregistré à ce jour).

Si une campagne de régression doit être réalisée entièrement ou partiellement manuellement, il est bon de limiter autant que possible le nombre de tests de régression récurrents à réaliser naturellement, et de compléter ces campagnes par des campagnes de tests exploratoires visant à détecter les régressions.

En résumé

Un test de régression est avant tout un test qui va tester une partie du produit qui a déjà été testée et dont le rôle est de détecter les changements de comportement liés à des modifications du logiciel. Ce test fait partie d'une campagne spécifique dont l'objectif est de détecter les régressions majeures afin d'éviter de les déployer.

Ces tests, qui étaient auparavant essentiellement manuels, doivent désormais, avec le développement Agile, être automatisés dans la grande majorité des cas. Au moins en partie, car ils doivent être exécutés très régulièrement. Moins ces tests sont automatisés, moins ils sont exécutés et plus ils sont testés tardivement, ce qui, en plus d'aller à l'encontre du principe de "test early", entraîne des pertes d'argent et de motivation.