Défis et perspectives des tests logiciels en 2022.

Bonjour et bienvenue sur cette e-conférence organisée conjointement par Group Open et Smart Testing. Je suis Michel Guz, président et co-fondateur de Smart Testing, et je serai aujourd'hui l'animateur de cette e-conférence. Mais évidemment, les acteurs principaux, comme vous le savez, sont deux experts : Françoise Barbeau et Bruno Lejard. Alors, Françoise est responsable de l'offre testing au sein d'Open, mais elle est aussi directrice adjointe du centre de production testing d'Open, notamment sur le site de Nantes. Françoise anime également le chapter France TMMI pour le compte du CFTL, multicertifiée SAFe Scrum Master, TMMI Coach Testing. Bref, vous avez affaire à une experte testing avec une expérience terrain très riche et variée depuis plusieurs années. Et puis, Bruno Lejard, qui lui aussi, a plusieurs casquettes. La plupart d'entre vous connaissent Bruno pour son rôle au sein du CFTL. Il a été pendant des années la cheville ouvrière de l'organisation de la JFTN. Mais il est également actif au sein de l'ISTQB. Il est co-fondateur et CSO de Smart Testing. Et enfin, il encadre des travaux de recherche notamment sur la machine learning appliqué à l'automatisation des tests au sein du laboratoire informatique de l'Université de Bourgogne-Franche-Comté.

Alors, cette e-conférence est le point d'or de travaux conjoints réalisés par Françoise et Bruno sur les impacts pour le test de la transformation vers l'agilité métier, travaux qui ont donné lieu à la production d'un livre blanc accessible sur le site internet d'Open et sur le site internet de Smart Testing. Et puis, aussi, ça a donné lieu à des courtes cartouches vidéo, dont la première est déjà en ligne et les suivantes suivront très prochainement. Donc, n'hésitez pas à aller télécharger le livre blanc si ce n'est pas déjà fait, sur les sites de Smart Testing et d'Open.

Alors évidemment, ces ressources, que ce soit le livre blanc ou les cartouches vidéo, sont des formats unidirectionnels de nous à vous. Avec cette e-conférence, notre volonté est d'avoir un événement interactif, vous donner l'opportunité d'interpeller nos experts et d'obtenir des réponses aux questions que vous vous posez. Alors, on ne peut pas donner la parole à tout le monde, on ne peut pas ouvrir tous les micros, mais vous pouvez utiliser la fonction question, plutôt que la fonction chat, de la plateforme de webinar pour poser vos questions, faire des commentaires, des remarques, etc. Et je me ferai votre porte-parole en relayant vos questions à Françoise et Bruno.

On a également un invité, un témoin, en la personne de Jérémy Delot, qui a la charge du test engineering et du test automation chez Crédit Agricole Assurance. Jérémie interviendra à quelques moments clés de la conférence pour vous dire ce qui a été mis en place chez Crédit Agricole Assurance et les initiatives pour les mois à venir.

Voilà, on a pris quelques minutes pour cette introduction, ça a permis aux derniers arrivants de se connecter tranquillement. Alors, on peut commencer, et pour cela, je vais demander d'abord deux choses à Françoise et Bruno : de nous repréciser ce qu'est l'agilité métier, et puis de nous expliquer ce qui les a poussés à travailler ensemble sur l'impact pour le test de la transformation vers l'agilité métier.

Je vais commencer donc, Françoise, si tu veux. Alors, ça fait longtemps qu'on travaille ensemble avec François sur différents aspects, au processus, aux pratiques, aux évolutions des organisations, en particulier dans le contexte du Comité Français des Tests Logiciels. Et le point déclencheur, c'était la conviction commune que les difficultés de cette transformation qu'on constate sur le terrain (et on va voir des chiffres juste après dans l'enquête du CFTL), et puis dans les remontées de terrain, les difficultés liées à la vitesse de l'adaptation ne sont pas une fatalité. Il y avait des éléments clés, des bonnes pratiques, en particulier, on va le voir dans cette vision de bout en bout de la façon d'appréhender la réorganisation des pratiques de test, l'organisation de test, et que c'était là-dessus qu'il fallait construire pour mieux faire face aux défis. La volonté commune qu'on a eu, c'est de formuler ça, voilà, de l'écrire, de le partager dans des vidéos, et surtout de le discuter. Puisque il s'agit pas de, on a fait remonter des constats, de ce qu'on voit sur les différentes situations, contextes clients. Donc, avec l'envie de le partager, de l'échanger, d'avoir aussi cet échange riche qu'on va avoir aujourd'hui. Donc, le point de départ, c'est cette compréhension. Voilà, c'est difficile aujourd'hui parce que les choses sont fortement accélérées. Alors, juste pour terminer, puisque tu as mis ce slide en avant, notre premier support, que vous retrouverez du reste dans le Livre blanc, mais aussi donc dans les éléments sources sur le site du CFTL, c'est l'enquête du CFTL, qui a l'intérêt d'être réalisée périodiquement maintenant depuis 2013. Ça veut dire quoi ? Ça veut dire qu'on ne voit pas seulement un instantané comme les chiffres qui vous sont montrés là, mais les tendances. Et ces tendances, ce qu'elles mettent en évidence, c'est d'abord une accélération de cette transformation. Ça va très, très vite, et ça pose des difficultés, cette accélération de la transformation. Le deuxième élément qui est important, et je vais passer la parole, c'est le fait que c'est piloté par la valeur. Il y a une volonté des organisations de piloter la transformation agile par la valeur, de délivrer réellement, de la benchmarker, de la mesurer, et que ça a un impact réel sur leur compétitivité. Donc, voilà, rapidité, pilotage par la valeur, impact, voilà les mots clés qui caractérisent les organisations aujourd'hui.

Merci, Bruno. On peut effectivement rajouter, compléter avec le fait que finalement, dans ce pilotage par la valeur métier, le test va finalement s'imposer peut-être encore plus qu'avant comme vecteur de la qualité, sans laquelle il ne peut pas y avoir de valeur délivrée. Et voilà, ça c'est aussi un élément qui nous a poussés à travailler ensemble avec Bruno. Alors, c'est vrai qu'on se connaît effectivement depuis longtemps avec la JFTM, mais je crois qu'on partage vraiment une passion commune sur ce métier du test, sur sa professionnalisation, sur l'adaptation de ce métier aux différents défis qui arrivent régulièrement, d'année en année. Et puis, on a une complémentarité aussi, Open et Smart Testing, puisque Open est partenaire des solutions de Smart Testing. Donc, voilà, on a l'habitude d'échanger sur tous ces sujets. On peut d'ailleurs le voir dans les défis, peut-être, voilà, sur lesquels je vais te laisser continuer, Françoise, qui remontent quoi.

