Tester Juste, une nécessité pour augmenter l’efficacité de la recette

Par Marc Rambert, Président de Kalistick

Cette approche « boîte grise » passe par une « radiographie » des applications à valider pour obtenir une nouvelle visibilité sur les risques à couvrir et ainsi :
-Anticiper les problèmes,
-Augmenter l’efficacité des tests,
-Assurer la stabilité de la qualité de version en version,
-Maîtriser les risques de déploiement d’un correctif,
-Agir sur la qualité en amont.

Avant de rendre un système opérationnel, il faut toujours s’assurer de sa conformité à un niveau de qualité qui dépend des risques à prévenir (dysfonctionnements, mauvaises performances, failles de sécurité…). Différentes méthodes sont disponibles à cet effet, toutes basées sur des activités formelles de revues ou sur le déroulement de campagnes de test.

Force est de constater qu’aucune ne permet de répondre de manière satisfaisante à tous les enjeux, aussi bien du monde de l’IT que de celui des métiers, comme le démontrent les problèmes soulevés par les acteurs impliqués :
– L’IT se plaint des délais de qualification trop courts, des équipes sous-dimensionnées, des budgets prévisionnels insuffisants…
– Les métiers constatent que la recette dure trop longtemps, que les tests mobilisent trop de ressources non informatiques, que des dysfonctionnements restent et coûtent cher…

Une première tentative de solution est venue de la standardisation des processus (modèle V&V, méthodologie TMap…). Cette standardisation a ensuite permis d’automatiser certaines activités. Dernièrement, une amélioration importante est venue de l’apport du pilotage des tests par les risques (RBT – Risk-Based Testing), qui constate qu’une couverture à 100 % des exigences fonctionnelles et non fonctionnelles relève de la théorie, et recommande de mieux cibler ses efforts. Cependant l’accélération des fréquences d’évolution, la complexité des systèmes, leurs interconnexions via les architectures SOA, mais aussi l’adoption des méthodologies agiles nécessitent des stratégies complémentaires. Il est primordial de rendre les activités de tests non seulement plus efficaces (découverte des défauts les plus critiques), mais également plus efficientes (couverture optimale avec le moins de cas de test). En effet, ces activités représentent encore 30 à 50 % des budgets et malgré cela, des défauts « latents » génèrent des anomalies qui coûtent très cher.

Une nouvelle visibilité sur l’application à valider

Les phases de qualification et recette impliquent différents acteurs et structures organisationnelles de l’entreprise avec des rôles et responsabilités complémentaires.

Imaginons une organisation articulée autour de trois entités : les études et projets (département qui a en charge la partie amont d’un projet de développement ainsi que la relation avec les entités métiers, y compris l’accompagnement à la recette), le développement (département interne ou externe qui effectue les développements) et la production (exploitation de l’infrastructure technologique et services y afférents).

Au centre, une organisation « virtuelle », chargée de la qualification et de la recette, complète le dispositif. Certains l’incluront dans le département études et projets, d’autres pourront considérer cette entité comme un prestataire de TRA (Tierce Recette Applicative).

L’objectif principal de cette organisation est d’optimiser en temps et ressources toutes les activités d’assurance qualité liées à une livraison planifiée de version d’un système d’information, quel que soit le type d’évolution.

Pour atteindre cet objectif, son rôle est double : l’un est d’accompagner le pilotage de la qualité globale du projet depuis les spécifications jusqu’à la mise en production, l’autre est de certifier à tout moment la conformité d’une livraison afin de garantir la fiabilité opérationnelle requise.

A chaque livraison, les responsables de qualification ou de recette doivent s’appuyer sur des stratégies qui leur permettent d’évaluer, piloter et gérer efficacement leurs activités de test, tout en s’inscrivant dans un cadre de gestion des risques opérationnels.

Quels sont les problèmes ?

Commençons par regrouper quelques situations rencontrées couramment :

1) A la fin des tests, seuls 50 % de la couverture fonctionnelle est testée et les mêmes tests sont sans cesse répétés (inefficience des tests).
2) Malgré des campagnes de test menées jusqu’au bout, la fiabilité du système s’avère insuffisante au vu des incidents rencontrés en production (inefficacité des tests).
3) Après des évolutions mineures exigées par les entités métiers et testées normalement, le système s’est dégradé (non pertinence des tests).
Tout comme une énumération de symptômes ne suffit pas, il nous faut analyser les causes des problèmes rencontrés lors des phases de qualification et de recette pour identifier des solutions. Des études empiriques publiées après des recherches scientifiques listent des causes originelles parmi lesquelles :

