Interview autour des activités des ProFessional Services (PFS) Squash AUTOM-DEVOPS et GitLab
Voici un résumé de l’interview de Florian Gautier, Responsable des PFS Squash AUTOM-DEVOPS et des PFS GitLab chez Henix. Dans cet entretien, réalisé en février 2023, il nous dévoile la diversité des missions qui rythment son quotidien et des profils avec lesquels il est amené à collaborer dans le cadre de projets d’automatisation de tests et/ou d’intégration de ces derniers dans une chaîne DevOps.
Quel a été ton parcours avant et après ton arrivée chez Henix ?
J’ai effectué mon parcours académique à Lyon, ce qui m’a mené à faire une thèse en physique théorique. Puis, j’ai connu une première expérience en tant que chercheur postdoctoral à Munich. Ce n’est qu’après, aux alentours de 2017, via l’Ecole de la Qualité Logicielle (EQL) puis l’AFCEPF, que je suis arrivé chez Henix en tant que développeur.
J’ai ensuite fait une mission de qualimétrie sur CAST chez une grande banque française puis j’ai enchaîné des missions d’automatisation de tests et de développement autour de Squash TA (avant que ce module ne soit rebadgé Squash TF) à l’Informatique Caisse des Dépôts.
À partir de 2020, je suis arrivé au Siège d’Henix pour participer au développement de Squash TF (qui est depuis remplacé par Squash AUTOM — Squash DEVOPS). À la suite du départ du précédent responsable des Professional Services Squash TF en 2019, j’ai récupéré ce périmètre. Aujourd’hui, je suis en charge des PFS Squash AUTOM-DEVOPS et, depuis un an, des PFS GitLab.
Il nous arrive parfois d’avoir l’impression que l’on participe à l’élaboration de la méthodologie outillage.
Qu’est-ce qui t’a attiré dans ta mission actuelle autour des PFS ?
Je dirai que c’était avant tout la variété des sujets, permettant d’éviter de rentrer dans une forme de routine. Les sujets techniques sur lesquels je suis amené à travailler sont toujours d’actualité. Nous parlons de tests en environnement, d’intégration continue, de déploiement continu, de Cloud… Dans ce domaine, il y a beaucoup à maturer et à mettre en place. Il nous arrive même parfois d’avoir l’impression que l’on participe à l’élaboration de la méthodologie outillage.
Quelle est la différence entre les PFS Squash TM et les PFS Squash AUTOM — Squash DEVOPS ?
Là où les PFS Squash TM portent la méthodologie et l’expertise autour du management de test avec Squash TM, notre travail porte lui sur la méthodologie liée à l’implémentation des tests automatisés avec Squash AUTOM et à l’intégration de ces tests dans la chaîne DevOps avec Squash DEVOPS. Notre périmètre représente donc un volet complémentaire aux PFS Squash TM en vue de mettre en place les bonnes pratiques dans le cadre de l’utilisation globale de la suite Squash.
Les PFS GitLab sont-ils bien distincts des PFS Squash AUTOM-DEVOPS ?
Les PFS GitLab sont en effet autonomes et indépendants pour répondre à des cibles différentes pour le moment.
Le pool d’experts GitLab est-il plus restreint que celui autour de Squash AUTOM — Squash DEVOPS chez Henix ?
Il est effectivement plus restreint, car cette partie de notre activité a été créée il y a seulement un an. Les missions portant autour de problématiques liées à l’utilisation de GitLab montent cependant clairement en force chez Henix et nous avons désormais suffisamment d’experts pour être certifiés Professional Services GitLab.
Tous nos consultants exerçant des missions d’automatisation de tests ou de DevOps, montent en compétences sur Squash, sur la méthodologie associée et sur les outils qui s’y intègrent tels que Robot Framework ou Cucumber.
Combien de personnes composent ton équipe et comment est-elle organisée ?
Nous avons plus d’une dizaine d’experts mobilisables, deux ou trois d’entre eux étant affectés spécifiquement aux PFS Squash AUTOM-Squash DEVOPS. Chez Henix, il faut savoir que tous nos consultants exerçant des missions d’automatisation de tests ou de DevOps, montent en compétences sur Squash, sur la méthodologie associée et sur les outils qui s’y intègrent tels que Robot Framework ou Cucumber. Ainsi, ils peuvent être à même de s’occuper de prestations type PFS dans leur propre mission ou d’étoffer notre pool de personnes mobilisables.
Peux-tu nous résumer les prestations proposées par ton Pôle ?
Globalement, nous accompagnons la mise en place et la prise en main des outils, mais nous proposons également des services autour de l’installation, de la formation et de la méthodologie.
Quelles sont les étapes préliminaires avant que vous puissiez démarrer cet accompagnement ?
Une partie de notre travail en tant que PFS s’apparente à de l’avant-vente. Nous échangeons donc beaucoup avec des prospects afin de les aider à définir et à affiner leurs besoins actuels ou futurs. C’est même la vraie plus-value des PFS qui ne se limitent pas à proposer des prestations sur étagère.
Mon but, c’est de « construire » une prestation adaptée au client.
Quel est l’aspect que tu préfères au moment de démarrer un premier échange avec un prospect ?
Ce qui m’intéresse, c’est justement quand un prospect arrive avec des besoins qui ne sont pas forcément établis. Plutôt que de dire « OK, on va faire exactement ça », nous réfléchissons avec lui pour déconstruire ses douleurs afin de mieux les identifier. Mon but, c’est ensuite de « construire » une prestation adaptée au client. Il faut bien avoir en tête qu’il y a deux phases distinctes : la phase d’avant-vente et de construction du besoin et la phase consistant pour nous à déterminer comment on pourra répondre à ce besoin. Il est donc intéressant pour moi de rappeler que les missions des PFS ne se résument pas qu’à de la réalisation ou à du delivery.
Comment pourrais-tu résumer la partie réalisation / delivery justement ?
Une fois que l’on a défini le besoin, il nous faut définir les missions, souvent courtes et à forte valeur ajoutée, qui permettront de répondre à des problématiques clients tout en capitalisant sur les bénéfices des outils que nous connaissons bien.
Quelle est la répartition de ton temps sur ces différentes missions ?
Je dirai que 25 % de mon temps est dédié à l’avant-vente, 60 % en réalisation et le reste en support pour l’équipe et en gestion du delivery.
De par ton expérience, quelles ont été les principales surprises liées à ton poste ?
J’ai été marqué par l’hétérogénéité des cultures autour du test et du DevOps entre les clients et parfois même entre les équipes chez un même client. En définitive, ce qui m’a surpris, c’est que chaque besoin est différent et que des clients vont être très matures sur certains aspects très pointus, tout en étant potentiellement moins investis dans d’autres domaines liés. Donc même à taille égale ou avec des personnes ayant un champ de compétences à peu près égal, on retrouve toujours des dissymétries et c’était surprenant au début.
Une autre surprise, plutôt agréable, c’est de pouvoir ressentir les effets bénéfiques de notre travail chaque fois que l’on peut soulager une douleur. Les équipes chez les clients ont naturellement beaucoup de questions et on les encourage à s’en poser toujours plus, comme je le disais précédemment. Les missions sur lesquelles on s’engage révèlent donc souvent de vraies problématiques avec de forts enjeux. Malgré cela, en une semaine ou deux, on arrive souvent à trouver des solutions. Récemment, chez un client que je connaissais déjà bien et chez qui j’avais historiquement déjà fait du coaching et de l’accompagnement avec l’aide du Support, nous avons avancé sur cinq sujets en seulement deux jours. Pour chaque sujet, je sentais le soulagement du client grandir.
As-tu par ailleurs des missions en anglais ?
Oui, je suis actuellement en contact avec une équipe en Inde. Même si 95 % de nos interlocuteurs actuels sont français ou francophones, il nous arrive d’organiser des meetings en anglais avec des équipes basées notamment au Portugal et en Inde.
Cela veut-il dire que toutes les missions des PFS peuvent être réalisées à distance ?
Tout peut être fait à distance, mais nos missions nécessitent souvent des aménagements qu’il est préférable de faire sur site, typiquement paramétrer l’accès à des plateformes via VPN ou à des outils techniques. D’après mon expérience, c’est toujours plus facile d’avoir au moins une partie de la mission en présentiel. L’exemple du client précédemment cité a été une réussite avec deux jours en distanciel, mais cela n’a été possible qu’après la vingtaine de jours que j’ai passés en présentiel chez eux, ce qui a pu créer une forme de confiance liée au fait que les interlocuteurs me connaissaient.
Préfères-tu les interactions en présentiel ou privilégies-tu le distanciel ?
Je préfère les interactions en présentiel parce que cela donne une dimension foncièrement humaine à notre métier. De plus, comme on cherche généralement à résoudre des problèmes dans un temps limité, il est toujours préférable d’humaniser le plus possible, ce qui est plus facile lorsque l’on est en face d’une personne plutôt que face à un écran.
Avant de se lancer dans l’automatisation, il faut […] réaliser une matrice permettant de voir où sont ses points faibles et indiquant où placer son effort d’automatisation.
D’après ton expérience, pourrais-tu nous résumer dans quels cas il est intéressant d’automatiser les tests ? Et quelles sont les opportunités à en tirer ?
Je dirai qu’avant de se lancer dans l’automatisation, il faut se poser les bonnes questions, afin de déterminer s’il est pertinent ou non d’automatiser ses tests. Ces questions sont les suivantes : est-ce que l’on recherche plus de couverture ? Une meilleure traçabilité ? Une plus grande confiance dans notre process de test ? Ou tout simplement plus de temps pour faire d’autres choses ?
Il faut également lister les différents types de tests actuellement réalisés par l’équipe de test, parce qu’il y a des tests unitaires, des tests plus fonctionnels, des tests plus techniques, des tests d’intégration au milieu, etc…
En fonction de cette liste et des réponses aux questions précédemment citées, il devient possible de réaliser une matrice permettant de voir où sont ses points faibles et indiquant où placer son effort d’automatisation. Il y a ensuite une infinité de réponses au moment de déterminer les opportunités de l’automatisation des tests.
Arrive-t-il que l’effort d’automatisation soit mal évalué par le client ?
Oui, l’un des meilleurs exemples pour le prouver concerne les tests utilisateur qui rassurent le plus en fin de recette, comme les tests de bout en bout. Ces derniers consistent à reproduire tout le parcours utilisateur. Or, ces tests ont tendance à être complexes à automatiser parce qu’ils touchent potentiellement tout le SI. De plus, plus le test est haut niveau, moins on est proche du code d’une application. Avec ce genre de tests, il peut donc s’avérer compliqué d’indiquer au développeur où faire des corrections dans son code.
Automatiser ces tests n’est donc pas forcément une bonne chose. La solution consiste donc à automatiser une certaine proportion de ses tests tout en définissant d’autres couvertures pour augmenter sa confiance.
L’une des tentations à partir du moment où on se lance dans l’automatisation de tests, c’est de vouloir se concentrer directement sur les tests métiers alors que ce sont les tests les plus complexes. Il vaut mieux se concentrer d’abord sur des tests plus bas niveau, des tests autour d’une seule fonctionnalité ou aller vers le Behaviour Driven Development (BDD), quitte à réenvisager l’option d’automatiser des tests de bout en bout avec l’expérience de la mise en place des premières automatisations.
Quels sont les avantages du BDD ?
Le BDD permet de mettre en place un langage technique compréhensible par les testeurs et les développeurs, mais aussi de retrouver ce langage au niveau du reporting. Au lieu d’avoir des reportings très techniques au niveau macro, cela permet de déterminer et de faire remonter simplement au niveau de quel pas de test un test est en échec.
Et quels sont les aspects déterminants au moment de choisir sa technologie d’automatisation ?
Il y a :
· L’équipe (pour remettre l’humain au centre). Les équipes ont des connaissances sur des outils ou des technologies (typiquement, une équipe de développeurs qui fait de l’Angular a certainement déjà touché à Cypress) donc le choix est dicté par l’expérience de l’équipe. À l’opposé, si on s’adresse à des gens qui veulent des choses plus intégrées parce qu’elles sont moins techniques, on peut favoriser des studios qui permettent la capture des objets, comme Katalon ou Agilitest. Cela favorisera le scripting en mettant en place des briques d’ordonnancement des différents pas de tests.
· Les systèmes à tester. S’il s’agit par exemple de webservices à tester, vous pourrez privilégier l’utilisation de Postman ou d’un framework de test JS avec un composant capable de faire des appels REST.
Il faut exécuter ses tests automatisés le plus souvent possible et le meilleur moyen pour y arriver, c’est d’intégrer ces tests dans des chaînes CI/CD.
À quelle fréquence est-il recommandé de faire des tests automatisés ? Quand est-ce que c’est pertinent de les exécuter ?
Le plus souvent possible, parce qu’on sait que des tests qui ne sont pas exécutés ne vont pas être maintenus et ne seront, à terme, plus exécutables. Nous perdons alors le retour sur investissement de l’automatisation de ces tests. Donc la bonne réponse, c’est le plus souvent possible et le meilleur moyen pour y arriver, c’est d’intégrer ces tests dans des chaînes CI/CD.
Dans le cadre des missions d’automatisation de tests sur lesquelles tu as travaillé, en quoi Squash AUTOM est un atout ?
L’avantage de Squash AUTOM, c’est qu’il est lié à notre référentiel de tests et qu’il permet d’exécuter rapidement des tests. La mise en place de l’automatisation étant coûteuse, il devient intéressant de capitaliser sur Squash AUTOM car il permet de :
· Configurer rapidement le rejeu des tests automatisés, dans des contextes multiples ;
· Déléguer l’exécution des tests automatisés à des testeurs pas ou peu techniques ;
· Inclure les résultats des exécutions dans des rapports de campagne plus génériques.
L’intérêt suivant est lié à l’utilisation de Squash DEVOPS qui permet d’inclure ces tests dans des chaînes DevOps, garantissant que ces tests sont exécutés de façon continue.
Notre expertise se résume à monter des usines logicielles rassemblant un ensemble de services qui favorise le bon développement des applications jusqu’à la mise en production.
Quelle est justement la plus-value des PFS en termes de DevOps ?
Notre expertise se résume à monter des usines logicielles rassemblant un ensemble de services qui favorise le bon développement des applications jusqu’à la mise en production, avec tout ce que tout ce que ça implique dans la gestion du cycle de vie des applications. L’objectif des PFS dans ce cadre est donc d’adresser les bonnes solutions pour aider nos clients à chaque étape du cycle de vie logiciel, que ce soit le plan, le package, le build ou le deploy.
Notre plus-value consiste ensuite à suivre la bonne utilisation, par les équipes projets, de l’usine logicielle mise en place. Nous avons donc une ingénierie capable de suivre la bonne mise en place et de la bonne appropriation par les équipes des outils préconisés lors de la mission.
Quels sont les aspects de ton travail que tu aimes le plus ?
J’aime beaucoup le fait que mes missions m’habituent à faire de la veille, car je suis amené à voir énormément d’environnements techniques et je suis donc à même d’utiliser des technologies Cloud, des outils d’orchestration de conteneur (comme Kubernetes), des outils serverless, des registry de conteneurs, des outils de CI et de test, des langages et outils de build associés, des intégrations avec GitLab… C’est quelque chose de très enrichissant. Cela me permet d’avoir un panorama des techniques, des outils et des méthodologies assez appréciable et cela m’évite de m’enfermer dans une seule technicité.
Deuxième chose que j’aime dans mon travail : mes collègues. Les PFS permettent des échanges avec pas mal d’interlocuteurs en interne. Nous sommes devant l’équipe produit quand il s’agit de faire de l’avant-vente, nous sommes également avec les ingénieurs d’affaires quand il faut bâtir des propositions. Enfin, nous sommes aussi en lien avec la direction stratégique parce que nous sommes les premiers à prendre connaissance des problèmes clients, ce qui nous permet de proposer des directions pour la roadmap. Cela me plaît d’être partie prenante sur ces sujets.
En conclusion, comment définirais-tu les qualités essentielles pour mener à bien ta mission ?
Je dirai qu’il faut avant tout être capable de « passer le ballon » : le monde du test automatisé et du DevOps est très vaste et on ne peut pas humainement tout maîtriser. Il faut donc être capable d’analyser les moments où nous atteignons la limite de notre connaissance et savoir identifier la personne capable d’avoir un élément de réponse pour transmettre la question, tout en s’assurant que cette personne ait la capacité de revenir vers nous au plus vite.
Je parlerai dans un second temps de la nécessité de savoir porter conseil, et de parfois le faire de manière un peu péremptoire. Il s’agit de porter le savoir méthodologique des PFS sur l’outil Squash de la façon la plus claire, compréhensible et concise possible. Ainsi, le client peut avoir les clefs pour faire vivre et adapter la méthodologie à son contexte.
Le troisième atout est d’être à l’aise et curieux au moment de se plonger dans les aspects techniques d’une mission. Par exemple, l’un des outils phares pour faire de l’automatisation en ce moment, c’est Robot Framework. C’est donc un outil que j’ai largement étudié, et ce, même entre mes missions. Cependant, si un client a des équipes de développement qui utilise Cypress, nous devons être aussi (et sommes donc) capables de l’accompagner avec Cypress.
Pour contacter Florian et son équipe autour de sujets liés à Squash AUTOM/DEVOPS :
Pour contacter Florian et son équipe autour de sujets liés à GitLab :
En savoir plus sur l’expertise d’Henix autour de GitLab :
