Témoignage: La genèse d’un ALM

Bonjour Eric, peux-tu nous présenter ton parcours mais aussi comment t’es venu l’idée de créer XStudio ?

Je suis actuellement CEO de la société XQual. Société éditrice d’une solution de Test Management : XStudio. Nous sommes en compétition direct avec HP (Quality Center et ALM) et d’autres acteurs plus modestes pour la plupart basés aux USA.

Mon parcours a commencé par une formation dans une école d’ingénieur généraliste en génie électrique (ESIGELEC basée à Rouen en Normandie), promo 1994. Je suis ensuite arrivé sur Sophia Antipolis. J’ai commencé par travailler dans des startups américaines. La première a été Shiva (hardware/firmware de télécommunication) – C’était très enrichissant car les technos employées étaient très en avance et innovantes pour l’époque). J’ai découvert le test avec cette première expérience professionnelle. L’environnement international était très excitant. Ma première mission a été de tester le client de Windows 95 qui permettait de se connecter en « remote access » sur un routeur d’accès distant (Network Access Server) via RNIS (Numeris pour les Français !). C’était donc un travail sur un produit Shiva qui était distribué par Microsoft dans son OS phare. J’ai ensuite été amené à tester plus directement les routeurs. A l’époque, il n’y avait pas d’outillage adapté. J’utilisais un outil Microsoft pour les tests software et puis c’est tout : pas d’ALM (l’ancêtre de QC , Test Director, devait pourtant exister mais je ne pouvais pas l’utiliser car il était plus ciblé pour du test manuel et nous avons rapidement automatisé les tâches répétitives pour passer plus de temps sur la conception et le développement et moins sur l’exécution).

Le 2^ème axe frappant à cette époque était le manque d’outillage disponibles et utilisables avec nos technos pour les tests de performances. Pour le test de hardware et notamment les produits sur lesquels je travaillais c’était pourtant primordial. Nous devions, par exemple, savoir comment réagissait le routeur et son firmware lorsque N users se connectaient simultanément ou suivant certains profils de charge, mesurer combien de tunnels nous étions capables d’initier et de supporter à la seconde etc. il fallait être plus performant que nos compétiteurs directs (Cisco et Ascend).

J’ai alors développé un outil de montée en charge (surcouche au noyau linux + stack PPP) et de monitoring pour « monter » des tunnels en masse et faire des tests de performances ad’hoc adaptés à notre besoin. Cet outil traçait en temp réel les différents SLA et est devenu un atout énorme, notamment pour démontrer les performances de nos produits au sein de différents labs, partenaires et prospects. A l’époque on ne s’intéressait pas réellement au test management comme maintenant : on élaborait un plan de test (sur Word !) puis l’essentiel de l’effort se concentrait sur l’écriture et l’automatisation des tests. C’est la partie qui m’a le plus intéressé à l’époque. L’exécution automatisée, simultanée et contrôlée des tests et le monitoring des ressources en général.

Assez rapidement nous sommes devenus 4-5 testeurs et ce qui était remarquable à l’époque c’était les coûts exorbitants (et non supportable pour une petite startup) des logiciels de test évolués. En outre, il y avait souvent dans l’outillage de l’époque une orientation très marquée « tests manuels » et rien n’était réellement pensé pour l’interfaçage avec les systèmes d’automatisation propriétaires – ce qui était rédhibitoire dans notre cas ! C’est probablement à ce moment-là qu’est née la 1^ère étincelle pour la création d’XStudio : l’idée de proposer un système avec des interfaces permettant à des systèmes externes de communiquer avec une entité « pilote ». Au départ, XStudio n’était donc pas un vraiment un ALM mais un moteur d’exécution générique pouvant s’interfacer avec n’importe quel système externe et qui devait permettre aux utilisateurs d’adapter l’outil à leurs besoins. Je n’ai pas pu exploiter cette idée à ce moment-là. Shiva a été racheté par Intel.