–    La qualité structurelle du code n’est pas au niveau requis. Dans ce cas, la phase de validation se confronte à des problèmes qui auraient dû être éliminés en amont, car liés à un déficit dans les pratiques de développement qui engendrent des défauts fonctionnels.
–    La maintenabilité et l’évolutivité du code ne sont pas suffisantes. Chaque modification exige plus d’efforts et a des impacts plus larges sur l’application ; cela augmente d’autant le risque de régressions. En conséquence, l’effort de test sera très important à chaque version, même mineure.
–    Les impacts des modifications réalisées ne sont pas correctement perçus, ou alors de manière trop tardive, et les campagnes de test ne s’appuient pas sur les risques réels de régressions selon les fonctionnalités impactées par le code modifié. Il est par exemple fréquent que des bugs soient créés lors des dernières corrections livrées en fin de validation et pour lesquelles il est impossible de rejouer l’ensemble des tests.
–    Le manque de visibilité sur le contenu du livrable reçu rend difficile la mise en place d’une stratégie de tests basée sur une collaboration efficace entre tous les acteurs. Les testeurs ne peuvent pas optimiser leurs efforts, les entités métiers ne reçoivent pas les informations nécessaires à l’évaluation des risques métiers et l’exploitation n’a pas de visibilité précise sur les versions.

La conséquence fréquente de ces différents points : un nombre de livraisons trop important pour une même phase de validation. Chaque livraison supplémentaire augmente les coûts et la durée des tests, les risques de régressions non détectées, et retarde la mise en production.

L’Examen radiographique

Evaluer ces risques en amont de la réception de chaque livraison en disposant d’une vision précise de la qualité du produit, de ses risques structurels, des modifications et de leurs impacts renforce les processus de « validation qualité », « validation produit » et « validation version » avec des indicateurs clairs pour :

–    Evaluer l’effort de test nécessaire à la validation de cette version,
–    Orienter l’effort de test sur les bons composants et fonctionnalités au moment opportun,
–    Réduire le nombre d’itérations nécessaires à la validation d’une version .
–    La clé réside dans une radiographie des livraisons, qui apporte à chacun une information obje
ctive :
     o    Evaluer la densité potentielle de défauts en effectuant une « validation qualité » basée sur des techniques d’analyse du code source,
     o    Restituer les risques projets et métier au travers d’une « validation produit » avec une vision rapide sur les impacts directs et indirects (régressions) des évolutions réalisées,
     o    Donner aux entités de production une vision instantanée sur les changements à déployer et les éventuels problèmes d’intégration grâce à une « validation version ».

Pour satisfaire à ces trois validations et donner une visibilité complète sur l’application, la radiographie doit analyser des domaines complémentaires et agréger les résultats pour fournir une synthèse pertinente et exploitable. En couvrant les 8 domaines présentés ci-après, une plateforme de radiographie devient une source d’informations riche pour planifier, piloter et gérer les activités de validation. En disposer à chaque livraison évite de se lancer à « l’aveugle » dans une phase de qualification ou de recette.

L’agrégation et la restitution des informations doivent se faire en utilisant un prisme adapté aux besoins de chaque acteur. Ainsi, une restitution basée sur l’architecture fonctionnelle montre plus clairement les zones de risques à couvrir lors des tests.

Comment produire cette radiographie ?

Pour réaliser cette radiographie, il est nécessaire de conjuguer plusieurs techniques d’analyse de l’application afin d’obtenir des informations pertinentes et complémentaires, et de les restituer de manière adaptée aux besoins des différents acteurs de la validation.

Les techniques appliquées sont :
–    Analyse statique du code, il s’agit d’une technique qui se rapproche de la boîte blanche pour détecter les potentiels problèmes techniques et structurels,
–    Analyse des architectures technique et fonctionnelle pour recomposer son organisation interne, pour pouvoir en vérifier la cohérence et restituer les informations sur un angle fonctionnel,
–    Analyse des variations entre chaque livraison avec la version en production, pour retrouver les modifications réalisées, évaluer les risques associés et ainsi pouvoir affecter les bonnes priorités aux tests à réaliser,
–    Analyse des tests réalisés par les équipes de développement avant la livraison, de leur couverture de modifications réalisées, pour détecter les points insuffisamment testés ou éviter de focaliser tous les efforts de tests sur les mêmes éléments.

La combinaison de ces différents axes d’analyse et la visibilité qu’elle donne des applications forment une approche de « boîte grise » pour sa capacité à restituer sur le plan fonctionnel une analyse interne de l’application, de ses variations et de ses risques.

Pour maximiser l’efficacité de la démarche, cette radiographie doit se faire à chaque livraison et s’intégrer de manière fluide dans les processus existants. Pour cela, il est important qu’elle soit automatisée, que ses résultats soient disponibles en quelques heures et accessibles facilement à l’ensemble des acteurs internes ou externes pour disposer d’un référentiel commun. Pour les projets offshore, il est important d’avoir une plateforme multilingue, accessible par Internet de manière sécurisée, pour partager la visibilité acquise sur l’application.

