Vous avez dit non régression ! – Arnaud Verin

1.1.    Un concept connu mais qui reste néanmoins assez flou

La non régression est l’un des éléments principaux du test logiciel. C’est aussi une de ses particularités. Nombreux sont ceux qui ont manipulé ce concept un jour, pour autant, tous n’en partagent pas la même vision :

• pour certains, il s’agit de vérifier que le logiciel continue à fonctionner de la même manière que pour la version précédente ;
• pour les autres, il convient de s’assurer qu’aucune instabilité ne vient compromettre le bon fonctionnement applicatif en cours de version.

La non régression, si elle comprend ces deux visions, va bien au-delà.

1.1.1.  La non régression, une particularité de la phase de test

Pourquoi la non régression est elle une particularité de la phase de test ? Tout simplement parce que toutes les différentes phases de l’évolution d’un système informatique s’attachent à ne traiter que les points qui font l’objet de cette évolution. Or, le périmètre des tests est composé à la fois des évolutions, mais aussi de la non régression des fonctionnalités non impactées. De part son travail d’assurance qualité, le test n’est pas assujetti au seul périmètre évolutif, mais à la globalité du système.

Le périmètre des tests sera donc, la plupart du temps, plus large que celui des évolutions dont il doit contrôler la qualité.

1.1.2.  L’ambigüité des fonctionnalités non impactées

De fait, toute l’ambiguïté porte sur cette notion de fonctionnalités non impactées.

Certaines fonctionnalités ne sont pas impactées d’un point de vue fonctionnel. Pour autant, au vu de la complexité des architectures logicielles et de la réutilisabilité de certains composants techniques, l’évolution d’une fonctionnalité peut entraîner une défaillance dans le comportement d’une autre. Une fonctionnalité peut être non impactée d’un point de vue fonctionnel, mais l’être d’un point de vue technique.

Outre ce facteur de complexité interne logicielle, l’évolution d’une fonctionnalité peut aussi entraîner son inintégration par rapport au reste du logiciel :

• pour des raisons technico-fonctionnelles ;
• du fait de la multiplicité des acteurs œuvrant à la conception fonctionnelle ou technique.

C’est ainsi que l’impact sur une fonctionnalité utilisant une donnée d’une autre fonctionnalité évoluant peut-être omis.

Pour gérer ce risque, la non régression devra donc aussi couvrir les fonctionnalités adjacentes voire l’intégralité des processus contenant l’évolution.

Pourquoi aller jusqu’à tester le processus dans sa globalité ? Parce qu’un défaut sur une fonctionnalité peut parfois rester caché en base de données par exemple, et causer une défaillance sur une autre fonctionnalité du processus, plus ou moins éloignée. En combinant tous ces risques de régression du logiciel, on se rend vite compte de la complexité que peut représenter une étude d’impact, et de la nécessité d’avoir une bonne couverture de test de non régression, afin de se prémunir de ce risque.

1.1.3.  Une problématique : le chiffrage des tests

Et c’est aussi cette particularité qui rend le travail de chiffrage des phases de test très délicat. Effectivement, le chiffrage de toutes les phases est effectué par rapport au périmètre des évolutions. On adopte donc la même posture pour le test, et on chiffre en général en faisant un ratio par rapport à la phase de développement. Or, il n’existe pas de linéarité entre ces deux phases, ni envers aucune autre d’ailleurs, en raison de la présence d’éléments supplémentaires à tester : la non régression. Cet effort de non régression est plutôt lié à l’ampleur du patrimoine fonctionnel applicatif, à son instabilité et sa criticité. Le chiffrage des phases de test doit donc être fait par rapport à la stratégie de test mis en place.

1.1.4.  Un point d’attention : le capital de non régression

Le concept de non régression couvre aussi la gestion du capital de non régression. Car il s’agit bien d’un capital de non régression qu’il faut gérer. Celui-ci se compose de tous les pas de test, procédures de test, scénarios de test et jeux de données qui permettent de s’assurer du bon fonctionnement de l’application. Il doit être réutilisable et maintenable de manière aisée. Ce capital peut être humain ou de type référentiel de test, nous le découvrirons par ailleurs.

1.2.    Une étape importante de la maîtrise de la qualité

Comme démontré précédemment, les évolutions, dues aux différents niveaux de complexité, entraînent une instabilité intrinsèque à la plupart des systèmes informatiques. Les impacts sont difficilement circonscriptibles. La régression peut apparaître partout. Il est donc important pour maîtriser la qualité, d’effectuer un effort de non régression proportionnel aux enjeux et risques en présence.

