SlideShare une entreprise Scribd logo
WHITE PAPER




Radiographier une application
   pour « Tester Juste ».
     Un nouveau regard pour la validation




             Copyright Kalistick 2010
              Tous droits réservés.
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
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
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
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
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
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
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
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
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

Contenu connexe

Tendances

Types de tests vs techniques de tests
Types de tests vs techniques de testsTypes de tests vs techniques de tests
Types de tests vs techniques de tests
Sabrine MASTOURA
 
Altran soirée du test logiciel - assez des c 05-10-17
Altran   soirée du test logiciel - assez des c 05-10-17Altran   soirée du test logiciel - assez des c 05-10-17
Altran soirée du test logiciel - assez des c 05-10-17
Marc Hage Chahine
 
Keynote Retmo2018 : le test QA et UAT en méthode agile
Keynote Retmo2018 : le test QA et UAT en méthode agileKeynote Retmo2018 : le test QA et UAT en méthode agile
Keynote Retmo2018 : le test QA et UAT en méthode agile
StardustTesting
 
Assurance Qualité S O A
Assurance Qualité  S O AAssurance Qualité  S O A
Assurance Qualité S O A
guestb55335
 
Test logiciel
Test logicielTest logiciel
Test logiciel
Youness Boukouchi
 
Modèle en cascade
Modèle en cascadeModèle en cascade
Modèle en cascade
Ghodhbane Mohamed Amine
 
Test de logiciels
Test de logiciels Test de logiciels
Test de logiciels
Bilel Abed
 
Métriques de qualité logicielle
Métriques de qualité logicielleMétriques de qualité logicielle
Métriques de qualité logicielle
Youness Boukouchi
 
Introduction à la qualité logicielle (1/5)
Introduction à la qualité logicielle (1/5)Introduction à la qualité logicielle (1/5)
Introduction à la qualité logicielle (1/5)
Sylvain Leroy
 
Qualité logiciel - Generalités
Qualité logiciel - GeneralitésQualité logiciel - Generalités
Qualité logiciel - Generalités
Christophe Rochefolle
 
Démarche Qualité Totale, Amdec safe amp50 hagondange
 Démarche Qualité Totale, Amdec safe amp50 hagondange Démarche Qualité Totale, Amdec safe amp50 hagondange
Démarche Qualité Totale, Amdec safe amp50 hagondange
SAGITEC
 
Introduction à la validation de logiciel
Introduction à la validation de logicielIntroduction à la validation de logiciel
Introduction à la validation de logiciel
Jean-Paul CARMONA
 
Qualite1
Qualite1Qualite1
Qualite1
Rachid Lajouad
 
20090113 03 - Exigences et mise en oeuvre du processus mesure et analyse
20090113 03 - Exigences et mise en oeuvre du processus mesure et analyse20090113 03 - Exigences et mise en oeuvre du processus mesure et analyse
20090113 03 - Exigences et mise en oeuvre du processus mesure et analyse
LeClubQualiteLogicielle
 
La méthode amdec
La méthode amdecLa méthode amdec
La méthode amdec
sabir sehli
 
Exposé amdec
Exposé amdecExposé amdec
Exposé amdec
Arwa Mohamed Baccouche
 
3-Cours de Géniel Logiciel
3-Cours de Géniel Logiciel3-Cours de Géniel Logiciel
3-Cours de Géniel Logiciel
lauraty3204
 

Tendances (20)

Types de tests vs techniques de tests
Types de tests vs techniques de testsTypes de tests vs techniques de tests
Types de tests vs techniques de tests
 
Amdec
AmdecAmdec
Amdec
 
Amdec
AmdecAmdec
Amdec
 
Altran soirée du test logiciel - assez des c 05-10-17
Altran   soirée du test logiciel - assez des c 05-10-17Altran   soirée du test logiciel - assez des c 05-10-17
Altran soirée du test logiciel - assez des c 05-10-17
 
Keynote Retmo2018 : le test QA et UAT en méthode agile
Keynote Retmo2018 : le test QA et UAT en méthode agileKeynote Retmo2018 : le test QA et UAT en méthode agile
Keynote Retmo2018 : le test QA et UAT en méthode agile
 
Assurance Qualité S O A
Assurance Qualité  S O AAssurance Qualité  S O A
Assurance Qualité S O A
 
Test logiciel
Test logicielTest logiciel
Test logiciel
 
Modèle en cascade
Modèle en cascadeModèle en cascade
Modèle en cascade
 
Test de logiciels
Test de logiciels Test de logiciels
Test de logiciels
 
Métriques de qualité logicielle
Métriques de qualité logicielleMétriques de qualité logicielle
Métriques de qualité logicielle
 
