Cegedim Activ cherchait à industrialiser ses processus de test pour son nouveau logiciel Activ’Ro, Kalistick a apporté une brique indispensable à la solution.

Retour sur le déploiement de l’outil au sein de la société avec la Responsable  de la Cellule Certification Qualité Pilotage de Cegedim Activ, Anne-Marie Bailly.

Cegedim Activ Chiffres Clés

• Editeur de logiciel
• 500 collaborateurs
• 9 sites
• 74 M€ de CA en 2011,
• 30 millions de personnes protégées

Le groupe Cegedim propose des prestations de services, des outils informatiques, des logiciels spécialisés et des services de gestion de flux et de bases de données à l’ensemble des acteurs de la Santé :

• - industries,
• - laboratoires pharmaceutiques,
• - professionnels de santé,
• - compagnies d’assurance.

Au sein de Cegedim Assurances, Cegedim Activ est le leader des logiciels et services dédiés à l’Assurance de Personnes sur le marché français.

Application: Activ’Ro

• Logiciel SaaS
• Développement en mode Agile et cycle en V
• En phase d’industrialisation du processus de test
• Cible : organismes gestionnaires de régimes maladie obligatoire

“Nous étions à la recherche de ce type d’outils, sans savoir si cela existait déjà.” Objectifs

• Industrialiser le processus de tests sur une application-clé mais relativement jeune
• Identifier la couverture de tests actuels sur la solution, créer de nouveaux scénarios, et augmenter l’automatisation des tests (outil Selenium).
• Monter en qualité sur les versions logicielles fournies aux organismes clients
• Faciliter le passage vers un modèle Agile

La solution Kalistick Kalistick, un levier prometteur d’industrialisation du processus de test

Cegedim Activ commercialise et maintient six solutions logicielles sur lesquelles des batteries de tests sont régulièrement effectuées. Mais en 2009, lorsque la société décide de lancer la commercialisation d’Activ’Ro, sa nouvelle solution en  mode hébergé de gestion du régime maladie obligatoire (sections locales mutualistes, travailleurs non salariés…), aucun test de non-régression (TNR) automatisé n’est véritablement mis en oeuvre.

«Il y avait bien entendu des recettes et des  tests de régressions manuels déjà mis en place, confie Madame Anne-Marie Bailly, Responsable de la cellule Certification Qualité Pilotage de Cegedim Activ. Mais le chantier d’automatisation des tests avec l’outil Selenium était encore devant nous, et nous  souhaitions avancer sans tarder.»

C’est à ce moment qu’Anne-Marie Bailly assiste à un webinar sur Kalistick.

«Nous étions à la recherche de ce type d’outils, sans savoir si cela existait déjà… Et nous avons été impressionnés par la solution qui nous a été présentée.»

Kalistick  s’est rapidement imposé comme l’outil-clé dans l’industrialisation du processus de test pour Activ’Ro.

Parfaitement complémentaire aux outils d’automatisation et aux référentiels de tests tels que HP QC, XStudio ou Selenium, Kalistick est  une solution particulièrement innovante et unique permettant de détecter les “trous de test” c’est dire tout ce qui échappe à nos tests et plus particulièrement les modifications et leurs effets de bords éventuels.

La solution nous permet notamment de construire de nouveaux scénarios de tests de non-régression, afin d’améliorer la couverture de ces derniers et d’augmenter ainsi la qualité logicielle des versions livrées.

Vers l’implémentation de la solution “L’outil Kalistick fonctionne parfaitement, bien que notre logiciel soit complexe et contienne plus de deux millions de lignes de code.”Anne-Marie Bailly

Trop beau pour être vrai ? Un POC (Proof of Concept) est alors mis en place, afin de vérifier la promesse offerte par l’outil Kalistick et valider sa compatibilité avec la nouvelle solution de Cegedim Activ.

Il s’agit de vérifier les bénéfices pour Activ’Ro, solution pour laquelle les organismes clients se montrent particulièrement exigeants en terme de qualité, mais où leurs moyens financiers ne permettent pas toujours d’affecter suffisamment de ressources humaines dans les phases de recette.

«Le pilote a répondu à l’intégralité de nos exigences, déclare Anne-Marie Bailly. L’outil Kalistick fonctionne parfaitement, bien que notre logiciel soit complexe et contienne plus de deux millions de lignes de code.»