Effectivement, sur ces défis, au niveau de la transformation, on en a relevé trois importants, mais il est évident qu'il y a plusieurs défis. Mais le premier défi, c'est ce qu'on a appelé la collaboration entre les équipes IT et métier pour accroître la valeur des livrables. Et ça, c'est important. J'accompagnais un client fin d'année dernière qui avait commencé sa transformation agile au sein de sa DSI sans impliquer les métiers. Et en fait, très rapidement, il a été confronté à des problèmes d'échange avec le métier, à des problèmes de priorisation, et je pense qu'il n'a pas réussi finalement à atteindre cette notion de valeur métier, de satisfaction de ces utilisateurs finaux. Donc, cet alignement, il est vraiment important, l'alignement, bah forcément, du test et de la qualité dans toutes les activités. Et ça, c'est vraiment le premier défi. Le deuxième qu'on constate, c'est l'évolution des rôles et des compétences attendues des testeurs. Alors, je mets testeur entre guillemets parce que finalement, dans le contexte agile, la qualité, c'est l'affaire de tous, ça vous le savez. Et on va avoir des testeurs au sein des équipes, mais on va avoir aussi des testeurs au sein des systèmes teams transverses. Si on est dans un contexte SAFe, par exemple, on peut avoir des testeurs spécialistes au sein de l'architecture. Donc, c'est vraiment derrière testeur, une partie prenante du test, parce que j'ai eu un petit échange il n'y a pas très longtemps aussi sur le sujet. Et en fait, ces rôles et ces compétences touchent finalement toutes les parties prenantes du test. Alors, le testeur équipage, cette fois-ci.

Donc, celui qui est au sein des équipes va vraiment évoluer à travers une posture de facilitateur et d'animateur du test et de la qualité au sein de l'équipe. Donc, il va aider finalement toute l'équipe à progresser sur ce volet de l'agilité et de la qualité. Le deuxième volet d'évolution des compétences, et ça fait le lien avec le 3e défi, c'est l'évolution des compétences techniques. Le troisième défi, c'est qu'on a une accélération des rythmes de mise en production, qui pour certains clients sont des rythmes de 3 semaines, donc ça va vite, donc ça revient régulièrement. Et ce rythme des mises en production nécessite d'automatiser le plus de tests possible. Et de ce fait, cette compétence technique doit aussi évoluer vis-à-vis du testeur. Alors soit effectivement, il a une réelle appétence et il va pouvoir se diriger vers l'automatisation, il a des compétences antérieures techniques qui lui permettent de, mais à minima il doit pouvoir être capable, bien sûr, de discuter automatisation avec l'ensemble de l'équipe, de contribuer à la stratégie d'automatisation, etc. Donc, on a besoin effectivement d'une évolution de ces compétences aussi techniques. J'ai parlé d'automatisation, mais c'est vrai aussi pour l'ingénierie de la qualité au sens large, avec l'intégration continue, avec tous ces éléments qui vont de pair avec l'agilité. Alors, merci Françoise pour toutes ces, on pourra bien définir les défis, on n'a pas encore de questions à ce stade, mais moi j'en ai rencontré une assez récemment lors d'une réunion où j'ai présenté les concepts de l'agilité métier, et j'ai eu une test manageuse femme qui me disait : "Je me retrouve bien dans les constats que vous faites, mais aujourd'hui la pression est forte pour nous transformer rapidement afin de répondre aux enjeux du marché. Le souci, c'est que nous subissons cette transformation, tout doit évoluer en même temps et nous ne savons plus vraiment où donner de la tête." En réalité, c'était ça, et elle se tournait vers moi en me demandant comment on peut s'en sortir. Et j'imagine que si cette question m'a été posée très récemment, elle doit traverser l'esprit de certains de nos participants aujourd'hui. Donc, qu'avez-vous à répondre à cela ? Je commence, Bruno, si tu veux ?

Ouais, moi je dirais donc que l'approche est basée sur une vision des quatre piliers de la transformation. Si tu passes au slide suivant, en fait, on ne peut pas prendre les problèmes isolément. On ne peut pas, par exemple, se consacrer à l'automatisation de l'exécution des tests indépendamment de la vision de bout en bout de l'approche, qui va de la capture du besoin jusqu'à la conception des tests, les critères d'acceptation, la conception des tests et leur automatisation. Et ça veut dire quoi ? Ça veut dire que ces défis, il faut les prendre de façon complète, effectivement, mais pour autant, il faut le prendre avec des lignes directrices et c'est ça qui va faciliter, c'est ça la réponse, en fait, Michel. C'est-à-dire que, et pour nous, les point clés sont les suivants, c'est mettre en place les pratiques collaboratives en premier lieu et le faire de façon engagée avec le sponsoring du, on va le voir, on va détailler ça, et Françoise va dessus, mais la question collaborative tirée par la valeur, c'est le point d'entrée, les ateliers qu'on met en place qui permettent d'aller de l'expression du besoin jusqu'à justement la mise en place des moyens de vérifier que le besoin est satisfait. C'est le cœur du sujet donc, à travers, c'est ce qu'on voit, le Simon global, c'est revisiter ensemble des pratiques sur une efficience collective, le faire après par amélioration continue, donc dans une démarche progressive mais en gardant toujours ce cap et donc c'est en gardant le cap et en itérant sur les améliorations et ça ça s'oppose à ce qu'on constate assez régulièrement, c'est-à-dire finalement des chantiers un peu dissociés et avec finalement un manque d'efficience, un manque d'effet, quoi, un manque d'impact, tâtonnement. Si je peux intervenir, ce que je ressentais dans la question de la personne en question, c'était, c'était qu'on tâtonne et je crois que justement les travaux que vous avez réalisés sont destinés à éviter les tâtonnements et à donner à fixer un cap.

