réduire les coûts de test et accélérer la validation

8/7/2019 Rduire les cots de test et acclrer la validation

1/10

WHITE PAPER

Radiographier une application

pour Tester Juste .

Un nouveau regard pour la validation

Copyright Kalistick 2010

Tous droits rservs.


2/10

WHITE PAPER

2

Afin de satisfaire les besoins de lentreprise, tout systme dinformation

doit saligner sans cesse avecdes exigences de plus en plus fluctuantes et

un rythme toujours plus rapide. Cela influe sur les processus de

dveloppement mais exige galement une gestion plus efficiente des phasesde qualification et de recette, soumises des fortes pressions et des

risques croissants.

Adopter une approche base sur la connaissance dinformations prcises sur

la version valider permet de franchir une nouvelle tape dans

lamlioration conomique des activits de qualification et de recette, avec

comme bnfices potentiels une amlioration de 32% de lefficacit de la

validation et une rduction de 45% de sa dure1

Cette approche boite grise passe par une radiographie desapplications valider pour obtenir une nouvelle visibilit sur les risques

couvrir et ainsi :

Anticiper les problmes.

Augmenter lefficacit des tests.

Assurer la stabilit de la qualit de version en version.

Maitriserles risques de dploiement dun correctif.

Agir sur la qualit en amont.

1Capers Jones, Software Quality in 2010: A Survey of the state of the art, base sur

13500 projets, 675 socits (150 Fortune 500) + 35 acteurs publics dans 24 pays, etconfirms par 15 conflits juridiques.


3/10

WHITE PAPER

3

CCOO NNTTEEXXTTEE

Avant de rendre un systme oprationnel, il faut toujours sassurer de sa

conformit un niveau de qualit qui dpend des risques prvenir(dysfonctionnements, mauvaises performances, failles de scurit, ). Diffrentes

mthodes sont disponibles cet effet, toutes bases sur des activits formelles de

revues ou sur le droulement de campagnes de test. Force est de constater

quaucune ne permet de rpondre de manire satisfaisante tous les enjeux aussi

bien du monde de lIT que de celui des mtiers, comme le dmontrent les

problmes soulevs par les acteurs impliqus :

LIT se plaint des dlais de qualification trop courts, des quipes sous-

dimensionnes, des budgets prvisionnels insuffisants,

Les mtiers constatent que la recette dure trop longtemps, que les tests

mobilisent trop de ressources non-informatiques, que des

dysfonctionnements restent et cotent chers,

Une premire tentative de solution est venue de la standardisation des processus

(modle V&V, mthodologie TMap, ). Cette standardisation a ensuite permis

dautomatiser certaines activits. Dernirement, une amlioration importante est

venue de lapport du pilotage des tests par les risques (RBTRisk-Based

Testing), qui constate quune couverture 100% des exigences fonctionnelles et

non-fonctionnelles relve de la thorie, et recommande de mieux cibler ses efforts.

Cependant lacclration des frquences dvolution, la complexit des systmes,

leurs interconnexions via les architectures SOA, mais aussi ladoption des

mthodologies agiles ncessitent des stratgies complmentaires. Il est

primordial de rendre les activits de tests non seulement plus efficaces

(dcouverte des dfauts les plus critiques) mais galement plus efficientes

(couverture optimale avec le moins de cas de test). En effet, ces activits

reprsentent encore 30% 50% des budgets et malgr cela, des dfauts latents

gnrent des anomalies qui cotent trs cher.

UUNN EENNOOUU VV EELLLLEE VV II SS IIBB IILL IITT EESSUU RR LL AA PP PPLL IICC AATT IIOO NN AA VV AALL II DD EERR

Les phases de qualification et recette impliquent diffrents acteurs et structures

organisationnelles de lentreprise avec des rles et responsabilits

complmentaires.

Le diagramme suivant reprsente une organisation articule autour de trois

entits : les tudes et projets (dpartement qui a en charge la partie amont dun

projet de dveloppement ainsi que la relation avec les entits mtiers y compris


4/10

WHITE PAPER

4

laccompagnement la recette), le dveloppement (dpartement interne ou

externe qui effectue les dveloppements), et la production (exploitation de

linfrastructure technologique et services y affrant).

FIGURE 1:ORGANISATION VIRTUELLE POUR LA VALIDATION

Au centre, nous avons reprsent une organisation virtuelle charge de la

qualification et de la recette. Certains lincluront dans le dpartement tudes et

projets, dautres pourront considrer cette entit comme un prestataire de TRA

(Tierce Recette Applicative).