Rassurer sur la sécurité du code

Ceci étant, il convenait également de rassurer complètement Cegedim Activ sur le fonctionnement de Kalistick. Sur ce secteur sensible et concurrentiel qu’est la Santé, la sécurité du code des solutions logicielles déployées est primordiale.

«Notre outil est construit sur un mode hybride “On premise/Cloud”, confie Marc Rambert, directeur de la société Kalistick. Les modules “Scan de l’application” et «Empreintes de tests” sont installés chez le client, et l’analyse et les tableaux de bord sont hébergés dans le Cloud.»

Mais l’un des vrais points forts de Kalistick réside dans le fait qu’aucune ligne de code n’est envoyée dans le Cloud ce qui lui garantit une sécurité totale à ce niveau.

La transparence est fortement appréciée par Cegedim Activ et la solution, qui allie la sécurité du “On premise” et les avantages du SaaS, tant au niveau du business model (abonnement simple) qu’au niveau de la maintenance (pas de serveur dédié en interne), est définitivement adoptée par la société.

“L’un des autres avantages de Kalistick est qu’il permet de déterminer précisément les tests qui doivent être joués et donc de gagner un temps précieux.” Aller plus loin encore

«La compétence et la grande réactivité des experts que nous avons rencontré au sein de la société Kalistick, notamment pour l’intégration à XStudio et autres outils que nous utilisons, a également joué dans notre décision, confie Madame Bailly.»

Cegedim Activ souhaite s’appuyer sur la solution pour faciliter la transition vers les méthodes agiles sur l’ensemble de ses solutions, alors qu’aujourd’hui une partie des développements se font toujours sur un cycle en V.

En effet, selon Anne-Marie Bailly, «l’un des autres avantages majeurs de Kalistick est qu’il permet de déterminer précisément les tests qui doivent être joués, car portant sur la partie du code qui a été modifiée, de ceux qu’il est inutile de lancer car portant sur une partie du code non-affectée par les développements effectués d’une version à l’autre.

C’est une fonctionnalité décisive quand on décide de raccourcir les délais de mise sur les marchés des solutions».

Pour aller vers une qualité totale sur deux applications centrales de contrôle métier, CNP assurances décide de s’appuyer sur Kalistick.

L’approche véritablement hors-norme que permet l’outil, et notamment la couverture intelligente qu’il  offre, s’avère être un levier déterminant pour l’optimisation du processus de tests.

CNP Assurances

Chiffres Clés

• Compagnie d’assurances
• CA 2011 : 31 M€
• 40+ millions d’assurés à travers le monde

CNP Assurances est le premier assureur de personnes en France avec un chiffre d’affaires de 31 milliards d’euros en 2011.

Spécialisé depuis 150 ans sur ce métier, l’ambition du groupe est de fournir à chacun les moyens de se prémunir contre  les aléas de la vie et de l’accompagner tout au long de son existence.

Il compte 23 millions d’assurés en épargne/prévoyance dans le monde et 17 millions en couverture de prêts.

Applications : INS et IDD

• Applications de contrôle métier
• Cible : Applications clientes internes et externes pour des partenaires (banques…)
• En phase d’industrialisation du processus de test

“Nous désirions optimiser l’ensemble de nos tests sur nos applications-clés.” Enjeux

• Monter en qualité sur ces applications clés au coeur du SI Assurances Individuelles
• Identifier la couverture de tests actuels sur les applications et créer de nouveaux scénarios de tests
• Monter en puissance et optimiser les processus de tests

La solution Kalistick La maitrise de risques : un aspect-clé pour les applications métiers de CNP Assurances

Une partie du coeur du système d’informations de la branche “Assurance individuelle” du groupe CNP Assurances repose sur deux applications phares : INS et IDD.

Applications- clés de contrôle métier, ces solutions ne comportent pas  d’interface utilisateur en elles-mêmes, mais communiquent par webservices avec un grand nombre d’applications clientes déployées au sein du groupe et chez de nombreux partenaires, issus du monde bancaire notamment, pour l’instruction  de demandes (INS) et l’instruction de dossiers (IDD) d’assurances individuelles.