En repartant de sa définition, la non régression est une réexécution de tests validés sur une version logicielle précédente, d’une fonctionnalité non impactée par la livraison présente du logiciel, dans le but de s’assurer de son fonctionnement nominal. Il s’agit donc de vérifier que le comportement du logiciel soumis aux mêmes données en entrée, fournira le même service en sortie. Le test de non régression comme les autres parties du test, est d’abord là pour se prémunir d’un risque. Il s’agit d’un investissement pour se préserver d’une anomalie en production, qui serait préjudiciable. Mais dans les faits, comment atteindre cet objectif de maîtrise de la qualité ?

1.2.1.  Les piliers de la maîtrise de la qualité

Deux points essentiels permettent de maîtriser la qualité des évolutions d’un système.

Premièrement, toute livraison est une source d’instabilité du système, que ce soient les évolutions en elles-mêmes ou les corrections d’anomalies. Donc, si l’on veut maîtriser la qualité logicielle tout au long du cycle projet, il faut vérifier la non régression sur chacune de ces livraisons. Bien entendu le niveau de non régression doit être adapté aux enjeux et risques de la livraison. Nous verrons par la suite les différentes typologies de livraison et l’effort qui doit y être consenti.

En second lieu, pour effectuer une non régression de qualité et être certain de simuler le même comportement d’une fois sur l’autre, et donc de vérifier que le logiciel est stable, il faut être en mesure de répéter strictement les mêmes actions. Ceci sous-entend un niveau de granularité fin dans la spécification des tests, d’autant plus que les équipes de test peuvent changer. Ces actions, qui doivent donc être reproduites à l’identique, doivent donc être décrites de manière exhaustive dans les cas de test, quelle que soit la méthode de non régression. En effet, même une équipe « sachante » ne sera pas capable de reproduire exactement les mêmes actions sans disposer d’un descriptif détaillé des chemins applicatifs et actions exactes. Il s’agit là d’une condition sine qua non pour vérifier de manière certaine que le comportement reste inchangé, souvent sur un intervalle de versionning applicatif de six mois.

1.2.2.  Deux méthodes pour comparer les résultats attendus

Mais les actions ne sont pas suffisantes pour vérifier la non régression, il faut aussi comparer les résultats attendus. Pour ce faire, deux méthodes peuvent être envisagées.

Quand on parle de non régression, on pense parfois à « comparaison de base des données ». Il s’agit d’une méthode consistant à exécuter un cahier de test sur une version précédente du logiciel, de sauvegarder la base de données, de reexécuter ce cahier sur la nouvelle version logicielle, pour enfin comparer les bases de données et en extraire les régressions identifiées.

• Avantage : la possibilité de s’abstenir de spécifier les résultats attendus, puisqu’ils sont comparés à l’image qu’ils ont laissés en base de données lors de la précédente exécution.
• Inconvénient : l’obligation de passer l’intégralité du cahier de test afin de pouvoir effectuer une comparaison de base, et ainsi, identifier les régressions. Cette méthode ne peut donc pas s’adapter à la taille de la livraison et nécessite une logistique difficilement compatible avec des exigences de réactivité.

Je ne préconise donc pas cette méthode qui est coûteuse (deux bases de données, rafraîchissement d’environnement, maintien en version …), qui peut être longue en analyse des différences et sans garantie de résultat (modification du schéma de données, données intermédiaires …).

La méthode la plus efficace pour maîtriser la non régression, et donc la qualité logicielle, reste le rejeu d’un cahier issu d’un référentiel de test bien formé. Quand on parle de référentiel bien formé, on pense notamment à des pas de test avec des actions et résultats attendus compréhensibles, reproductibles et exhaustifs. Les résultats attendus doivent donc être pour les mêmes raisons que les actions, spécifiés de manière fine et exhaustive. Cela permet de garantir que le logiciel aura le même comportement pour les mêmes données en entrée, et donc de vérifier la non régression applicative. Bien entendu ce référentiel peut être automatisé en suivant un certain nombre de règles …

1.2.3.  Une non régression adaptée aux types de livraisons

Ce cahier de test doit doncêtre exécuté à chacune des livraisons applicatives pour en maîtriser la qualité. Il faut différencier trois types de livraisons qui auront chacune une non régression adéquate.

• Au démarrage d’une version, en général, toutes les évolutions sont livrées en un seul bloc. Il s’agit donc d’une instabilité majeure et étendue du logiciel pour laquelle on doit faire tester la non régression de l’existant.
• En cours de version, à la suite de correction d’anomalies, des livraisons concernent des périmètres restreints qui sont plus facilement maîtrisés. On peut donc faire une non régression locale.
• Enfin, une dernière livraison vient clôturer la version avant livraison en production, pour laquelle une non régression de la version doit être effectuée.