Lobjectif principal de cette organisation est doptimiser en temps et ressources

toutes les activits dassurance qualit lies une livraison planifie2 de version

dun systme dinformation, quel que soit le type dvolution.

Pour atteindre cet objectif, son rle est double : lun est daccompagner le pilotage

de la qualit globale du projet depuis les spcifications jusqu la mise en

production, lautre est de certifier tout moment la conformit dune livraison

afin de garantir la fiabilit oprationnelle requise.

A chaque livraison, les responsables de qualification ou de recette doivent

sappuyer sur des stratgies qui leur permettent dvaluer, piloter et grer leurs

activits de test efficacement tout en sinscrivant dans un cadre de gestion des

risques oprationnels.

2Mais aussi dans le cas dun correctif dployer rapidement (rarement planifi).


5/10

WHITE PAPER

5

QQUU EELLSSSSOO NN TT LL EESS PPRROO BBLL EEMM EE SS??

Commenons par regrouper quelques situations rencontres couramment :

1)A la fin des tests, seule 50% de la couverture fonctionnelle est teste et les

mmes tests sont sans cesse rpts (inefficience des tests).

2)Malgr des campagnes de test menes jusquau bout, la fiabilit du

systme savre insuffisante au vu des incidents rencontrs en production

(inefficacit des tests).

3)Aprs des volutions mineures exiges par les entits mtiers et testes

normalement, le systme sest dgrad (non pertinence des tests).

Tout comme une numration de symptmes ne suffit pas, il nous faut analyser

les causes des problmes rencontrs lors des phases de qualification et de recette

pour identifier des solutions. Des tudes empiriques3 publies aprs desrecherches scientifiques listent des causes originelles parmi lesquelles :

La qualit structurelledu code nest pas au niveau requis. Dans ce cas, la

phase de validation se confronte des problmes qui auraient d tre

limins en amont car lis un dficit dans les pratiques de dveloppement

qui engendrent des dfauts fonctionnels.

La maintenabilitet lvolutivitdu code ne sont pas suffisantes. Chaque

modification exige plus deffort et a des impacts plus larges sur

lapplication; cela augmente dautant le risque de rgressions. Enconsquence, leffort de test sera trs important chaque version, mme

mineure.

Les impactsdes modifications ralises ne sont pas correctement perus, ou

alors de manire trop tardive, et les campagnes de test ne sappuient pas sur

les risques rels de rgressionsselon les fonctionnalits impactes par le code

modifi. Il est par exemple frquent que des bugs soient crs lors des

dernires corrections livres en fin de validation pour lesquelles il est

impossible de rejouer lensemble des tests.

Le manque de visibilit sur le contenu du livrable reu rend difficile la mise

en place dune stratgie de tests base sur une collaboration efficaceentre

tous les acteurs. Les testeurs ne peuvent pas optimiser leurs efforts, les

entits mtiers ne reoivent pas les informations ncessaires lvaluat ion

des risques mtiers, et lexploitation na pas de visibilit prcise 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.


6/10

WHITE PAPER

6

La consquence frquente de ces diffrents points : un nombre de livraisons trop

important pour une mme phase de validation. Chaque livraison supplmentaire

augmente les cots et la dure des tests, les risques de rgressions non dtectes,

et retarde la mise en production.

LL EEXXAAMMEENN RRAADDIIOO GGRRAAPPHH IIQQ UU EE

Evaluer ces risques en amont de la rception de chaque livraison, en disposant

dune vision prcise 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 leffort de test ncessaire la validation4 de cette version,

Orienter les efforts de test sur les bons composants et fonctionnalits au

moment opportun,

Rduire le nombre ditrations ncessaires la validation dune version5.

La cl rside dans une radiographie des livraisons qui apporte chacun une

information objective :

Evaluer la densit potentielle de dfauts en effectuant une validation

qualit base sur des techniques danalyse du code source. Restituer les risques projets et mtier au travers dune validation

produit avec une vision rapide sur les impacts directs et indirects

(rgressions) des volutions ralises.

Donner aux entits de production une vision instantane sur les

changements dployer et les ventuels problmes dintgration grce

une validation version .

Pour satisfaire ces trois validations et donner une visibilit complte sur

lapplication (360), la radiographie doit analyser des domaines complmentaireset agrger les rsultats pour fournir une synthse pertinente et exploitable. En

couvrant les 8 domaines prsents ci-aprs, une plateforme de radiographie

devient une source dinformations riche pour planifier, piloter et grer les

activits de validation. En disposer chaque livraison vite de se lancer