La qualité de ces applications de contrôle métier revêt donc une importance de premier ordre pour CNP Assurances et pour ses partenaires, car un grand  nombre de solutions logicielles reposent sur elles.

Développées sur un mode d’intégration continue, elles font donc l’objet de nombreux tests unitaires et fonctionnels automatisés.

Une solution complémentaire aux outils d’automatisation et aux référentiels

Mais pour CNP Assurances, il s’agissait d’aller plus loin encore dans la qualité recherchée.

«C’est dans cette optique que nous nous sommes intéressés à la solution Kalistick, confie Madame Christine Brosseau, Responsable de cellule de tests DMOE. Nous désirions en effet optimiser l’ensemble de nos tests sur ces deux applications-clés.» Car Kalistick ne s’inscrit pas dans la classique dichotomie entre les logiciels d’automatisation d’une part, et les référentiels de test d’autre part.

L’atout de cette solution est qu’elle n’a vocation à remplacer ni les uns ni les autres, mais à s’y intégrer afin d’assurer à l’entreprise une forte visibilité sur les tests qu’elle effectue, leur couverture et les risques de régression non-couverts.

«En enregistrant l’empreinte de chaque test, Kalistick est capable, à partir de l’ensemble des tests automatisés et manuels définis, de signaler en amont à l’éditeur les tests les plus importants à exécuter et ceux qui sont plus accessoires, et donc de gagner du temps. En aval il indique avec précision les “trous de test” à combler, c’est à dire les parties du code modifiés sur lesquelles aucun test n’a encore été joué», précise Christine Brosseau.

Sécurisation et implémentation sur INS et IDD

Mais l’outil doit d’abord convaincre CNP Assurances que le code de ses applications reste sécurisé, et la réponse apportée par la société Kalistick est sans équivoque.

Si l’outil est de nature hybride «on-premises/Cloud», c’est à dire avec une partie “scan de l’application et enregistrement des empreintes de tests” effectuée chez le client et une partie “analyse” hébergée sur le Cloud, aucune ligne de code n’est pour autant envoyée vers le Cloud.

La confirmation a été apportée directement par la technologie Kalistick qui utilise des techniques de signature, un peu à la manière d’un antivirus, et assure ainsi qu’aucun code source ou binaire ne quitte jamais le système de CNP Assurances.

Un POC (Proof of Concept) est donc réalisé en début d’année 2012 sur INS, pour qui près de 800 à 1000 tests fonctionnels existent, ce qui est bien évidemment très important pour une application sans IHM. Et très vite, les bénéfices-clés de Kalistick se confirment, et le groupe décide alors de travailler en parallèle à une mise en oeuvre de l’outil sur d’autres applications.

Des modes d’utilisation variés et des atouts nombreux “Pour INS, Kalistick nous permet d’identifier précisément d’éventuels doublons et trous de tests jusque là passés inaperçus.”

Divers bénéfices-clés, et donc différents modes d’utilisation possible apparaissent en effet à CNP Assurances.

«IDD est une application métier beaucoup plus jeune et plus légère que INS, explique Christine Brosseau. Par conséquent, le nombre de tests fonctionnels existants est plus faible. Dans ce contexte, nous attendions de Kalistick qu’il nous donne une vision très précise de la couverture de test existante, afin de pouvoir travailler à l’amélioration de celle-ci en sachant précisément quels nouveaux scénarios de tests il nous fallait créer.»

«Pour INS, ajoute Christine Brosseau, où nous disposons de nombreux tests, mais peu référencés, Kalistick nous permet d’identifier précisément d’éventuels doublons et trous de tests jusque là passés inaperçus, car indécelables sans ce type d’outil.»

En effet, contrairement aux logiciels qui identifient les couvertures de tests strate par strate (tests unitaires, test d’intégration et tests fonctionnels), Kalistick offre une vision transversale des tests qui se révèle donc beaucoup plus juste. C’est pourquoi, on parlera volontiers de “couverture de test intelligente”.

Optimiser les référentiels de tests était également un bénéfice attendu de la solution. Tous les deux à trois mois environ, la cellule de tests procède à une “revue de tests”, afin d’identifier lesquels sont devenus “obsolètes” et peuvent être sortis du référentiel, car ils n’ont plus besoin d‘être joués.