Finalement, on fait constat de ces organisations qui se cherchent, qui se progressent, qui avancent progressivement. Voilà, donc c'est aussi ce qui nous a motivés, avec Bruno, pour élaborer ce livre blanc afin d'apporter notre tour d'expérience que nous avons pu avoir, je dirais chacun de notre côté, et faire en sorte que ça puisse vous guider, ça puisse vous aider à aller plus vite dans cette transformation sans perdre trop de temps, en fait. Donc, en bénéficiant finalement déjà de nos expériences. Voilà, et puis avec des convictions fortes, hein. Je pense qu'on va passer justement en revue chacun des quatre maintenant. Et la conviction forte, c'est en particulier que le partage d'une formulation visuelle des parcours applicatifs va être un fil conducteur finalement de la capitalisation sur le couple expression du besoin et test. Ça, c'est important. Voilà, non mais c'est important. Voilà, de aussi dire que c'est ça, on structure finalement la vision qu'on porte ensemble avec Françoise là, dans ce livre blanc. Structure une démarche de facilitation de la transformation, d'accord. Donc on va peut-être justement passer en revue les différents piliers, un par un, même si tout est lié, hein. On a bien compris que tout était lié, mais malgré tout, on va aller sur chacun des piliers, des quatre piliers, en commençant par celui de l'organisation, hein, des aspects organisationnels. Si j'ai bien lu le livre blanc, finalement tout part d'en haut de la hiérarchie, s'agissant des évolutions de l'organisation. Est-ce que c'est bien ça ? Oui, alors je voudrais juste rebondir sur ce terme hiérarchie, que je n'aime pas trop et qui me semble de moins en moins adapté sur les organisations agiles à l'échelle. En fait, on va avoir des business owners, des managers d'entreprise qui vont donner la vision et ça, c'est important. Et l'agilité, aujourd'hui, fait en sorte que tout le monde contribue, que les gens se synchronisent en ligne, que l'autonomie se développe, que la créativité aussi se développe. Donc, voilà, on est un petit peu moins dans ce modèle que l'on connaît forcément, hein. C'est notre référence aussi, qu'on connaît sur le côté hiérarchique. Donc, voilà, je parle plutôt de vision qui est donnée par les managers de l'entreprise et qui va permettre justement à l'ensemble de l'entreprise d'avancer dans le cadre de cette vision. Alors, c'est vrai, c'est le premier pilier, hein, l'accompagnement de l'organisation. Cette vision, elle doit être, elle doit permettre de définir, bien sûr, effectivement la valeur attendue, tout ça. Mais elle va permettre de définir aussi en quoi la qualité et le test vont être importants dans l'entreprise, et ça, c'est fondamental. Dans tout changement, le rôle du management sur ces sujets-là est vraiment de porter ce message et de soutenir les équipes dans cette direction. Donc, la définition du niveau de qualité visée va permettre de dire voilà effectivement ce que l'on souhaite dans notre entreprise, et ça va pouvoir donner lieu notamment à l'élaboration ou à la mise à jour de la politique de test de l'entreprise qui va permettre justement d'aligner l'ensemble des parties prenantes sur la différente répartition des tests, sur la mesure de la performance du test, sur tous ces sujets. Alors, bien sûr, on le verra dans le pilier 2, mais le sujet des compétences est très important. Et donc, le manager doit impulser également des plans de formation pour former, acculturer à la fois les managers, à la fois les testeurs, mais globalement toutes les parties prenantes sur l'agilité et sur le test dans un contexte agile. Ça, c'est important aussi pour faire en sorte que l'on parle le même langage et que l'on ne perde pas trop de temps à se poser des questions sur le qui fait quoi, etc. Donc, ça, c'est important effectivement de pouvoir apporter ces éléments de base. Alors, bien sûr, on l'a vu tout à l'heure avec le défi, avec le testeur qui va évoluer, avec des rôles et des responsabilités qui évoluent. C'est vrai que ça nécessite aussi de repenser les carrières, les évolutions de carrière des parties prenantes, sur le test, des testeurs, des concepteurs du test, test manager pour leur redonner de la vision dans ce contexte, dans ce contexte agile. La formation, c'est une chose, ça ne suffit pas. L'accompagnement est important derrière. Dans l'agilité, il y a un levier qui est intéressant pour justement prendre le relais de la formation, accompagner, partager, capitaliser. Ce sont les communautés de pratique et ça, c'est important aussi de pouvoir les mettre en place, de les soutenir, de les encourager. Ça, ça va être le rôle du management de les encourager, d'encourager ce développement au sein, je dirais, de collaborateurs de groupes qui vont avoir le même métier, la même intention. Voilà, donc ça, ça va être également important.

Et puis rapidement, il faut qu'on soit capable de mesurer comment on avance. Est-ce qu'on avance dans la bonne direction ? Est-ce qu'on avance ? Quels sont les pas qu'on est capable de faire, de franchir et comment on les intègre, comment on les valide quelque part ? Et ça, c'est de mettre en place assez rapidement des indicateurs, je dirais, une mesure de maturité. Ça se fait beaucoup en agilité sur les principes de l'agilité même. Il faut poursuivre ça sur le volet de la qualité, avoir des mesures d'évolution de la qualité, des progrès qualité qui sont faits dans l'entreprise à travers tout ce que l'on va mettre en place pour cette transformation agile. Et puis, bien sûr, le soutien, l'alignement budgétaire pour permettre des investissements sur des nouveaux outils, parce qu'il y a des nouveaux outils. Il y a effectivement ces sujets qui sont importants et que le manager, l'organisation, doit vraiment porter tout au long de cette transformation. Donc, voilà pourquoi le premier pilier sur l'organisation il est important parce que c'est vraiment le oui, la tendance, c'est la direction qui va être donnée et ensuite une fois que le mouvement va être lancé, c'est le soutien de ce mouvement pour l'accompagner, l'encourager pendant toute cette transformation et au-delà, avec peut-être un point important sur les risques qu'il faut modérer. C'est-à-dire que ce qu'on peut constater dans certains contextes, c'est que ce pas à l'itéré par exemple, le fait qu'on va dispatcher les testeurs dans les équipes là où ils étaient constitués, va se faire dans certains cas avec une perte de savoir-faire, dans d'autres cas non, on constitue proprement les communautés de pratique par exemple. Alors, on va capitaliser, continuer à faire progresser les équipes sur les bonnes pratiques des tests, mais dans certains cas, on voit que c'est oublié, ce qui fait que le risque des risques à modérer est vraiment la perte de savoir-faire sur finalement qui est notre histoire dans le domaine du test. On a acquis ces savoir-faire ces 15 dernières années et dans cette transformation, voilà, et c'est pas une fatalité encore une fois, c'est-à-dire que justement les organisations, par communauté, la dynamisation de la communauté, les confrontations des pratiques et l'amélioration continue des dites pratiques constituent des outils. Mais c'était pour dire que on a vu sur le terrain, on voit sur le terrain finalement aussi des régressions qui se traduisent sur la perte de qualité du produit ensuite en l'opération.