Que s’est-il passé après ton expérience chez Shiva ? Quand la première version de XStudio a-t-elle été utilisable ?

A cette époque XStudio n’existait que dans mon esprit et 1 ou 2 cahiers où je notais les idées « en vrac », l’architecture logiciel, le schema de la base de données etc. J’avais la casquette d’architecte à ce moment là.

Compteur de cahiers: 2

Le cœur de l’équipe (développements + QA) n’étant pas totalement épanoui chez Intel, nous sommes tous partis à l’aventure et avons suivi notre manager de l’époque pour monter la succursale française de la société Xevo. Cette startup concevait une plateforme permettant de provisionner des applications (par exemple la suite office ou un serveur d’authentification LDAP) automatiquement. Les utilisateurs finaux louaient leurs applications un peu à la manière du SaaS que l’on connait aujourd’hui à partir de clients légers. Mais c’était il y a 20 ans ! une sorte de « cloud » applicatif. Je suis arrivé en tant que responsable des tests. Il y avait beaucoup à faire, du test de base de données, du test fonctionnel et beaucoup de tests d’intégration. C’était une technologie totalement différente de ce que l’on manipulait chez Shiva et pourtant des problématiques similaires sont réapparues à ma grande surprise:

• Management de tests et des campagnes de tests difficile,
• Maintenance des test plans, problématique de versioning des tests vs des releases
• Intégration avec des frameworks de tests automatisés ardue
• Coûts d’exécution des tests de non-regression

L’idée de XStudio a continué à faire son chemin avec des notes régulières sur mes cahiers qui commençaient à se multiplier pour décrire mon ALM « idéal ».

Compteur de cahiers: 4

L’aventure Xevo s’est malheureusement terminée car le marché des clients légers et la location d’application n’a pas fonctionné (vraisemblablement pas le bon timing).

J’ai ensuite intégré pour la première fois une société française (Trusted Logic), qui travaillait sur les cartes à puces, et la sécurité au sens large, en particulier des VMs Java. Le domaine de test était ici purement software et les technologies de chiffrement étaient prépondérantes. J’ai énormément travaillé à ce moment sur des tests qu’on qualifierait plutôt d’unitaires (test de VM Java – des milliers de tests au sens strict du terme pour tester les classes java : String, Integer, Vector etc.). J’ai également élaboré à cette époque le plan de test STIP (standard de profile de stack java embarquée). Cette expérience m’a apporté encore une nouvelle approche du test. QC existait déjà mais était trop cher et de ce que j’avais vu ne convenait pas vraiment au contexte. Entre temps, j’avais écrit 1 nouveau cahier de notes sur ce que devrait accomplir mon ALM « idéal ».

Compteur de cahiers: 5

J’ai quitté Trusted Logic pour rejoindre de nouveau une startup (Babel Networks), société qui proposait un service de streaming (à la Youtube) spécialisée dans les contenus de niches (sports extrêmes, musique indé en particulier). C’était désormais aux technologies web avec des problématiques de bandes passantes, CDN, et cache de grande envergure que je devais me frotter. J’ai été embauché à Villeneuve-Loubet dans l’équipe R&D pour reprendre l’équipe d’assurance qualité. On a de nouveau beaucoup automatisé et encore une fois rien sur le marché ne nous permettait d’automatiser et surtout d’intégrer facilement nos tests dans un ALM digne de ce nom.

J’ai alors commencé, sur mes week-ends et mes soirées à travailler et développer une ébauche de ce dont j’avais besoin. Pendant plusieurs mois, j’ai travaillé sur la mise en place et l’élaboration d’une base de données regroupant toutes les informations utiles. Je me suis ensuite penché sur la définition de l’interface (SDK et launchers). Cela a été assez rapidement stabilisé. Les APIs développées pendant cette période sont globalement les mêmes qu’aujourd’hui – ça sert de mijoter des idées sur papier suffisamment longtemps ! – et sont activement implémentées dans les 80 launchers existants dans XStudio aujourd’hui. Je continuais néanmoins mon travail à 100% chez Babel Neworks. C’est à cette période que j’ai commencé à avoir un outil qui commençait à tenir debout. XStudio contenait à cette époque les modules requirements, tests, campagnes et user management. Le moteur d’exécution était déjà très stable et fonctionnait très bien. Le test management et le moteur d’exécution manuelle n’était en revanche pas complet. Mais le principal était là : l’interfaçage avec l’automatisation (ad’hoc ou non) fonctionnait très bien, le lien entre XStudio et n’importe quel framework d’automatisation était fonctionnel ! Nous étions alors en 2005.