«En résumé, Kalistick nous apporte des bénéfices sur de multiples niveaux, conclut Christine Brosseau et nous sommes déjà en train d’étendre son utilisation à une nouvelle application web.»

 

Evaluer la maturité d’une organisation ou d’une équipe sur le plan des tests est souvent un point de départ chez nos clients afin d’établir des plans d’amélioration. La réalisation et le suivi de ces plans s’appuient ensuite sur des indicateurs pour s’assurer de l’avancement et des résultats obtenus.

Nos partenaires spécialistes du test sont fréquemment sollicités pour réaliser ces audits, établir ces plans, et mettre en place les indicateurs à suivre. Nous avons donc travaillé à établir des tableaux de bord qui peuvent contribuer à cette phase d’audit mais aussi être un appui pour le suivi des actions et montrer les résultats obtenus.

Ces tableaux de bord s’appuient sur les informations générées pour chaque projet et en donne plusieurs restitutions. Ainsi pour chaque application nous avons notamment des indicateurs :

• la couverture des tests, sur l’application globale ou uniquement les modifications
• le nombre d’itérations/livraisons nécessaires à la validation
• la répartition de l’effort de test entre les différents types de tests, qu’ils soient manuels ou automatisés, réalisés par l’équipe de développement ou par l’équipe de tests fonctionnels
• et d’autres indicateurs comme le temps, le taux de modification ou l’évolution de la couverture…

Cartographie des tests

Le Portfolio est accessible sur le Cockpit via le menu « Tableau de Bord », la Cartographie est disponible dans la partie « Historique » du Portfolio (voir menu à gauche).

Une des principales restitutions s’appuie sur un graphe en 2 dimensions pour comparer les activités de tests de plusieurs projets, faire ressortir ceux situés dans les zones à risques, et identifier des axes de progrès.

Ici chaque quadrant a une signification précise et on peut choisir quel type d’information on souhaite afficher : des informations sur le projet ou sur la dernière version cible. La taille de chaque disque représente soit la taille du projet, soit la taille de la dernière version si on veut se focaliser sur le périmètre modifié. La couleur représente le taux de couverture par les tests de l’application globale ou uniquement des modifications.

Quadrant 1 « Faiblement testée »

Cette zone regroupe les projets avec un déficit de test. Non seulement il y a peu de tests dans les phases de développement mais également peu de tests fonctionnels. Si des analyses plus poussées confirment un problème de qualité, plusieurs actions d’améliorations peuvent être menées à court et moyen terme.

Quadrant 2 « Surtout des tests unitaires et d’intégration»

Dans cette zone, on retrouve des projets dont les équipes de développement ont atteint une bonne maturité sur les tests car c’est généralement synonyme de tests réalisés dans un processus d’intégration continue. On y retrouve plus fréquemment les équipes agiles qui choisissent d’automatiser leurs tests et moins de test au niveau fonctionnel. On trouve aussi les applications qui offrent principalement des services (SOA) et qui n’offre donc pas d’interface utilisateur. Cependant il y a peu de tests fonctionnels avec la vision utilisateur ou de bout en bout, on peut donc avoir quelques désillusions après la mise en production.

Quadrant 3 « Surtout des tests fonctionnels »

Ici les projets sont certes testés correctement mais principalement par des tests fonctionnels ou des tests de bout en bout. Et il est probable que cela soit majoritairement des tests manuels. Les applications devraient être in-fine de bonne qualité en production. Cependant 3 désavantages :

• Ces tests fonctionnels sont certainement exécutés en fin de cycle et comme il y a peu de tests en amont les problèmes surgissent en fin de cycle et tendent les plannings. Cela accroit le risque que dans une future version on passe en production avec une version pas totalement stable, si on n’a pas le temps d’exécuter tous ces tests.
• Le cout de la qualité sur ces applications est important car le coût de correction d’un bug lors des tests fonctionnels est 10 à 100 fois plus important qu’en amont.
• En outre, dans le futur il sera difficile d’automatiser ces tests car ils seront probablement sensibles au changement et donc génèreront des coûts de maintenance plus important.

Quadrant 4 « Sécurité optimale »

Une application placée dans ce quadrant a certainement un niveau de qualité satisfaisant et le coût de cette qualité doit être réduit. Les tests unitaires et d’intégrations assurent de la qualité tout au long de la réalisation et les tests fonctionnels assurent que le processus métier complet fonctionne correctement.