Alors, j'ai une question là qui a été posée par un participant qui dit la chose suivante : quand en quelque sorte il y a quelques doutes sur les capacités des managers à comprendre tout ça, quand on était en cycle en V, voilà la question. Quand on était en cycle en V, le test était souvent la variable du justement des projets. Avec l'agilité, le test a été accusé d'être le goulot d'étranglement des projets, avec tout ce passif mental qui a ancré le test dans une position de mal nécessaire depuis des années. Quels sont les éléments de conviction que vous utilisez, vous, Françoise, Bruno, pour mettre le test au centre des préoccupations des managers ? Alors, peut-être je peux réagir à ça. Ce que j'ai en tête, c'est l'évolution du wording de l'expression. On est passé donc d'assurance de la qualité et on parle maintenant d'ingénierie de la qualité. Et ça, c'est, ça veut dire que, bien sûr, qu'on a design Byas, voilà, qualité par construction, quality by design, mais cette, ce concept de la qualité intégrée se traduisant par une organisation qui assume l'ingénierie de la qualité. Dans l'ingénierie de la qualité, il y a l'ingénierie des tests, évidemment. Peut-être la bonne réponse à ça, c'est-à-dire que à une réponse qui a un peu le déni en fait du, et bien est une réponse par le haut, par le haut. C'est dans la compétence, dans l'ingénierie, dans les technologies pour justement intégrer l'ensemble des facettes du test. Et je trouve que, comment dire, la communauté du logiciel, globalement, quel que soit les secteurs, évolue dans ce sens-là, dans une intégration de, et donc ça veut dire que effectivement l'ingénierie de la qualité concerne l'équipe, concerne l'ensemble de l'équipe, avec les rôles de testeur qui dirigent ça aussi maintenant, qui viennent de leur savoir-faire. Alors, après les aspects organisationnels, il y a la question des compétences que vous avez déjà abordée. J'imagine qu'il ne s'agit pas pour les testeurs de retourner à l'école et d'oublier tous les acquis d'expérience et de certification ISTQB, etc., qui ont été travaillés pendant toutes ces années. Vous l'avez déjà dit, mais peut-être pouvez-vous élaborer un peu plus sur les aspects de compétences et d'acculturation dont vous avez parlé là, que vous avez évoqués rapidement sur la partie organisationnelle ? Oui, alors c'est effectivement le pilier 2. Donc, on a vu cette évolution qui est un élément important. Alors, c'est vrai que le rôle du testeur va évoluer, mais par rapport à ce qu'on vient de dire notamment, je crois qu'il va évoluer en capitalisant sur son socle de compétences sur le métier du test acquis au fil des années, et ça c'est important. On est plutôt dans une évolution et on n'est pas dans une révolution de ce rôle, on est dans une évolution pour effectivement s'intégrer dans l'agilité. Je discutais encore hier avec un client que j'accompagne sur les formations qu'on pouvait mettre en place justement sur le sujet. Il me disait : "Oui, bon bah effectivement, sur ce qui est technique de conception, bon ça c'est des choses qui sont acquises". Je lui dis : "Ça serait quand même bien de d'en reparler, parce que justement dans l'agilité ce qui va être important, c'est vraiment la pertinence du test. C'est pas seulement faire des tests, c'est faire les bons tests, c'est choisir, aller vers une efficience encore plus renforcée du test". Et là, les compétences sur les techniques de conception, sur l'utilisation des valeurs limites, sur les classes d'équivalence, sur ce genre de choses, il est encore plus important. Donc, en fait, on voit bien qu'on est en train de renforcer ce socle, bien sûr, de le faire évoluer, parce que il y a des nouveaux sujets sur l'agilité, il y a le shift left, hein, le fait que le testeur va devoir, il est nécessaire en fait qu'il soit impliqué très tôt dans le cycle de construction du produit, qu'il puisse accompagner le product owner dans la définition des critères d'acceptation, etc. Donc, il a effectivement un rôle qui évolue, qui est plus en amont, qui bien sûr se complète d'éléments d'agilité qu'il doit maîtriser, qui se complète d'éléments techniques que l'on a vu notamment pour prendre en compte l'automatisation le plus tôt possible. Voilà, donc, tout ça effectivement c'est, on est dans cette évolution et il ne faut pas laisser le testeur s'adapter tout seul à son niveau, dans son coin. C'est pour ça que la formation, l'accompagnement des testeurs est important. L'ISTQB a effectivement mis en place depuis longtemps déjà, je dirais, un module de formation sur le testeur agile. Mais il y a aussi d'autres modules, il y a effectivement sur la pratique de la TDD, hein, des tests d'acceptance, il y a effectivement des formations avancées sur la partie agilité technique, et puis il y a effectivement d'autres formations qui commencent à se mettre en place autour de la continuité de la livraison et surtout du test dans cette continuité de la livraison. Donc, l'offre de formation elle évolue et il faut vraiment s'en saisir pour apporter, je dirais, à l'ensemble de vos collaborateurs voilà ce qu'il est nécessaire pour qu'ils puissent évoluer à nouveau en étant confiants dans cet environnement et pas méfiants, en disant oui, bah voilà, je vais pas avoir ma place, etc. Faut vraiment les accompagner et c'est vraiment le message important. Peut-être pour appuyer, hein, ce que tu dis, Françoise, je vous ai mis le lien sur istqb.org, hein, que vous connaissez, mais si vous y allez, vous verrez que le site est nouveau. Mais, sur le schéma ISTQB, vous verrez dans le track agile au niveau avancé, il y a deux formations, il y a deux certifications, l'une qui s'appelle testeur technique agile, l'autre qui s'appelle agile test leadership at scale. Ça veut dire quoi ça ? Ça veut dire que en fait il y a bien deux directions à renforcer, l'une qui est sur les compétences techniques des testeurs dans l'agilité qu'on vient d'évoquer, il y a l'automatisation, et l'autre c'est le leadership dans l'organisation, c'est le justement irrigué de cette bonne compréhension de la qualité infiné et de la façon de bien tester, de la pertinence des tests. Donc, et suivons les profils, ça veut pas dire que vous devez chercher à avoir des moutons à cinq pattes.