Qu’as-tu fait ensuite ? T’es-tu intégralement penché sur XStudio ?

A cette période j’ai été promu directeur de l’engineering au sein de Babel network (équipes développement + test) et suis devenu gérant de la filiale française. Mon temps libre était réduit mais mes développements personnels ont continué. C’est alors que j’ai été contacté par une société Allemande spécialisée dans l’automation me proposant de racheter la propriété intellectuelle d’XStudio. A cette époque, XStudio était déjà pas mal utilisé en mode gratuit car je l’avais mis à disposition sur le net. Cette société souhaitait intégrer XStudio dans sa gamme de produit, il y a eu une phase de négociation et puis finalement cela ne s’est pas fait. Pendant cette phase de négociation, leur exigence première était que j’ai une société en mon nom propre pour pouvoir acheter les droits et s’assurer que je ne les laisse pas tomber ensuite.

Puisque le deal était tombé à l’eau et que j’avais anticipé la création de la société, je ne savais pas trop quoi en faire. En parallèle, j’ai commencé à être approché par pas mal de clients qui m’indiquaient qu’ils aimaient la solution mais souhaitaient avoir l’assurance d’un suivi et d’un support garanti « professionnel ». C’est ainsi que j’ai commencé à vendre du support (le modèle produit gratuit mais support payant).

De fil en aiguille, je suis arrivé à avoir une petite base de clientèle – en les aidant également sur leurs déploiements, l’organisation, la mise en place. A cette même époque, Babel Network a dû fermer (pas assez de traction et trop de concurrence d’une petite société ayant le doux nom de Youtube !). J’ai eu la douloureuse charge de fermer la société en France. Mais quitter Babel Networks m’a permis de prendre 1 année complète pour travailler à fond sur mon produit (1 année de développement acharné). J’ai commencé à développer les versions commerciales que l’on connait aujourd’hui ainsi que les diverses fonctionnalités des versions Professional, Business et Enterprise.

La base de XStudio était là (année 2007).

Après cette année de développement, le hasard fait qu’on m’a proposé de travailler en tant que consultant pour Air France. Je devais les aider sur le plus gros projet jamais réalisé en interne en tant que test manager. Une expérience très challenging ! Le chiffre d’affaires d’XStudio n’étant pas encore tout à fait suffisant pour me faire vivre, j’ai accepté et repris une activité de consultant pour les aider pendant 1 an à 100%. Evidemment, j’ai continué à développer les week-ends et les soirées (heureusement, 4-5 heures de sommeil par nuit me suffisent). Au bout d’un an chez Air France j’avais beaucoup plus de clients et XStudio me « consommait » désormais l’équivalent d’un temps plein. Je suis donc passé à 80% puis à 50% chez Air France pendant 2 ans. Je suis resté en tout 3 ans chez Air France et ai arrêté au moment où je ne pouvais vraiment plus tenir le rythme (physiquement). Le projet était très intéressant et arrivait heureusement à son terme je suis donc parti avec l’impression du travail achevé.

Depuis, je développe XStudio et le commercialise dans le monde entier. Nous sommes désormais plusieurs à travailler sur le produit et le « one-man-show » s’est transformé en vraie société distribuant à l’internationale !

Comment XStudio est-il vu sur le marché ?