Différentes lectures des données présentées permettent d’appuyer des analyses plus complètes et d’identifier des plans d’améliorations précis.

Voir la documentation sur le Portfolio.

 

 

Lorsqu’il s’agit de réaliser des évolutions ou des correctifs sur une application, plusieurs questions se posent fréquemment :

• Quelles sont les charges de développement et de tests associés pour confirmer le budget et le planning ?
• Quels sont les risques liés à ces évolutions ou à ces correctifs ? Car s’il faut prévoir un gros effort de test de non-régression, il peut-être préféré de reporter ces changements à une version plus importante dans laquelle cet effort de test sera plus facilement absorbé.
• Quel est précisément l’impact sur le travail de l’équipe de test ? Y a-t-il un déficit de test sur les fonctionnalités concernées par ces évolutions ? Faut-il prévoir la conception de nouveaux scénarios de test ? Faut-il anticiper la maintenance de cas de tests automatisés liés à ces changements ?

Les personnes en charge de répondre à ces questions manquent souvent d’éléments factuels pour aider leur analyse. Et celles qui doivent les valider apprécient l’apport d’éléments précis pour appuyer leur décision. Ce besoin nous a été exprimé plusieurs fois par nos clients que cela soit entre un sous-traitant et son client, entre une MOE et une MOA, mais aussi chez un éditeur entre la direction R&D et la direction générale. Les clients avaient identifié avant nous l’intérêt des données collectées par notre plateforme pour répondre à ce besoin. Nous avons donc répondu avec une nouvelle fonctionnalité que nous avons appelée « Simulateur d’Impact ».

Le Simulateur d’Impact permet d’évaluer à partir d’un périmètre à faire évoluer (fonctionnalités, exigences, sous-ensemble du code) les impacts liés à des modifications, en termes de développement, de test et de risque.

 

Estimer les charges de développement

Estimer la charge de développement pour une nouvelle fonctionnalité repose nécessairement sur un travail d’analyse de l’application et de son implémentation. Cependant il n’est pas toujours facile de réaliser des estimations fiables ou d’étayer ses estimations avec un chiffrage précis. D’autre part, au fur et à mesure des évolutions il est possible de comparer ces estimations pour identifier des risques qui pourraient être mal évalués ou au contraire évalués de manière trop généreuse.

Notre solution analyse l’ensemble des changements réalisés à chaque version et des éléments concernés et apporte donc à postériori une analyse de ce qui a été réellement fait pour le budget prévu. Le simulateur d’impact renverse la situation et permet d’évaluer à partir d’un périmètre à faire évoluer (fonctionnalités, exigences, sous-ensemble du code) les impacts liés à des modifications. Nous n’apportons pas de réponse miracle mais des indicateurs pour affiner son estimation ou la comparer avec d’autres estimations ou des versions précédentes.

 

Estimer les charges de test

Généralement la charge de test est évaluée selon différentes méthodes :

• Comme un ratio du développement, 10, 20, 50% voire 100% selon les projets, les risques, etc…
• Comme une charge incompressible, par exemple l’exécution d’une campagne de non-régression complète, 3, 8, 20 jours, voire plusieurs mois sur certain projet sur cycle en V…
• Avec des estimations basées sur les exigences ou les risques (RBT pour Requirement Based Testing ou Risk Based Testing).

Derrière cette estimation se cache aussi des efforts de test différents selon qu’il s’agit des tests unitaires ou d’intégration réalisés par les équipes de développement, des tests fonctionnels manuels ou automatiques conçus, maintenus et réalisés par la maîtrise d’ouvrage. Mais, en termes de test sur le périmètre concerné par ces évolutions, la différence se situe aussi dans l’existant :

• Existe-t-il déjà des tests manuels et peut-on prévoir leur temps d’exécution ?
• Y a-t-il un déficit de test et sera-t-il nécessaire de prévoir la conception de nouveaux cas de test ou à minima de prévoir du temps pour des tests exploratoires ?
• Y a-t-il des tests fonctionnels automatisés et peut-on prévoir la charge de leur maintenance éventuelle ? (cf. zoom sur un cas client ci-dessous)

 