En outre, permettre un accès à l’équipe de développement est primordial, car l’expérience montre qu’il est également souhaitable de disposer d’une radiographie anticipée, en amont de la livraison officielle (quelques semaines) afin de disposer de plus de temps pour adapter sa stratégie de validation aux risques détectés.

En complément, il faut bien sûr que l’approche ne soit pas structurante et qu’elle ne génère pas une charge d’exploitation qui la rendrait trop coûteuse notamment durant les phases de maintenance corrective de l’application à radiographier.

Enfin, si elle s’appuie sur une base de connaissance pour d’étudier la corrélation réelle entre les résultats de la radiographie et les taux de panne réellement observés en production, cela permet l’amélioration continue de la radiographie et donc des validations.

Les bénéfices de cette visibilité pour la validation

Apporter au chef de projet et aux responsables d’entités concernées par la validation les moyens d’anticiper sur les risques potentiels, d’en évaluer les impacts techniques et métier en utilisant une perspective technique ou fonctionnelle selon leur rôle est une vraie innovation et apporte des bénéfices très concrets :

Anticiper les problèmes
Ce premier bénéfice est très tangible : l’anticipation sur la validation. En effet, l’analyse des résultats des radiographies réalisées montre que l’on s’attaque trop souvent à la validation d’une version instable, pas réellement testée en développement. Cette situation apparait généralement bien tard lorsque l’on a reçu de multiples livraisons pour une même version avec, à chaque livraison, de nouvelles régressions provoquées par des remaniements du code inattendus.

Avoir une vision de la version à recevoir quelques semaines avant sa réception effective et s’appuyer sur des indicateurs factuels pour estimer l’effort de tests à réaliser et les risques potentiels apporte une capacité d’anticipation forte à la DSI. Comme le montrent les études, telles celles de Capers Jones, le coût et la durée de validation augmentent de 50 % lorsque l’on est face à une application « pathologique ». Avoir cette information est donc capital.

Augmenter l’efficacité des tests
Disposer à chaque livraison d’une vision précise des modifications réalisées, telles des « releases notes », accompagnée d’une analyse d’impact de ces changements sur les plans techniques ou fonctionnels, augmente significativement la pertinence des efforts de tests. Cela évite également l’apparition de nouveaux bugs introduits avec les dernières corrections réalisées peu avant la mise en production.

Assurer la stabilité de la qualité
Lors du déploiement d’une nouvelle version, on cherche toujours à s’assurer que la qualité est a minima équivalente à la version précédente en identifiant les nouveaux problèmes ; car soit les anciens sont connus et considérés comme non prioritaires, soit pas encore découverts et donc « potentiellement moins graves », car ils ne « gênent » pas le fonctionnement actuel en production. Avoir la visibilité sur ce différentiel est donc essentiel pour éviter la dégradation de l’application au fur et à mesure de ses évolutions et l’apparition de nouveaux risques.

Contrôler les risques de développement d’un correctif
Lors de la réception d’un correctif à déployer rapidement, la capacité de test est limitée et la décision de déploiement repose sur une analyse des risques pour éviter des dysfonctionnements en chaîne. Là encore, disposer d’une radiographie immédiate est synonyme d’une analyse des risques maîtrisée. D’autant plus si on ajoute la possibilité pour la production d’identifier précisément le différentiel par rapport à la version déjà déployée, par exemple, sur la configuration ou les librairies tierces.

Agir sur la qualité en amont
Notons que les validations effectuées permettent non seulement d’estimer les probabilités de risques métiers ainsi que les impacts potentiels, mais également et surtout, la valeur du code déjà fourni et testé. Basés sur un référentiel qualité établi, les résultats font fréquemment ressortir des opportunités d’optimisation ou d’adaptation
des processus d’ingénierie logicielle en amont.

Conclusion

Disposer de cette nouvelle visibilité pour une application est un moyen efficace pour « Tester Juste » et ainsi améliorer quatre dimensions de sa validation :
–    S’assurer avant le lancement des tests que le produit est au niveau de qualité exigé,
–    Augmenter l’efficacité des activités de tests,
–    Maîtriser les risques de mise en production
–    Faciliter la gestion des risques projets

L’étude des radiographies de plusieurs centaines d’applications, représentant plus de 100 millions de lignes de code, montre l’effet de levier que représente cette visibilité pour la validation. En effet, lorsque cette approche « boîte grise » laisse entrevoir des difficultés, une approche traditionnelle de la validation de type « boîte noire » se traduit par des risques non maîtrisés avec des retards imprévisibles et des instabilités en production.