C'est un risque et une contradiction, évidemment. Ce n'est pas ça qui est le sujet. Le sujet, c'est de se dire qu'en fonction de l'histoire et des compétences du parcours de mes collègues, des membres de l'équipe, et bien finalement, il y a deux trajectoires pour eux. Il n'y en a pas qu'une. En fait, trop souvent, on imagine qu'il n'y a qu'une trajectoire, c'est aller vers le "pouding", quoi, aller vers plus de sujet technique et qui, évidemment, peut être en même temps toujours moins pertinent des tests, quelque part moins de compétences métier. Non, non, ce n'est pas ça. Il y a des voies et voyez, je vous incite à regarder justement cette certification récente, elle est encore en Beta, qui s'appelle "Atlas Test Leadership at Scale". À l'échelle, parce que justement elle correspond au positionnement des testeurs dans leurs compétences, à partir de la compréhension fine de ce qui est le donc le important à tester, leur connaissance métier et la façon dont ça évolue dans l'équipe. Vous voyez, hein, c'est juste pour dire que trop souvent récemment, enfin, on a entendu des discours comme quoi le testeur fonctionnel, bah, c'était juste mort. Mais non, pas du tout, pas du tout. On a, au contraire, une, je dirais, une mise en avant pour une partie de ses rôles autour de ces de l'impact dans l'équipe. C'est très bien ce que tu dis là, Bruno, parce que ça répond à une question qui a été posée sur le fait que certains voient une pression. Alors, je lis la question : "Il y a une très forte pression sur l'automatisation des tests, et la tentation de la confier au développeur, d'une part, et de l'autre, il y a l'émergence des technologies qui font un peu fantasmer, et dans ce contexte, on voit que certains testeurs s'interrogent sur leur évolution de carrière et sur le bien-fondé de leur rôle." Et là, tu viens de répondre finalement à cette interrogation. Donc, en disant que clairement, il y a un avenir, évidemment, au rôle de testeur, et ce métier-là est un vrai métier, une vraie carrière. En fait, vous savez, les tests les moins chers, c'est ceux qu'on ne fait pas. Ça veut dire quoi ? Ça veut dire qu'un des rôles les plus importants, c'est de distinguer à un moment donné ce qui est prioritaire, ce qui doit être réalisé, ce qui est pertinent. Et ça, ben, ça, c'est une connaissance intime des enjeux liés au produit, mais aussi un savoir-faire de testeur dont nous, on est persuadé, hein, vraiment que, en fait, c'est ça. Il est en train, il va se valoriser. Et c'est un petit peu à contre-discours, je suis d'accord, et pourtant, voilà, ce qui va se passer, et c'est pas voilà ce besoin-là, ces compétences-là, c'est celle-là qui va se valoriser.

Ah, on va arriver alors à ce stade, effectivement, de notre e-conférence, un peu pour rythmer les choses. Je propose à notre invité Jérémie Delot, qui travaille donc sur précisément sur l'ajustement des activités de l'ingénierie du test et de la qualité et de l'automatisation des tests au sein de Crédit Agricole Assurance, de nous dire s'il se retrouve dans les éléments partagés jusqu'à maintenant. Et peut-être, Jérémie, aurais-tu aussi une ou plusieurs questions à poser à nos experts ? Donc, je te laisse prendre la parole. Merci beaucoup, Michel. Bonjour à toi, à Bruno et à Françoise aussi. Merci de m'avoir invité. Effectivement, au sein de Crédit Agricole Assurance, on a lancé la transformation du test dans l'agilité depuis début 2020. Et ce qui est intéressant, c'est que toutes les étapes qu'on a faites au tout départ, on les retrouve dans vos piliers 1 et 2. Par exemple, on a démarré en définissant la politique de test avec vraiment une vision globale de l'ensemble des phases de test, que l'on soit en cycle en V ou en agile, et ça a permis à chaque intervenant de comprendre qui fait quoi et à quel moment. Donc, ça, c'était déjà pas négligeable. Également, ce que l'on a fait, c'est qu'on a défini un cursus dédié à la formation des testeurs, et aussi on a dédié des rôles fonctionnels dédiés au métier du test pour désigner des testeurs seniors, et cetera. Également, ce qu'on a fait, bah, c'est intégrer le rôle de QA dans les squads. Au départ, on les a sensibilisés, mais on a vu que ce qui était nécessaire, c'était qu'il ait un QA vraiment qui intervienne spécifiquement et qui est ce rôle dédié et qui est cette formation dédiée au test. Et puis on a défini des pratiques de test sur les tests applicatifs niveau QA dans la squad, en mettant en place la cérémonie des tri-amigos, en formalisant les tests en gherkin, mais aussi en ayant une approche de conception visuelle des tests, parcours du test avec Yes Test. Donc, là, on se retrouve totalement dans ces deux premiers piliers. Et nous, on veut accélérer les choses, notamment sur l'automatisation. Et on se posait la question : est-ce que le rôle du QA ne va pas encore évoluer ? Parce que, voilà, il est intégré dans la squad, mais nous, ce qu'on veut, c'est que la squad soit autonome pour automatiser. Alors, on a essayé plein de choses pour l'automatisation depuis 2020. On a essayé de mettre un automaticien qui est intégré, on a essayé des outils open, des outils payants, ça n'a jamais marché, ça n'a pas été probant. Il y a plein de raisons, je pourrais vous les citer. Une des raisons principales, c'est que un, ça coûte cher, et de la squad n'a jamais le temps d'accepter d'intégrer cet automaticien pour lui donner la matière et l'automatiser. Donc, ce qu'on s'est dit, et je n'ai pas retrouvé ça ailleurs, c'est de se dire : bah, voilà, c'est le QA ou le billet finalement, voire même le qui va automatiser. Alors, c'est pour ça, dans les compétences.