Retour d’expérience : un cas de tests automatisés
Un client a partagé avec nous l’intérêt que présente pour lui le simulateur d’impact par rapport à la situation qu’il a vécue récemment sur ses tests automatisés.

Sur une nouvelle version, il n’avait pas été anticipé que le périmètre des modifications nécessitait de revoir les scripts des tests automatisés. Résultat, à la 1ère livraison par l’équipe de développement, toute une série de tests de non-régression automatisés sont en échec. Mais comme cela n’a été anticipé, impossible d’intégrer cette charge de maintenance dans le planning de recette. Résultat un choix difficile à faire :

– On ne passe pas ces tests sur cette version avec les risques associés

– On retarde la version pour pouvoir corriger ces scripts de test et les exécuter

– On passe tous ces tests en mode manuel sur cette version si on peut mobiliser les ressources nécessaires.

Le choix est difficile. Notre client a finalement choisi d’utiliser le Simulateur d’Impact pour anticiper cette situation dans le futur.

 

La réponse apportée par le Simulateur d’Impact est simple, selon les éléments concernés par ces évolutions, il identifie les tests impactés qu’ils soient manuels (à exécuter) ou automatiques (à maintenir). Il identifie aussi les « trous de test » c’est-à-dire l’éventuel déficit de tests actuel. Ainsi il devient plus facile d’anticiper la charge de test et ses différentes dimensions.

Identifier les risques d’une version

Un usage classique mais fréquent d’une analyse d’impact est d’identifier en amont les potentiels effets de bord d’une évolution ou d’un correctif. Ces derniers peuvent paraitre simples au départ mais ils ont parfois des effets beaucoup plus importants qu’envisagés au départ. Avec pour corrolaire une charge de développement plus lourde, plus de tests à prévoir, voir une mise en production laborieuse.

Pour réaliser une analyse des risques rigoureuse, le simulateur d’impact s’appuie sur deux fonctionnalités de la plateforme Kalistick :

• Le modèle métier de l’application qui représente les sous-ensembles fonctionnels, va faire apparaitre les éléments impactés par ces futures modifications. Cette analyse peut se faire par les exigences ou par les risques lorsqu’un tel modèle est utilisé avec des outils comme HP QC.
• L’empreinte des tests fonctionnels. Le simulateur identifie les tests fonctionnels impactés par des évolutions avec pour chacun le « nombre d’impacts » pour identifier les plus impactés.

Remonter l’étude d’impact au niveau des exigences

Plusieurs de nos clients s’appuient sur une modélisation des exigences avec une traçabilité des tests. Dans ce cas, ils bénéficient alors d’une remontée de l’analyse d’impact et des risques au niveau des exigences.

 

Présentation du Simulateur d’Impact

Le simulateur d’impact utilise les données capturées par la plateforme Kalistick pour répondre aux besoins présentés ci-dessus. Les données sont constituées des différentes versions livrées et scannées de l’application et des empreintes de test exécutés lors de ces précédentes versions. Les évolutions ou corrections à réaliser seront précisées soit à partir du modèle fonctionnel (modules/exigences/risques impactés), soit à partir des résultats d’une étude technique préalable qui indiquera les éléments du code concernés (fichiers, packages, classes, méthodes,….).

 

Définir le périmètre concerné
L’étude d’impact s’appuie sur l’identification des éléments concernés par les évolutions. Deux solutions sont proposées pour cela :

 

• Sélectionner les modules métiers
  Cette identification repose sur la définition des fonctionnalités ou exigences concernées, et utilise le modèle métier de l’application. Ainsi dans l’exemple ci-dessous en indiquant le module Workflow, la plateforme retrouve tous les éléments du code concernés par ce module et qui sont dans le périmètre à faire évoluer.

   

• Indiquer le code à faire évoluer
  

  Cette deuxième option permet d’indiquer directement le code sujet à évolution. Cela suppose que l’équipe technique a déjà réalisé une première évaluation technique pour fournir cette liste.

 

Ensuite il faut lancer l’analyse en cliquant sur le bouton « Analyser l’impact » :

 

Interprétation des résultats

Le Simulateur affiche alors une « Synthèse » avec le chiffrage de l’évolution en termes de nombre de tests impactés, de temps d’exécution de ces tests, des trous de test (déficit de test) ou encore de la proportion des modifications au regard de la taille globale de l’application.

