WHITE PAPER

Radiographier une application

pour « Tester Juste ».

Un nouveau regard pour la validation

Copyright Kalistick 2010

Tous droits réservés.

WHITE PAPER

2

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.

WHITE PAPER

3

CCOONNTTEEXXTTEE

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.

UUNNEE NNOOUU VVEELL LL EE VV II SSIIBB IILL IITT EE SSUU RR LL ’’AA PP PPLL IICC AATTIIOONN AA VV AALL II DDEERR

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

WHITE PAPER

4

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).

FIGURE 1 : ORGANISATION « VIRTUELLE » 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é).

WHITE PAPER

5

QQUUEELL SS SSOONNTT LL EESS PP RROOBBLL EEMM EESS ??

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.

WHITE PAPER

6

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.

LL ’’EEXXAAMMEENN RRAADDIIOO GGRRAAPPHH IIQQUUEE

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%.

WHITE PAPER

7

FIGURE 2 : PERIMETRE 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.

FIGURE 3 : RESTITUTION DES RISQUES FONCTIONNELS ET REGRESSIONS

(risques : vert -> rouge, zones modifiées & risques régressions)

CCOOMMMMEENNTT PPRROODDUU IIRREE CCEETTTT EE RRAADD IIOO GGRRAAPPHH IIEE

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.

FIGURE 4 : PROCESSUS DE RADIOGRAPHIE

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.

WHITE PAPER

8

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.

CCAARRAACC TTEERR IISSTT IIQQUU EESS SSUUPP PPLL EEMMEENN TTAA IIRREESS DD EE LL AA PPLL AA TTEEFF OO RRMMEE DD EE

RRAADDIIOOGGRR AAPPHH IIEE

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.

WHITE PAPER

9

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).

LLEESS BBEE NNEEFF II CCEESS DDEE CC EETTTTEE VV IISS IIBB IILL IITT EE PPOOUU RR LL AA VVAALL IIDDAATT IIOONN

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 :

AANN TT II CC II PP EE RR LL EE SS PP RR OO BB LL EE MM EE SS

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.

AAUU GG MM EE NN TT EE RR LL ’’ EE FF FF II CC AA CC II TT EE DD EE SS TT EE SS TT SS

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.

AASS SS UU RR EE RR LL AA SS TT AA BB II LL II TT EE DD EE LL AA QQ UU AA LL II TT EE

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é.

WHITE PAPER

10

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.

CCOO NN TT RR OO LL EE RR LL EE SS RR II SS QQ UU EE SS DD EE DD EE PP LL OO II EE MM EE NN TT DD ’’ UU NN CC OO RR RR EE CC TT II FF

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.

AAGG II RR SS UU RR LL AA QQ UU AA LL II TT EE EE NN AA MM OO NN TT

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.

CCOONNCCLL UUSSIIOONN

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