On voit donc qu'il y a un tout petit peu de connaissance technique, mais pour ça en fait, on est parti sur une expérimentation plus nos codes avec un outil comme AgileTest. Alors, c'était pas de fournir uniquement l'outil, c'est qu'on a accompagné quand même la Squad avec un automaticien qui va les aider à monter en compétence sur l'automatisation, les critères voilà d'éligibilité, mais aussi pour les outils, pour les accompagner à l'outil, les bonnes pratiques de structuration du script, et cetera. Mais ma question, c'est est-ce qu'on part dans la bonne direction et est-ce que c'est ça l'avenir, finalement, c'est donner le la Squad l'autonomie, le Q à faire lui-même l'automatisation, et quels sont les pièges finalement à éviter ?

Je pense que vous êtes dans la bonne direction, c'est-à-dire que, en fait, l'élément clé c'est aussi de bien avoir en tête la pyramide des tests, de bien se dire que le point important, c'est la valeur ajoutée des tests automatisés fonctionnels que vous apportez à ce moment-là, de leur impact en matière de prévention des anomalies en production et des anomalies qui comptent, évidemment, et du coup de bien faire le lien. Donc, c'est pour ça que je pense que c'est la bonne approche réellement de bien faire le lien entre la pertinence des tests, la sélection des parcours à tester, qui est l'élément clé, c'est-à-dire que là où vous allez gagner du temps, c'est dans la bonne sélection, vous allez gagner en efficience. Et puis, on peut quand même imaginer que, il y a du support technique qui puisse venir en appui, c'est-à-dire qu'il ne soit pas non plus forcément sans appui. C'est ça ce que je veux dire, c'est que le sujet principal, c'est celui-là, c'est-à-dire faire les bons tests, automatiser les bons tests, et donc porté par ce sachant qu'est le Q. Après, le fait qu'il puisse avoir accès à du temps de support, à d'un technicien à des moments donnés, et lui-même bien sûr en puissance, ça, ça doit être naturellement fait, à mon avis. Donc, il y a peut-être ce point là de votre côté qui soit pas, tu vois quoi, qui soit pas, je veux dire, qui sente pas à un moment donné laisser tout seul, mais la logique est voilà, la logique est la bonne logique, c'est ça en fait. Dans l'automatisation, il y a aussi, enfin, abondé un peu dans ton sens Bruno, et il y a souvent l'idée de l'automatisme qui travaille tout ça dans son coin, et en fait, dans les préconisations sur l'automatisation que nous faisons chez Smart Testing, sans doute également Open, il y a l'idée aussi que l'automatisation, c'est pas que le sujet de l'automatisme, c'est le sujet de toute l'équipe. Et donc évidemment le PO, le Business Analyste, le testeur, et puis supporter aidé par éventuellement un collègue plus technique, on l'a dit tout à l'heure sur les quatre piliers, le ciment de ces quatre piliers, c'est la collaboration, et je trouve que l'automatisation c'est un bon exemple de collaboration, où effectivement ben le testeur, développeur, service de soutien, doivent collaborer ensemble pour automatiser le plus possible partout où c'est nécessaire. Et je rejoins, c'est une vraie difficulté, hein, Bruno.

Ah, on est qu'on progresse pas forcément beaucoup en termes de couverture, en termes de donc donc voilà donc ça va encore bouger. Il y a des outils no codes effectivement qui arrivent maintenant et qui vont permettre effectivement un accès à l'automatisation en limitant finalement le besoin de compétence hyper technique, mais voilà je crois que cette collaboration elle est vraiment aussi à mettre au service de l'automatisation. On parle de pair testing, de pair programming, moi je crois beaucoup au Pair Automation avec avec justement de la collaboration sur ces sujets. Alors, c'est ça, ça rejoint une question qui est posée là sur notre forum de question, une question qui me semble pertinente, c'est-à-dire on a parlé de la formation des acteurs des équipiers agile testeur, de l'équipier agile testeur quit des autres équipiers qui sont agile, et notamment Product Owner, architecte, voilà, la question qui est posée, et la personne dit : dans mon expérience, je rencontre parfois certains manques de compréhension du testing par ces rôles. Ou c'est un élément, pardon, vas-y Bruno ou c'était juste proposé d'afficher le pilier 3 et qu'on va partager tous les cas dans le pilier 3, on voit justement l'évolution des pratiques collaboratives, juste peut-être pour répondre à cette question. Mais en fait, c'était excuse-moi, Françoise c'était pour répondre, non mais juste pour dire que en fait quand on parle de cette collaboration, la culturation, elle se fait pas le changement finalement de pratique, on est absolument d'accord, c'est-à-dire que il y a la façon dont les testeurs vont se saisir de l'agilité, des pratiques, et cetera, du changement de rythme, et cetera, aussi, et d'intervenir plus tôt, mais ça veut dire que les autres aussi changent, et en particulier côté métier, à la fois du point de vue de la compréhension de quelle façon il est important de réfléchir à l'acceptation lors de la formulation du besoin, et que réfléchir à l'acceptation, scénario d'acceptation, c'est réfléchir en termes de test, et aussi dans le fait que ces tests après sont destinés à être à faire de la non-agression, et cetera. Et donc, c'est absolument vrai, c'est-à-dire que dans cette transformation, c'est l'ensemble de l'équipe qui évolue, pas seulement les testeurs, mais c'est à la fois la formation des personnes, mais aussi c'est de la formation action. C'est ça que je voulais dire, c'est-à-dire que c'est aussi dans la pratique quotidienne de du de du de la collaboration, des ateliers, hein concrètement les ateliers 3os, et cetera puis la pratique au quotidien qui fait que ça se diffuse voilà, mais après bien sûr que euh un un intérêt à se former au concept du test au concept de test d'acceptation au concept liés au BDD à la TDD hein donc aux pratiques collaboratives donc absolument voilà c'était pour lier finalement le la façon dont le travail s'organise concrètement en commun et le fait qui effectivement qui doit amener les rôles en particulier c PO à à cette dimension test de façon structurante quoi dans leur activité. Françoise, vous voulez ajouter quelque chose ? Vous aviez non non c'est ça là on travaille avec un client sur ces sujets là justement et ce qu'on a fait c'est qu'on a défini des personas pour l'ensemble des des parties prenantes et on a défini un parcours de formation par personas et le Product Owner en fait partie, les développeurs aussi en font partie et on a effectivement ciselé précisément en fonction de leurs besoins ce qu'ils ont besoin de savoir à minima pour que que cette homogénéité ce ce ce langage cette conviction commune sur les tests et la qualité se développe au sein de l'équipe et et en dehors de l'équipe au sein des trains alors euh j'ai des questions.