Les tests considérés comme impactés sont les tests dont l’exécution stimule les éléments du code à modifier, et il est indiqué le temps estimé pour l’exécution de tous ces tests. Cette estimation étant basée sur le temps de la dernière exécution de chaque test.

Ainsi, la liste des « Modules impactés » donne une évaluation des risques. Chaque module qui contient du code à modifier est identifié, le nombre d’impacts étant un indicateur du nombre d’éléments modifiés dans chacun d’eux.

 

La liste des « Tests impactés » présente tous les tests concernés par ces changements dans l’application. Pour chaque test est présenté le nombre d’impacts et la durée de la dernière exécution.

Les « Eléments de code impactés » précisent tous les éléments pris en compte pour l’estimation de l’impact avec pour chacun le volume de code correspondant (indicateur de risques/charge).

Enfin les « Trous de test » présentent tous les éléments du code pour lesquels il n’existe aucun test fonctionnel. Un travail avec l’équipe technique est nécessaire pour évaluer le risque lié à ce déficit de test et la nécessité de prévoir la conception de nouveaux cas de test.
D’autre part, la fonctionnalité « Tests Voisins » permet d’identifier des cas de tests proches dont la déclinaison peut répondre à ce besoin de nouveaux tests. Cela donne aussi une première idée du rôle fonctionnel de ce code dans l’application.

 

Conclusion

Le Simulateur d’Impact de la solution Kalistick répond ici à un besoin en amont pour les projets Agile aussi bien que pour les projets sur cycle en V. Il permet l’anticipation pour réaliser ou confirmer des chiffrages d’évolution et appuyer les décisions subséquentes sur des faits précis. Cette nouvelle fonctionnalité est déjà déployée et accessible à tous nos clients sur leur Cockpit, et voici le lient pour l’accès direct.

Alors que la plupart des outils de test et de performance du marché se heurtent à la complexité de la brique Dassault System Enovia sur laquelle est basé le PLM de Faurecia, le groupe découvre en  Kalistick une solution innovante qui lui permet de rationaliser fortement ses processus de test et d’optimiser sa qualité logicielle.

Retour sur le déploiement de l’outil avec Jean-Noël Gueutal, PLM  Developpement Team Manager de Faurecia.

Faurecia

Quelques Chiffres

• Equipementier automobile international
• CA 2011 : 16,2 M€
• 270 sites de production dans 33 pays
• 40 centres de R&D
• 84 000 collaborateurs à travers le monde

Groupe d’ingénierie et de production d’équipements automobiles, Faurecia est un des leaders mondiaux dans chacune de ses activités : sièges, systèmes d’intérieur, technologies de contrôles des émissions et extérieurs d’automobile.

Présent  sur 270 sites dans une trentaine de pays, Faurecia a réalisé un chiffre d’affaires de 16,2 milliards d’euros en 2011 et emploie actuellement plus de 80 000 personnes.

Il a pour clients la quasi-totalité des constructeurs automobiles mondiaux,  dont ceux des économies émergentes, indiens, chinois et coréens.

Zoom sur le cas Faurecia

• Application de PLM construite sur la brique Dassault System Enovia
• Environ 70 000 tests automatisés
• Grand nombre de test manuelscomplémentaires
• Outils principaux de tests : HP QTP (automatisation) et HP QC (référentiel)

“Nous avions de vrais doutes sur la capacité d’une solution comme Kalistick à fonctionner sur notre système.” Les Enjeux

• Rationaliser les processus de test et gagner en coûts/délais tout en améliorant l’efficacité des tests de non-régression
• Adopter un nouvel outil dans un contexte particulièrement complexe

La solution Kalistick Kalistick, un outil pour monter en qualité sur le PLM (Product Lifecycle Management)

La taille de Faurecia et l’importance de son marché l’obligent à recourir à une gestion du cycle de vie produit (PLM) rigoureuse et de très haute qualité.

Celle-ci est du domaine de compétence du département EIT (Engineering Information  Technology) dirigé par Eric Borgard et lui-même divisé en deux entités : la première s’occupant de la partie fonctionnelle, en relation avec les métiers et Key Users, et la deuxième gérant la partie technique : spécifications techniques, développements, packaging et tests unitaires selon un cycle en V classique.