L’intérêt et la manière de faire ces différentes non régressions sont présentées par la suite.

1.3.    Non régression de l’existant

Une nouvelle version d’un logiciel comporte un certain nombre d’évolutions et de nouvelles fonctionnalités à même de perturber le fonctionnement général applicatif. Les impacts étant difficilement prévisibles, cette première phase de non régression permet de s’assurer que les fonctionnalités et comportements de l’application non impactées par la livraison conservent un fonctionnement nominal. Hors stratégie de test particulière, il est donc recommandé d’effectuer cette non régression de l’existant sur le périmètre applicatif complet, en prenant soin de doser l’effort de test en fonction des impacts. Cette stratégie peut et doit s’appliquer à l’ensemble du parc applicatif, les applications étant souvent imbriquées : un défaut sur l’une peut impliquer une défaillance sur une autre.

A partir de là, comment insérer la campagne de non régression de l’existant au sein de la campagne des évolutions : en début de phase, en fin de phase ? Certains diront en fin de phase, pour avoir stabilisé les évolutions avant. Ceci permettra de ne pas tester plusieurs fois la non régression de l’existant en cas d’instabilité récurrente des évolutions. Mais que se passera-t-il si, en fin de test, lors de la non régression de l’existant, on trouve une ou plusieurs anomalies bloquantes dont les corrections entraînent de nouvelles instabilités des évolutions ? On entre dans un cercle vicieux qui fait que certaines phases de test n’en finissent pas de recommencer.

Mais alors comment faire pour maîtriser la qualité logicielle ? Tout simplement en voyant une livraison comme un tout indivisible. Une version est composée d’évolutions et de comportements existants, mais c’est avant tout une nouvelle version du logiciel qu’il faut vérifier. Testons donc les processus métier un par un, suivant une stratégie de priorité de ces processus, en confondant les aspects évolutions et comportements existants. Les processus métier les plus importants seront stabilisés en premier et permettront rapidement de maîtriser la qualité logicielle pour tenir les jalons projet. Les évolutions et les comportements existants seront donc vérifiées en parallèle, du début de la phase de test, jusqu’à sa fin.

La première livraison en test d’une nouvelle version applicative se fait en général en une seule fois. Malheureusement, certains plannings projet contraints ou certaines causes exogènes ne permettent pas de maintenir ce cap idéal. Chaque cas est unique et la stratégie de test devra s’y adapter, mais cette première étape de non régression est avant tout là pour permettre de maîtriser une instabilité majeure. Il convient donc d’attendre d’avoir une livraison la plus exhaustive possible avant de lancer l’effort de non régression.

Néanmoins, le périmètre de non régression peut être découpé, et nous le verrons par la suite, d’autres remparts permettent de maîtriser la qualité.

1.4.    Non régression locale

Le deuxième type de livraison applicative intervient au sein de la phase de test et consiste en la livraison de patchs correctifs. Ces patchs contiennent un certain nombre de corrections d’anomalies sur des processus métier actuellement en test ou ayant déjà été validés. Des instabilités locales au périmètre des corrections d’anomalies livrées peuvent apparaître. Si on ne fait pas de non régression locale sur le périmètre des patchs correctifs, un risque de régression sur un processus métier déjà validé peut apparaître, que ce soit sur le périmètre des évolutions ou des comportements existants. Des tests de non régression sur l’existant en fin de phase projet, qui est une méthode relativement répandue, ne permettent pas de couvrir le risque de régression sur les évolutions. Ils couvrent seulement celui sur les comportements existants, mais de manière trop tardive. Certaines régressions seraient alors détectées en production ou lors de cette dernière phase de non régression. Par contre celle-ci arrive tard dans le cycle projet et elle est là pour donner un dernier coup de tampon sur la version comme nous le verrons par la suite. Une non régression locale au périmètre des patchs correctifs permet donc de maîtriser la qualité logicielle.

Cette livraison arrivant après la livraison initiale des évolutions, et donc le début de leurs tests, le risque de régression peut apparaître à la fois sur les comportements non impactés par la version mais aussi sur les évolutions elles-mêmes. Souvent on ne conçoit la non régression que par rapport à la version logicielle précédente, en oubliant que les évolutions peuvent aussi régresser au cours de version. La non régression locale devra donc vérifier les processus métier impactés par les patchs, quelle que soit l’ancienneté du comportement.