laveugle dans une phase de qualification ou de recette.

4Validation sentend au sens du modle V&V, savoir toutes les activits de test en

qualification et recette

5 Chaque itration correspond une livraison et apporte de nouveaux risques de

rgressions. Le nombre de bugs introduits lors de modifications pendant la

validation est estim 8%.


7/10

WHITE PAPER

7

FIGURE 2:PERIMETRE DUNE RADIOGRAPHIE 360

Lagrgation et la restitution des informations doivent se faire en utilisant un

prisme adapt aux besoins de chaque acteur. Ainsi, une restitution base sur

larchitecture fonctionnelle, comme illustre 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 modifies & risques rgressions)

CCOO MMMMEENNTT PPRROODDUU IIRR EE CCEE TT TT EE RRAADD IIOO GGRRAAPPHH IIEE

Pour raliser cette radiographie, la plateforme Kalistick conjugue plusieurs

techniques danalyse de lapplication6afin dobtenir des informations pertinentes

et complmentaires, et les restitue de manire adapte aux besoins des diffrents

acteurs de la validation.

FIGURE 4:PROCESSUS DE RADIOGRAPHIE

6 Ces techniques sont issues des recherches menes en collaboration avec les

laboratoires de lInsa de Lyon et du CETIC, et ont t primes par le Ministre de la

Recherche en 2008.


8/10

WHITE PAPER

8

Les techniques appliques sont :

Analyse statique du code, il sagit dune technique qui se rapproche de la

boite blanche pour dtecter les potentiels problmes techniques et

structurels.

Analyse des architectures technique et fonctionnelle pour recomposer son

organisation interne, pouvoir en vrifier la cohrence et restituer les

informations sur un angle fonctionnel.

Analyse des variations entre chaque livraison avec la version en production,

pour retrouver les modifications ralises, valuer les risques associs et

ainsi pouvoir affecter les bonnes priorits aux tests raliser.

Analyse des tests raliss par les quipes de dveloppement avant la

livraison, de leur couverture des modifications ralises, pour dtecter les

points insuffisamment tests ou viter de focaliser tous les efforts de tests

sur les mmes lments.

La combinaison de ces diffrents axes danalyse et la visibilit quelle donne des

applications forme une approche que nous qualifions de boite grise pour sa

capacit restituer sur le plan fonctionnel une analyse interne de lapplication, de

ses variations et de ses risques.

CCAARRAACC TT EE RR IISS TT IIQQ UU EESSSSUU PP PPLL EEMMEE NN TT AA IIRR EESSDD EE LL AAPPLL AA TTEEFFOORRMMEEDD EE

RRAADDIIOOGGRR AAPPHH IIEE

Pour maximiser lefficacit de la dmarche, cette radiographie doit se faire

chaque livraison et sintgrer de manire fluide dans les processusexistants.

Pour cela, il est important quelle soit automatise, que ses rsultats soient

disponibles en quelques heures et accessibles facilement lensemble des acteurs

internes ou externes pour disposer dun rfrentiel commun Pour les projets

offshore, il est important davoir une plateforme multilingue accessible par

Internet de manire scurise pour partager la visibilit acquise sur lapplication.

En outre, permettre un accs lquipe de dveloppement est primordial carlexprience montre quilest galement souhaitable de disposer dune

radiographie anticipe, en amont de la livraison officielle (quelques semaines) afin

de disposer de plus de temps pour adapter sa stratgie de validation aux risques

dtects.

En complment, il faut bien sr que la solution ne soit pas structurante et quelle

ne gnre pas une charge dexploitation qui la rendrait trop coteuse notamment

durant les phases de maintenance corrective de lapplication radiographier.

Enfin, si elle sappuie sur une base de connaissance pour dtudier la corrlation

relle entre les rsultats de la radiographie et les taux de panne rellement

observs en production, cela permet lamlioration continue de la radiographie et

donc des validations.


9/10

WHITE PAPER

9

La plateforme Kalistick offre ces caractristiques notamment grce au mode SaaS

(Software as a Service), c'est--dire accessible par Internet par tous les acteurs du

projet, dans diffrentes langues, et intgres avec les plateformes de

dveloppement et de test (ALM - Application Life-Cycle Management).

LLEESS BBEE NNEEFFIICCEE SS DDEE CC EE TT TT EE VV IISS IIBB IILL IITT EE PPOOUU RRLL AA VVAALL IIDD AATT IIOONN

Apporter au chef de projet et aux responsables dentits concernes par la

validation les moyens danticiper sur les risques potentiels, den valuer les