Pour Jean-Noël Gueutal, PLM Developpement Team Manager de Faurecia et donc responsable de cette deuxième entité, la qualité logicielle du PLM est un aspect  fondamental de la conception des équipements pour le marché automobile.

«C’est dans ce cadre, que nous nous sommes intéressés à Kalistick. Pour l’application PLM – Product Lifecycle Management) de nos produits, nous réalisons d’ores et  déjà plus de 70 000 tests automatisés avec l’outil HP QTP, dont nous pilotons l’exécution à travers HP QC (référentiel de tests), que nous utilisons aussi pour formaliser nos tests manuels.»

La solution Kalistick, qui permet de détecter les  “trous de tests” entre les différentes versions logicielles, apparaît très vite comme un outil particulièrement intéressant pour construire de nouveaux scénarios sur les tests manquants et ainsi améliorer la couverture de test sur le logiciel PLM  du groupe.

Un challenge de taille : la compatibilité avec la brique Dassault System Enovia “Nous avions de vrais doutes sur la capacité d’une solution comme Kalistick à fonctionner sur notre système car la solution PLM que nous utilisons est colossale : des millions de lignes de code, un mélange de différents langages (Java, JS, C, TCL, MQL) et différents types d’exécution (JSP, Servlet, JAR, Programmes compilés en base de données et exécutés en interne)… Ce n’est pas une application Java que l’on pourrait qualifier de “normale”.”Mickaël Bertrand, PLM Technical Expert at Faurecia

Si les équipes sont donc au départ sceptiques, c’est également en raison de la structure particulièrement complexe et hors-norme de la brique Dassault System Enovia sur laquelle est basé le PLM du groupe, et à laquelle se heurtent la plupart des outils de test et de performance du marché.

Une donnée simple suffit d’ailleurs à se faire une idée de la taille du challenge pour Kalistick : la dernière montée en version du PLM du groupe a ainsi nécessité environ 500 jours/homme de pur développement à iso-fonctionnalités.

Dans un premier temps, un POC (Proof of Concept ou Pilote) a donc été réalisé.

«J’avoue que nous avons été positivement surpris de voir que Kalistick réussissait du premier coup à enregistrer 100% de l’empreinte des tests et à détecter l’impact des changements», déclare Jean-Noël Gueutal. Le POC a donc été validé par le groupe et l’implémentation de la solution entérinée.

Des conditions d’implémentation auxquelles se plie parfaitement Kalistick

Les capacités d’intégration qu’offre Kalistick avec les solutions majeures d’automatisation de tests et de référentiels de tests, que sont respectivement HP Quality Center (QC) et HP Quick Test Pro (QTP), sont également un élément-clé pour l’adoption de la solution par Faurecia.

On le comprend aisément : il est indispensable pour une entreprise qui réalise plus de 70 000 tests avec ces solutions leaders de leurs catégories que tout nouvel outil apporte une valeur importante et complémentaire, tout en s’intégrant parfaitement.

Enfin, l’aspect hybride «on-premises/Cloud» de Kalistick est un autre point fort de la solution : les modules «Scan de l’application» et «Empreintes de test» qui sont installés chez le client sont en effet simples à mettre en oeuvre, et l’analyse et les tableaux de bord sont, eux, hébergés sur le Cloud.

«Le fait que Kalistick ne nécessite pas l’installation d’un serveur en interne est un plus», reconnaît Mickaël Bertrand.

Kalistick, un atout-clé pour passer en mode agile

Mais au-delà de ces considérations purement techniques, Kalistick pourrait bien être un atout non-négligeable dans l’évolution que souhaite entreprendre le département EIT du groupe.

«Nous projetons en effet de passer du traditionnel cycle en V vers des méthodes agiles»,

explique Jean-Noël Gueutal.

«Pour cela, afin de pouvoir livrer de nouvelles releases (versions) du PLM plus souvent. Il nous faudra donc encore optimiser les tests. Et si Kalistick permet en aval de détecter des trous de tests pour construire de nouveaux scénarios complémentaires, il permet aussi en amont de mieux sélectionner les tests qui doivent être joués, et ainsi de les optimiser (éviter de tester plusieurs fois la même chose) et de les prioriser, ce qui est capital sur des cycles courts.»