Your SlideShare is downloading. ×
Accélérer les tests et la validation de logiciels
Accélérer les tests et la validation de logiciels
Accélérer les tests et la validation de logiciels
Accélérer les tests et la validation de logiciels
Accélérer les tests et la validation de logiciels
Accélérer les tests et la validation de logiciels
Accélérer les tests et la validation de logiciels
Accélérer les tests et la validation de logiciels
Accélérer les tests et la validation de logiciels
Accélérer les tests et la validation de logiciels
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Accélérer les tests et la validation de logiciels

1,307

Published on

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

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,307
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
51
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. WHITE PAPERRadiographier 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), cest-à-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

×