Euh alors j'ai des questions sur le chat, j'en ai une déjà qui me dit qu'on a mis en place chez nous le BDD à base de formulation Gherkin pour favoriser la collaboration entre les rôles métier et l'équipe, mais les métiers n'ont pas tenu à distance en fait et avec le Gherkin en tout cas, avec le Gherkin, et aujourd'hui ce sont les testeurs qui font les expressions Gherkin, ce qui est une un défaut de collaboration finalement. On perd tout l'atout de la collaboration, l'alignement métier a été sacrifié. Voilà ce que j'ai dis. L'alignement métier a été sacrifié sur l'autel de l'automatisation des tests à tout crain. Est-ce que vous pouvez répondre à ça? Alors moi je te propose de passer au slide, enfin CAD, parce que c'est vraiment une, comment dire, une expérience que qu'on a de façon récurrente. Que le BDD qui traite de façon très atomique c'est des critères d'acceptation a beaucoup de mal à être bien utilisé par les PO et finalement se retrouve être dans 80 % des cas, ce que moi je constate sur les projets, à être principalement un framework d'automatisation. C'est que Cucumber, pardon, égal égal dans 80 % des cas un framework d'automatisation et donc perdant passage finalement ce qu'on attend d'une formulation d'un scénario. Et là où on pense qu'il y a une alternative en partie dans une vision parcours applicatif avec évidemment la relation avec les cas, les règles métiers, et bien c'est de scénariser de façon graphique, de façon visuelle pour suivre les parcours applicatifs, lier les règles et pouvoir partager autour de ça les scénarios d'acceptation, créer les scénarios d'acceptation pour avoir finalement une vision qui n'est pas uniquement au niveau du critère d'acceptation de la User Story mais bien dans le contexte d'usage parce que infin ce qui est important c'est le contexte d'usage, le flot métier et là là effectivement on arrive mieux à incarner, formuler et finalement représenter en collaboration. Donc en synthèse la structure du Gherkin, le langage Given-When-Then qui est utilisé dans le BDD, nous restera un petit peu là où la partie visuelle nous permet d'avoir une vision facilement orientée parcours applicatif et partager ça répond bien à une question qui est posée là par un de nos participants qui nous dit les principaux défauts de qualité que je rencontre aujourd'hui sur des projets en agilité à l'échelle sont liés à des problèmes d'intégration des composants produits par les différentes feature teams entre eux. On voit bien que c'est effectivement la difficulté à avoir la vision globale et que les parcours applicatifs visuels peuvent contribuer à donner. Est-ce que je me trompe, Bruno?

Alors oui, j'ai envie de passer la parole à Françoise parce que justement elle est là dans des missions en cours de déploiement CF et je trouve que c'est bien de l'incarner sur voilà sur des projets safe concrets. C'est vrai que la vision de bout en bout est importante donc justement l'organisation dont on parlait tout à l'heure, le premier pilier euh, c'est de dire effectivement comment on s'organise sur ces sujets euh de feature team ou d'équipes euh jusqu'où vont les équipes, comment les relais sont pris, comment la synchronisation entre les équipes est faite, comment l'alignement est fait à partir des parcours visuels, éventuellement parcours métier euh, comment collectivement euh je dirais les process de bout en bout euh sont pris en compte. On a actuellement des échanges sur euh euh sur le rôle de la systemme team sur ces sujets-là euh. Bah on on est vraiment là-dedans, on on doit l'organisation doit dire euh bah voilà comment comment est-ce qu'on on adresse euh ces sujets alors là on est dans des sujets d'intégration euh de composants que nous nous met à jour euh, mais on a aussi euh je dirais des sujets d'intégration avec des composants externes parce que euh les SII sont plus que jamais ouverts euh sur l'extérieur et on peut avoir aussi des intégrations voilà dans dans tout ce qui est banque assurance service public les briques sont parfois externes et et donc il faut vraiment se poser la question de bah comment on décide de le faire comment on s'organise pour le faire et effectivement le niveau équipe peut paraître parfois insuffisant sur ces sujets là c'est ça c'est ça c'est-à-dire que le pilotage par la valeur c'est avoir une vision du flux métier de son en production des tests des cas enfin des parcours qui comptent hein ceux qui comptent et la façon dont on est capable de les formuler de les partager de distinguer les problèmes potentiels et et c'est là aussi où he c'est le le pilier 4 où l'outillage a son importance c'est-à-dire que pour que l'équipe soit efficiente il faut que tout ça soit fluide le travail qu'on a fait côté Smart testing et on travaille avec Open là-dessus depuis déjà quelques temps hein c'est de pouvoir proposer d'ailleurs c'est un adon gratuit de Gira donc un composant donc de d'édition mais aussi de qui permet de visualiser donc les parcours applicatifs dans Gira en le lien au User Story et en le liant au test qui sont couverts enfin en visualisant la couverture de test à la fois les tests qui sont réalisés mais aussi dans leur exécution donc que je veux dire par là c'est que on a aujourd'hui une plateforme qui auquel chacun contribue he qui est donc la plateforme de gestion agile sur lequel apparaissent les User Story et le fait de pouvoir incarner formuler et capitaliser hein parce que ça c'est un mot important s'appuyer dessus pour distinguer les parcours applicatifs à tester les parcours clés finalement c'est un outil d'efficience collective donc on voit voilà que par rapport à à la transformation AG où on a finalement mis de côté des pratiques documentaires qui existaient avantin on les a même arrêté hein et bien on est en train de se reposer des questions de comment être plus efficient et enfin moi il y a un concept que que je qui me paraît vraiment d'avenir en ce sens-là c'est la notion de documentation vivante c'està-dire de faire que la scénarisation des tests soit en fait un outil collectif de compréhension de ce que fait le produit en en d'autres termes et ça c'est en train d'émerger euh voilà bon on va peut-être euh laisser une nouvelle fois donner une nouvelle fois la parole à à Jérémie euh notre témoin qui va nous dire peut-être ce que chez chez casass Crédit Agricole assurance euh la chaîne outiller qui qui a été mise en place et qui euh euh peut-être derrière il y a une question ou pas mais en tout cas nous dire un petit peu ce qui a été fait chez cas sur le sujet de de la chaîne outiller oui merci Michel c'est vrai que on travaille sur l'automatisation là des Squad on n pas trouvé encore le bon dosage mais ce qu'on s'est aperçu c'est qu'il fallait d'emblé travailler sur cette chaîne pour qu'elle soit prête euh dès que dès que les équipes ont automatisé euh nous on s'est concentré dans un premier temps à automatiser les tests de non régression c'était déjà première étape et l'idée c'est c'est qu'on les a intégré dans cette chaîne outier et en fait euh comme tu l' expliqué Bruno c'est qu'on a cherché à fluidifier les choses au lieu que chaque Squad et leurs propres outils cherche à les intégrer avec ce qui va bien avec les gitlab les Jenkins à s'intégrer on voit qu'il perdent de l'énergie en fait nous on a créé une plateforme de de test automatisé et mutualisé par toutes les équipes de test et en fait cette plateforme elle est constitué principalement de machines virtuelles on a un pou de de Mach qui est dédié soit la conception des tests automatisés donc c'est un c'est une machine qu'on qu'on met à disposition à la Squad où tout est installé dessus les outils d'automatisation peu importe sur laquel il veulent ils veulent y aller on leur laisse la main les flux sont déjà ouverts voilà c'est c'est des comptes techniques donc pas pas nominatif et chacun peut s connecter une fois qu'on leur lou la machine et ce fait que nous dans dans cette chaîne bien sûr on utilise la conception visuelle avec yes yes for Gira et avec ce plugin aussi yes avec agitest c'est c'est ce qu'on c'est ce qu'on expérimente donc voilà ça permet de concevoir mais pour la partie exécution ce que l'on a fait aussi c'est que cette plateforme automatisée est interconnectée avec un ordonnanceur dédié à l'exécution on a des machines qui sont dédiées à l'exécution ou la Squad à la main soit le font à l'adement de depuis Jenkins ou alors programmer ordonnancer suite à un build d'une release pour déclencher une batterie test où derrière ces script principalement sont sont pilotés par les les jeux de données et les preuves de test sont stockés sur un SHP