Toutefois, pour ne pas pénaliser le test des évolutions et en considérant une fréquence classique de livraison des patchs à la semaine, il convient d’effectuer la non régression locale sur un délai de l’ordre de la demi-journée, ceci dépendant de la stratégie globale et du périmètre des livraisons. Cette phase ne pourra peut-être pas assurer l’intégralité de la non régression, mais vérifiera dans les grandes lignes que les processus métier fonctionnent. Il ne faut pas à contrario que l’effort de non régression prenne le pas sur le test des évolutions. Il faut maîtriser les instabilités majeures qui peuvent être longues à corriger, et laisser le reste pour la dernière phase de non régression. Le tout est de trouver l’équilibre entre ces deux phases de non régression.

Comme nous venons de le voir, les patchs sont une cause d’instabilité et l’effort de non régression local doit être parcimonieux. Trois axes nous permettent de contenir cet effort de non régression au minimum :

• Maîtriser le contenu des patchs correctifs en les restreignant par module fonctionnel et ainsi faire la non régression locale d’un module une seule fois ;
• Si plusieurs patchs correctifs consécutifs concernent le même module fonctionnel, restreindre la non régression locale sur ce module au dernier patch, sans toutefois attendre le dernier moment pour l’effectuer ;
• Ne pas faire de non régression locale sur un module fonctionnel si le patch correctif ne contient qu’une anomalie mineure sur celui-ci ou que l’effort de non régression est trop important par rapport au risque, sachant qu’une dernière phase de non régression intervient en fin de version.

1.5.    Non régression de la version

La dernière livraison corrective intervient en général quelques semaines avant la livraison en production, et permet de valider le package d’installation.

Au vu des délais, cette version du logiciel permet de régler les derniers détails avant la mise en production, mais tout aléa majeur risque d’avoir des impacts sur les jalons finaux. Elle est le résultat de plusieurs semaines de tests, de découvertes d’anomalies, de packages correctifs, d’installations, de vérifications des corrections, de retests… Une non régression sur cette version ne peut être à elle seule une assurance de la tenue des jalons, mais elle doit faire un état des lieux rapide sur une version stable du logiciel. Elle est là pour valider que l’intégration des différents patchs correctifs fournit une version du logiciel répondant aux exigences de livraison vers le métier. Un équilibre est à trouver entre les non régressions locales et cette phase, les unes pour vérifier la stabilité du logiciel sans prendre le pas sur le test des évolutions, l’autre pour faire un état des lieux et régler les derniers détails pour assurer une mise en production sereine.

Cette version se doit d’être la plus stable possible avant la mise en production. Ces tests de non régression sont là pour dresser un état des lieux avant livraison en production et ainsi, prendre toutes les mesures de contournement permettant de respecter le travail du métier en cas d’anomalies résiduelles. Il faut donc réaliser cette non régression sur une version du logiciel prenant en compte le plus possible de corrections d’anomalies dans les jalons imposés. En général on laisse une semaine de délai entre la fin de la réalisation des tests d’évolution et cette phase. Le temps pour le fournisseur de réaliser une dernière version du logiciel apte à fournir le service pour lequel il a été développé.

La non régression de la version, comme la non régression locale, doit voir le logiciel comme un tout et ainsi faire une dernière passe à la fois sur les évolutions et sur les comportements existants. Celle-ci se déroule en général sur une à deux semaines et son périmètre doit porter sur des scénarios à rejouer en fonction de la priorité du processus métier et de l’instabilité de ce processus, constatée durant les tests de cette version.

1.6.    En synthèse

Ceci est une stratégie de test de la non régression, mais il en existe d’autres. L’avantage de celle-ci est de pouvoir valider les processus métier par ordre de priorité en confondant les aspects évolutions et comportements existants. Elle permet aussi de maîtriser la qualité du logiciel tout au long de la chaîne de test, et ainsi, pouvoir prendre une décision de mise en production au plus tôt du cycle de test. Cette stratégie peut paraître lourde avec ces trois phases de non régression, mais finalement elle permet de maîtriser la qualité et donc de réduire les coûts et délais des projets de test.

Si le logiciel a une architecture simple, avec des modules fonctionnels bien cloisonnés, et que l’on maîtrise réellement les impacts, les tests de non régression ne sont pas forcément nécessaires. Ils sont là pour se prémunir d’un risque, risque qu’il faudra évaluer afin de mettre en place la bonne stratégie de test de votre organisation.

À propos de l’auteur: Arnaud Verin

Officiant depuis maintenant 20 ans dans la qualité logicielle, Arnaud est intervenu sur quasiment tous les rôles. De testeur fonctionnel, technique et automaticien, en passant par responsable d’équipe et chef de projet, il tient aujourd’hui un double rôle :
• D’un côté directeur de projet, il met en place des stratégies de test pour de gros programmes, des centres d’excellence test ;
• De l’autre réalisant des missions de conseil, audit, diagnostic, mentoring et formation pour accompagner les entreprises à optimiser leur processus de test manuel et automatique.