Au niveau du marché, XStudio est relativement connu à l’étranger et se vend bien (alors qu’on ne fait toujours pas de marketing – on laisse faire le bouche à oreille): 50% du CA est réalisé aux USA, 25% en Allemagne et Europe du nord, les 25 derniers % sont réalisés dans le reste du monde (Inde, Angleterre, Irlande, Frances etc.), très peu en Afrique. Là où on voit beaucoup de traction depuis 2-3 ans c’est le monde du médical et les labos pharmaceutiques. Je pense que c’est dû au fait que l’on a des partenaires qui vendent XStudio en marque blanche (la marque blanche se fait aisément car XStudio est très facilement configurable et l’on peut remplacer aisément ses logos, icones et terminologies). Cela permet à XStudio d’accéder à des marchés auxquels ont accès ces « revendeurs » d’un nouveau type. Cela est également probablement dû au fait que l’on a développé des fonctionnalités indispensables aux audits FDA (Food and Drug Administration). Par exemple nous sommes parmi les très rares à fournir des solutions de « gèle » et de signature électronique sur les éléments traceables et auditables (exigences et tests notamment). Une assurance de plus pour les auditeurs et donc les audités.

Comment es-tu passé de 1 à plusieurs personnes travaillant sur XStudio ?

Notre organisation est très particulière dans le sens où l’on n’a pas de bureau et qu’il y a aucun employé au sens strict du terme. Je ne fais appels qu’à des consultants avec qui je travaille depuis plus de 10 années et que je connais très bien. Une relation particulière nous unis et nous sommes tous indépendants. Que cela soit pour la documentation, le développement de petits modules, les développements plus génériques, les tâches administratives, la comptabilité, toutes les personnes qui travaillent pour moi me facturent « à l’heure ». Et tous travaillent de chez eux. Il n’y a aucun problème de communication, une bonne ambiance de travail, tout le monde est impliqué à 150%. Evidemment, nous organisons assez souvent des déjeuners de travail pour se voir en face à face (et aussi pour le plaisir !) mais Skype reste notre outil de communication central. Je sais qu’en France cela ne se fait pas trop mais ça fonctionne très bien à partir du moment où est établie une relation de pleine confiance.

Si tu devais refaire les choses différemment que changerais tu ?

J’aurais démarré les développements de notre client web plus tôt ! L’implémentation des APIs REST publiques et l’implémentation du client web a mis plus de temps que prévu. J’attendais que les clients me réclament le client web pour le démarrer et cela a été une grosse erreur.

Heureusement, nous avons été efficace et notre client web (encore jeune) a de bons retours. C’était aussi l’occasion de repenser notre interface utilisateur.

Comment as-tu pensé cette version web ?

Nous avons pensé cette nouvelle mouture en étudiant les retours clients (que l’on a obtenus via sondages et questionnements directs):