avec les jeux données donc ça c'est la Squad qui a la main ils accèdent au Jenkins il déclenchent leur test et ils ont les résultat l'étape suivante sur laquelle on travail c'est de pouvoir publier directement les résultats de dans dans xra voilà on est l'ensemble cohérent des des des des métriques et des reporting de test c'est ça effectivement plus ces tâes techniques sont automatiques plus la fluidité de la chaîne plus on peut se focaliser sur les choses importantes c'est-à-dire la pertinence des tests est-ce que la couverture de l'usage enfin des des des des des choses clés hein et puis évidemment augmenter finalement ce patrimoine dans C dans cet objectif là l'objectif de merci Jérémy pour ce témoignage pour cette explication on on arrive pas loin de de la fin de ce de cette conférence il y a une dernière question que que je voudrais poser aux experts au nom de de d'un de nos participants euh qui nous dit l'adoption de l'agilité amène à une forme d'abandon de la constitution d'un référentiel d'exigigen les parcours applicatifs de test permettre d'établir un référentiel de test accessible est-ce qu'un tel référentiel de test ainsi constitué donc de parcours applicatif graphique peut permettre un remplacement du référentiel d'exigence Renaud je pense que tu es bien placé pour répondre alors en fait justement le tout tout le sujet enfin il y a un double sujet il y a le sujet exécutable c'est-à-dire qu'effectivement euh ce qu'on qu'on a formulé est tout le temps à jour parce que ça correspond au test qu'on exécute et en même temps il faut avoir une certaine abstraction entre guillemets c'est pas une abstraction mais une capacité à être facilement accessible et effectivement le le comment dire les parcours applicatifs avec la visualisation des règles et des critères des cas en fait hein c'est-à-dire y compris des valeurs compris des valeurs au limite y compris des valeurs qui sont testées permettent finalement de visualiser les cas qu'on traite les cas que l'application traite de capitaliser dessus et de la partager compris avec des gens qui sont pas du tout concernés par le test mais qui sont par exemple intéressés par savoir qu'est-ce que l'application est censé faire quand il se passe tel telle chose donc oui je crois qu'il y a un très gros potentiel en fait pour pour déficience collective en capitalisant sur cette information en la partageant dans des wikiis ou dans euh dans dans des informations plus facilement accessible à l'ensemble des parties prenantes et donnant lieu finalement une traçabilité de ce que l'application fait comment à partir de comment on La Teste mais tout ça ça ça veut dire qu'effectivement on arrive à une certaine maturité dans euh dans l'usage de de ces représentations he finalement et puis que dans la liaison avec les tests ouais la chaî très bien on arrive au au terme de cette conférence il est 13h exactement donc on a tenu le timing je vous rappelle que cette conférence a été enregistrée vous recevrez un lien à partager avec vos collègues absents aujourd'hui et ou aussi pour vous pour la pour revisionner cette e-conférence je vous rappelle également le livre blanc qui est accessible sur notre site Web Smart testing et celui d'Open euh n'hésitez pas à le télécharger à le partager avec vos collègues à nouveau restez aussi à l'écoute de pour la mise en ligne de nos vidéos hein ça va être c'est une façon de de de revoir euh l'analyse de chacun des piliers dont on a parlé aujourd'hui euh en vidéo en 5 minutes donc c'est assez court et est assez est monté donc facile à à à digérer euh et puis c'est aussi le moment des remerciements donc je je remercie d'abord nos participants euh nos experts et puis aussi je participe pardon je remercie les les équipes d'Open et de smartfesting qui ont ouvré en backstage en coulisses depuis des mois en fait hein pour que ce contenu de qualité vous soit rendu sous divers formats eux-mêmes de qualité donc je pense notamment à Caroline destor à Laure le celeuse à Elodie Bernard merci à à toutes ces toutes ces jeunes femmes pour le rapport pour ce cette e-conférence donc on va se quitter je vous remercie beaucoup de votre participation encore n'hésitez pas à télécharger le livre blanc et vous recevrez le un lien pour visionner cette conférence ou la partager avec vos collègues à bientôt et bon appétit à tous je dirais il y a bientôt à la jftl merci à tous bonne merci à tous au revoir