Introduction à la qualité logicielle (1/5)
Introduction à la qualité logicielle (1/5)Introduction à la qualité logicielle (1/5)
Introduction à la qualité logicielle (1/5)
 
Qualité logiciel - Generalités
Qualité logiciel - GeneralitésQualité logiciel - Generalités
Qualité logiciel - Generalités
 
Démarche Qualité Totale, Amdec safe amp50 hagondange
 Démarche Qualité Totale, Amdec safe amp50 hagondange Démarche Qualité Totale, Amdec safe amp50 hagondange
Démarche Qualité Totale, Amdec safe amp50 hagondange
 
Introduction à la validation de logiciel
Introduction à la validation de logicielIntroduction à la validation de logiciel
Introduction à la validation de logiciel
 
Qualite1
Qualite1Qualite1
Qualite1
 
20090113 03 - Exigences et mise en oeuvre du processus mesure et analyse
20090113 03 - Exigences et mise en oeuvre du processus mesure et analyse20090113 03 - Exigences et mise en oeuvre du processus mesure et analyse
20090113 03 - Exigences et mise en oeuvre du processus mesure et analyse
 
La méthode amdec
La méthode amdecLa méthode amdec
La méthode amdec
 
Exposé amdec
Exposé amdecExposé amdec
Exposé amdec
 
3-Cours de Géniel Logiciel
3-Cours de Géniel Logiciel3-Cours de Géniel Logiciel
3-Cours de Géniel Logiciel
 
A.m.d.e.c
A.m.d.e.c A.m.d.e.c
A.m.d.e.c
 

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

Tester les applications plus efficacement
Tester les applications plus efficacementTester les applications plus efficacement
Tester les applications plus efficacement
kalistick
 
qualité logicielle (8).pdf
qualité logicielle (8).pdfqualité logicielle (8).pdf
qualité logicielle (8).pdf
NoamHaythem
 
Projets d'évolution ERP
Projets d'évolution ERPProjets d'évolution ERP
Projets d'évolution ERP
panayaofficial
 
les metriques de processus, de produit et de qualité
les metriques de processus, de produit et de qualitéles metriques de processus, de produit et de qualité
les metriques de processus, de produit et de qualité
soregh
 
formation istqb.pdf
formation istqb.pdfformation istqb.pdf
formation istqb.pdf
mido04
 
Présentation événement dette technologique micropole
Présentation événement dette technologique micropolePrésentation événement dette technologique micropole
Présentation événement dette technologique micropoleMicropole Group
 
Evolution des Exigences pour la Reconnaissance des Compétences LES ENJEUX DE ...
Evolution des Exigences pour la Reconnaissance des Compétences LES ENJEUX DE ...Evolution des Exigences pour la Reconnaissance des Compétences LES ENJEUX DE ...
Evolution des Exigences pour la Reconnaissance des Compétences LES ENJEUX DE ...
Pasteur_Tunis
 
Article de référence de Winston Royce
Article de référence de Winston RoyceArticle de référence de Winston Royce
Article de référence de Winston Royce
Fabrice Aimetti
 
Préparation continue des applications en six étapes
Préparation continue des  applications en six étapesPréparation continue des  applications en six étapes
Préparation continue des applications en six étapes
Flexera
 
L'Approche SMV de COGENIT
L'Approche SMV de COGENITL'Approche SMV de COGENIT
L'Approche SMV de COGENIT
Sany_M
 
Génie Logiciel.pptx
Génie Logiciel.pptxGénie Logiciel.pptx
Génie Logiciel.pptx
LatifaBen6
 
Bonnes pratiques : la hiérarchie des exigences
Bonnes pratiques : la hiérarchie des exigencesBonnes pratiques : la hiérarchie des exigences
Bonnes pratiques : la hiérarchie des exigencesCaroline de Villèle
 
Analyse de code: accélérez la validation de vos applications C#
Analyse de code: accélérez la validation de vos applications C#Analyse de code: accélérez la validation de vos applications C#
Analyse de code: accélérez la validation de vos applications C#
kalistick
 
Lssgrb formation-lean-six-sigma-green-belt-2eme-niveau
Lssgrb formation-lean-six-sigma-green-belt-2eme-niveauLssgrb formation-lean-six-sigma-green-belt-2eme-niveau
Lssgrb formation-lean-six-sigma-green-belt-2eme-niveauCERTyou Formation
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
Erradi Mohamed
 
RE: Les risques lies a l'amelioration continue
RE: Les risques lies a l'amelioration continueRE: Les risques lies a l'amelioration continue
RE: Les risques lies a l'amelioration continue
Francois Salazar
 
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels JavaAnalyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
kalistick
 