impacts techniques et mtier en utilisant une perspective technique ou

fonctionnelle selon leur rle est une vraie innovation et apporte des bnfices trs

concrets :

AA NN TT II CCII PP EE RRLLEESS PP RR OO BB LL EEMM EE SS

Ce premier bnfice est trs tangible : lanticipation sur la validation. Car

lanalyse des rsultats des radiographies ralises montre que trop souvent on

sattaque la validation dune version instable pas rellement teste en

dveloppement. Cette situation apparait gnralement bien tard lorsque lon a

reu de multiples livraisons pour une mme version avec chaque livraison de

nouvelles rgressions provoques par des remaniements du code inattendus.

Avoir une vision de la version recevoir quelques semaines avant sa rception

effective et sappuyer sur des indicateurs factuels pour estimer leffort de tests

raliser et les risques potentiels apporte une capacit danticipation forte la DSI.Comme le montre des tudes, telles celles de Capers Jones7, le cot et la dure de

validation augmentent de 50% lorsque lon est face une application

pathologique8 . Avoir cette information est donc capital.

AA UU GG MMEE NN TT EE RR LL EEFF FFII CC AACC II TT EE DD EESS TT EESS TT SS

Disposer chaque livraison dune vision prcise des modifications ralises, telles

des releases notes , accompagne par une analyse dimpact de ces changements

sur les plans techniques ou fonctionnels, augmente significativement la

pertinence des efforts de tests. Cela vite galement lapparition de nouveaux

bugs introduits avec les dernires corrections ralises peu avant la mise en

production.

AA SS SS UU RR EE RR LL AA SS TT AABB II LL II TT EEDD EELL AAQQ UU AALLII TT EE

Lors du dploiement dune nouvelle version, on cherche toujours sassurer que

la qualit est minima quivalente la version prcdente en identifiant les

nouveaux problmes ; car soit les anciens sont connus et considrs comme non

7Cf. note 1 : Capers Jones, Software Quality in 2010.

8Dans un tat de faible qualit.


10/10

WHITE PAPER

10

prioritaires, soit pas encore dcouverts et donc potentiellement moins graves

car ils ne gnent pas le fonctionnement actuel en production. Avoir la

visibilit sur ce diffrentiel est donc essentiel pour viter la dgradation de

lapplication au fur et mesure de ses volutions et lapparition de nouveaux

risques.

CC OO NN TT RR OO LLEE RRLL EESS RR II SS QQ UU EE SS DDEE DD EE PP LL OO II EE MM EENN TT DD UU NN CCOORR RR EE CC TT II FF

Lors de la rception dun correctif dployer rapidement, la capacit de test est

limite et la dcision de dploiement repose sur une analyse des risques pour

viter des dysfonctionnements en chane. L encore, disposer dune radiographie

immdiate est synonyme dune analyse des risques matrise. Dautant plus si on

ajoute la possibilit pour la production didentifier prcisment le d iffrentiel par

rapport la version dj dploye, par exemple sur la configuration ou les

librairies tierces.

AA GGII RR SS UU RRLL AAQQ UU AA LL II TT EE EE NN AA MM OO NN TT

Notons que les validations effectues permettent non seulement destimer les

probabilits de risques mtiers ainsi que les impacts potentiels, mais galement et

surtout, la valeur du code dj fourni et test. Base sur un rfrentiel qualit

tabli, les rsultats font frquemment ressortir des opportunits doptimisation

ou dadaptation des processus dingnierie logicielle en amont.

CCOO NNCCLLUUSS IIOO NN

Disposer de cette nouvelle visibilit pour une application est un moyen efficace

pour Tester Juste et ainsi amliorer quatre dimensions de sa validation :

Sassurer avant le lancement des tests que le produit est au niveau de

qualit exig.

Augmenter lefficacit des activits de tests.

Maitriser les risques de mise en production.

Faciliter la gestion des risques projets.

Ltude des radiographies de plusieurs centaines dapplications reprsentant plus

de 100 millions de lignes de code montrent leffet de levier que reprsente cette

visibilit pour la validation. Car lorsque cette approche boite grise laisse

entrevoir des difficults, une approche traditionnelle de la validation de type

boite noire se traduit des risques non-maitriss avec des retards

imprvisibles et des instabilits en production.

Copyright Kalistick 2010.Tous droits rservs.

[email protected]
http://www.kalistick.fr/http://www.kalistick.fr/mailto:[email protected]:[email protected]:[email protected]:[email protected]://www.kalistick.fr/

réduire les coûts de test et accélérer la validation

Documents