Analyse d'une solution permettant d'accélérer les phases de test et de validation de logiciels et de diminuer leurs coûts

1. WHITE PAPER
Radiographier une application
pour « Tester Juste ».
Un nouveau regard pour la validation
Copyright Kalistick 2010
Tous droits réservés.

2. WHITE PAPER
Afin de satisfaire les besoins de l’entreprise, tout système d’information
doit s’aligner sans cesse avec des exigences de plus en plus fluctuantes et à
un rythme toujours plus rapide. Cela influe sur les processus de
développement mais exige également une gestion plus efficiente des phases
de qualification et de recette, soumises à des fortes pressions et à des
risques croissants.
Adopter une approche basée sur la connaissance d’informations précises sur
la version à valider permet de franchir une nouvelle étape dans
l’amélioration économique des activités de qualification et de recette, avec
comme bénéfices potentiels une amélioration de 32% de l’efficacité de la
validation et une réduction de 45% de sa durée1
Cette approche « boite 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.
 Maitriser les risques de déploiement d’un correctif.
 Agir sur la qualité en amont.
1
Capers Jones, Software Quality in 2010: “A Survey of the state of the art”, basée sur
13500 projets, 675 sociétés (150 Fortune 500) + 35 acteurs publics dans 24 pays, et
confirmés par 15 conflits juridiques.
2

3. WHITE PAPER
CONTEXTE
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 chers, …
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 VISIBILITE SUR L’APPLICATION A 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.
Le diagramme suivant représente 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
3

4. WHITE PAPER
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érant).
F IGURE 1 : O RGANISATION « V IRTUELLE » POUR LA VALIDATION
Au centre, nous avons représenté une organisation « virtuelle » chargée de la
qualification et de la recette. 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ée2 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 leurs
activités de test efficacement tout en s’inscrivant dans un cadre de gestion des
risques opérationnels.
2
Mais aussi dans le cas d’un correctif à déployer rapidement (rarement planifié).
4

5. WHITE PAPER
QUELS SONT LES PROBLEMES ?
Commençons par regrouper quelques situations rencontrées couramment :
1) A la fin des tests, seule 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 empiriques3 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’effort 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 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.
3
Empirical Studies from Software Quality Group of ATI (at.es).
“Empirical Studies of a Prediction Model for Regression Test Selection”, Harrold,
Rosenblum, Rothermel, Weyuker, IEEE.
5

6. WHITE PAPER
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 validation4 de cette version,
 Orienter les efforts 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 version5.
La clé réside dans une radiographie des livraisons qui apporte à chacun une
information objective :
 Evaluer la densité potentielle de défauts en effectuant une « validation
qualité » basée sur des techniques d’analyse du code source.
 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.
 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 (360°), 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.
4
Validation s’entend au sens du modèle V&V, à savoir toutes les activités de test en
qualification et recette
5
Chaque itération correspond à une livraison et apporte de nouveaux risques de
régressions. Le nombre de bugs introduits lors de modifications pendant la
validation est estimé à 8%.
6

7. WHITE PAPER
F IGURE 2 : P ERIMETRE D ’ UNE RADIOGRAPHIE 360°
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, comme illustrée sur la figure ci-dessous, montre plus
clairement les zones de risques à couvrir lors des tests.
F IGURE 3 : R ESTITUTION DES RISQUES FONCTIONNELS ET REGRESSIONS
(risques : vert -> rouge, zones modifiées & risques régressions)
COMMENT PRODUIRE CETTE RADIOGRAPHIE
Pour réaliser cette radiographie, la plateforme Kalistick conjugue plusieurs
techniques d’analyse de l’application6 afin d’obtenir des informations pertinentes
et complémentaires, et les restitue de manière adaptée aux besoins des différents
acteurs de la validation.
F IGURE 4 : P ROCESSUS DE RADIOGRA PHIE
6
Ces techniques sont issues des recherches menées en collaboration avec les
laboratoires de l’Insa de Lyon et du CETIC, et ont été primées par le Ministère de la
Recherche en 2008.
7

8. WHITE PAPER
Les techniques appliquées sont :
 Analyse statique du code, il s’agit d’une technique qui se rapproche de la
boite blanche pour détecter les potentiels problèmes techniques et
structurels.
 Analyse des architectures technique et fonctionnelle pour recomposer son
organisation interne, 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 des 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 forme une approche que nous qualifions de « boite grise » pour sa
capacité à restituer sur le plan fonctionnel une analyse interne de l’application, de
ses variations et de ses risques.
CARACTERISTIQUES SUPPLEMENTAIRES DE LA PLATEFORME DE
RADIOGRAPHIE
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 la solution 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.
8

9. WHITE PAPER
La plateforme Kalistick offre ces caractéristiques notamment grâce au mode SaaS
(Software as a Service), c'est-à-dire accessible par Internet par tous les acteurs du
projet, dans différentes langues, et intégrées avec les plateformes de
développement et de test (ALM - Application Life-Cycle Management).
LES BENEFICES DE CETTE VISIBILITE 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 PROBLEMES
Ce premier bénéfice est très tangible : l’anticipation sur la validation. Car
l’analyse des résultats des radiographies réalisées montre que trop souvent on
s’attaque à 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 montre des études, telles celles de Capers Jones7, le coût et la durée de
validation augmentent de 50% lorsque l’on est face à une application
« pathologique8 ». Avoir cette information est donc capital.
 AUGMENTER L’EFFICACITE DES TESTS
Disposer à chaque livraison d’une vision précise des modifications réalisées, telles
des « releases notes », accompagnée par 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 STABILITE DE LA QUALITE
Lors du déploiement d’une nouvelle version, on cherche toujours à s’assurer que
la qualité est à 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
7
Cf. note 1 : Capers Jones, Software Quality in 2010.
8
Dans un état de faible qualité.
9

10. WHITE PAPER
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.
 CONTROLER LES RISQUES DE DEPLOIEMENT 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 QUALITE 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ée 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.
 Maitriser 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 montrent l’effet de levier que représente cette
visibilité pour la validation. Car lorsque cette approche « boite grise » laisse
entrevoir des difficultés, une approche traditionnelle de la validation de type
« boite noire » se traduit des risques non-maitrisés avec des retards
imprévisibles et des instabilités en production.
Copyright Kalistick 2010.Tous droits réservés.
www.kalistick.fr - contact@kalistick.fr
10