La qualité au service de vos projets digitaux ! Retour sur le PDJ co-organisé...
La qualité au service de vos projets digitaux ! Retour sur le PDJ co-organisé...La qualité au service de vos projets digitaux ! Retour sur le PDJ co-organisé...
La qualité au service de vos projets digitaux ! Retour sur le PDJ co-organisé...
Julie DULOT
 
Tirer profit d'un outillage de gestion des exigences
Tirer profit d'un outillage de gestion des exigencesTirer profit d'un outillage de gestion des exigences
Tirer profit d'un outillage de gestion des exigences
EchoesLabs
 
Le Contrôle Interne Assisté par Ordinateur
Le Contrôle Interne Assisté par OrdinateurLe Contrôle Interne Assisté par Ordinateur
Le Contrôle Interne Assisté par Ordinateurmohammed EZZOUAK
 

Similaire à Accélérer les tests et la validation de logiciels (20)

Tester les applications plus efficacement
Tester les applications plus efficacementTester les applications plus efficacement
Tester les applications plus efficacement
 
qualité logicielle (8).pdf
qualité logicielle (8).pdfqualité logicielle (8).pdf
qualité logicielle (8).pdf
 
Projets d'évolution ERP
Projets d'évolution ERPProjets d'évolution ERP
Projets d'évolution ERP
 
les metriques de processus, de produit et de qualité
les metriques de processus, de produit et de qualitéles metriques de processus, de produit et de qualité
les metriques de processus, de produit et de qualité
 
formation istqb.pdf
formation istqb.pdfformation istqb.pdf
formation istqb.pdf
 
Présentation événement dette technologique micropole
Présentation événement dette technologique micropolePrésentation événement dette technologique micropole
Présentation événement dette technologique micropole
 
Evolution des Exigences pour la Reconnaissance des Compétences LES ENJEUX DE ...
Evolution des Exigences pour la Reconnaissance des Compétences LES ENJEUX DE ...Evolution des Exigences pour la Reconnaissance des Compétences LES ENJEUX DE ...
Evolution des Exigences pour la Reconnaissance des Compétences LES ENJEUX DE ...
 
Article de référence de Winston Royce
Article de référence de Winston RoyceArticle de référence de Winston Royce
Article de référence de Winston Royce
 
Préparation continue des applications en six étapes
Préparation continue des  applications en six étapesPréparation continue des  applications en six étapes
Préparation continue des applications en six étapes
 
L'Approche SMV de COGENIT
L'Approche SMV de COGENITL'Approche SMV de COGENIT
L'Approche SMV de COGENIT
 
Génie Logiciel.pptx
Génie Logiciel.pptxGénie Logiciel.pptx
Génie Logiciel.pptx
 
Bonnes pratiques : la hiérarchie des exigences
Bonnes pratiques : la hiérarchie des exigencesBonnes pratiques : la hiérarchie des exigences
Bonnes pratiques : la hiérarchie des exigences
 
Analyse de code: accélérez la validation de vos applications C#
Analyse de code: accélérez la validation de vos applications C#Analyse de code: accélérez la validation de vos applications C#
Analyse de code: accélérez la validation de vos applications C#
 
Lssgrb formation-lean-six-sigma-green-belt-2eme-niveau
Lssgrb formation-lean-six-sigma-green-belt-2eme-niveauLssgrb formation-lean-six-sigma-green-belt-2eme-niveau
Lssgrb formation-lean-six-sigma-green-belt-2eme-niveau
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
 
RE: Les risques lies a l'amelioration continue
RE: Les risques lies a l'amelioration continueRE: Les risques lies a l'amelioration continue
RE: Les risques lies a l'amelioration continue
 
Analyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels JavaAnalyse de code source: accélérer la validation des logiciels Java
Analyse de code source: accélérer la validation des logiciels Java
 
La qualité au service de vos projets digitaux ! Retour sur le PDJ co-organisé...
La qualité au service de vos projets digitaux ! Retour sur le PDJ co-organisé...La qualité au service de vos projets digitaux ! Retour sur le PDJ co-organisé...
La qualité au service de vos projets digitaux ! Retour sur le PDJ co-organisé...
 
Tirer profit d'un outillage de gestion des exigences
Tirer profit d'un outillage de gestion des exigencesTirer profit d'un outillage de gestion des exigences
Tirer profit d'un outillage de gestion des exigences
 
Le Contrôle Interne Assisté par Ordinateur
Le Contrôle Interne Assisté par OrdinateurLe Contrôle Interne Assisté par Ordinateur
Le Contrôle Interne Assisté par Ordinateur
 

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

  • 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