1. Je souhaitais faciliter l’accès des utilisateurs (aujourd’hui XStudio propose 3 clients différents :
   1. le client lourd (à télécharger et installer),
   1. le client JNLP (java web start). L’appli est stockée sur le serveur, l’utilisateur démarre le client via une URL à ouvrir via un navigateur. Donc pas besoin d’installer mais c’est toujours en quelque sorte un client lourd qui tourne finalement,
   1. enfin, le client Web (besoin d’un navigateur uniquement)

Désormais, les gens ne veulent plus installer quoi que ce soit sur leur PC

• J’ai étudié les points forts et les points faibles remontés par nos clients :
  • Principal point fort : outil très complet (les gens qui viennent d’ALM sont pleinement satisfaits) et qui propose des solutions « ouvertes »,
  • Principal défaut remonté : semble compliqué d’approche pour certains et ergonomie à améliorer (dû à la techno employée : Java)

Afin de proposer aux clients une réponse aux points faibles remontés nous avons allégé le GUI (IHM – interface graphique) tout en faisant attention à ne pas perdre les utilisateurs du client lourd. Il y a eu un gros travail sur l’ergonomie. Nous avons donc fait un produit simple avec la possibilité d’ajouter des modules plus tard. Les 3 clients peuvent être utilisés simultanément si besoin. Enfin, XStudio.web (c’est le nom du client web) fonctionne sur tous les navigateurs et sera bientôt full responsive (fonctionnant sur téléphones et tablettes).

Le premier module développé sur la version web a été la gestion des exigences car les analystes métiers sont les premiers à ne pas vouloir installer de produits. Ils préfèrent souvent conserver leurs habitudes sur Excel (d’où notre module d’import Excel !). On a ensuite ajouté la gestion des spécifications, les SUTs (System Under Test), les tests, les campagnes, les sessions, les bugs et dernièrement la gestion des utilisateurs (droits et équipes).

La version 4.0 qui vient de voir le jour est parfaitement utilisable (nonobstant quelques fonctionnalités encore disponibles uniquement sur les versions « legacy »).

Quand on a commencé à développer XStudio.web, j’ai été aidé par 2 développeurs experts car je ne connaissais pas bien encore ces technologies. Nous avons refactoré, refactoré et encore refactoré pendant 6 mois l’architecture de manière à avoir des fondations solides. Cela nous a permis de beaucoup gagner en performances notamment par rapport au client lourd et aussi d’avoir un framework de développement javascript asynchrone modeste en taille et stable – sans avoir à utiliser les gros frameworks du marché, trop gourmands à mon gout.

Reste qu’un browser n’a pas accès aux ressources de la machine (heureusement !). Pour les tests manuels nous fournissons une interface spécifique dans le navigateur. Pour les tests automatisés nous n’avons rien eu à développer de particulier puisqu’on on utilise nos agents et les launchers déjà développés pour XStudio. L’utilisateur spécifie sur quel agent il veut exécuter ses tests automatiques et l’agent exécute le job et remonte les résultats en BDD. Cela dit, de plus en plus, les exécutions de test automatiques sont soit schédulés (via XStudio), soit déclenchés via l’environnement d’intégration continue grâce à notre outil XContinuousIntegration qui s’intègre dans le build plan Jenkins/Bambo/TeamCity etc. Tout est également pilotable via notre API REST.

Tout l’écosystème autour de XStudio reste complètement valide avec XStudio.web ! c’est tout l’intérêt d’une architecture ouverte et bien pensée.

Peux-tu donner des utilisations actuelles de XStudio où l’interfaçage proposé par cet ALM est primordial ?

2. Dès lors qu’un client a développé son propre framework de test automatisé (scripts, batch, développements natifs etc.). Dans ce cas, il suffit de développer un « launcher » qui fera l’interface entre XStudio et les tests « physiques ». Un SDK (open-source) très simple est fourni. Nous aidons nos clients à développer leur(s) launcher(s). En général, c’est l’affaire d’un ou deux jours de travail ! Nous pouvons développer nous même ces launchers custom pour nos clients si besoin. Il n’y a aucune limite. A titre d’exemple, nous avons des launchers qui pilotent des « robots » physiques (tests de scanners médicaux, sondes métrologiques etc.)
3. Lorsque qu’un client utilise plusieurs systèmes d’automations génériques (disons par exemple Selenium, JUnit, Ranorex et UFT) et qu’il souhaite piloter ses tests sans avoir à développer quoi que ce soit. Une de nos grandes forces réside dans notre catalogue de launchers. Plus de 80 launchers à l’heure actuelle ! Ils sont utilisables tels quels mais peuvent aussi être customisés si besoin par le client.

Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.

Liens utiles :

• Liste des launchers supportés : https://www.xqual.com/documentation/launchers/introduction.html
• 4 instances libre d’accès de XStudio.web (à Dallas, New-York, Paris et Chennai) : https://www.xqual.com/support/try_it.html
• Zone téléchargement : https://www.xqual.com/support/download.html
• Principales fonctionnalités (en Français dans le texte) : http://www.xqual.fr/products/xstudio.html
• Principales fonctionnalités (en anglais dans le texte) : https://www.xqual.com/products/xstudio.html