1/5 - L’évolution de la QA : du contrôle qualité à la Quality Assistance

Welcome to the guide, the podcast that boosts your skills in quality engineering. I am Jean-François Frézi, expert in quality engineering and passionate about the transmission of knowledge. Every week, I share tips for transforming your way of working in quality engineering. Install yourself well, we are going for a new episode filled with concrete advice. Don't forget to subscribe to the newsletter to receive exclusive content and not miss anything. Every week, I read you actionable methods, effective tools and strategies on the best practices of the moment, with short, practical and accessible formats to all. So subscribe now to not miss anything. There is nothing else but Vincent Doss, who is the senior engineering and quality director. I don't say stupid things, but maybe. So I'm going to let you introduce Vincent who works at Open Classroom, I forgot to say it. Thank you for being among us to talk about the quality assistance during the next five episodes of this mini-series. Merci de m'accueil, je suis François, très content de pouvoir partager mon expérience dans ce format podcast. Donc oui, je suis senior engineering et un quality manager, même moi j'ai dû pas l'altir. J'ai changé de rôle récemment cette année. Avant, j'étais effectivement directeur qualité chez Open Classroom, mais j'ai pris un post de engineering manager cette année, même si je garde encore l'équipe qualité en management direct. Mais ça, c'est super intéressant. On ne s'est pas le suivi de notre podcast, mais on va quand même en parler. C'est quand même rare les profils qui a piloté l'engineering, qui deviennent CTO, VP Engineering, en ayant piloté des équipes de QA et en étant QA avant. Donc c'est quand même bien pour notre secteur et pour montrer qu'il y a d'autres opportunités. Voilà, je sais, on a Farah Shabshout, que tu connais aussi, qui est ce type of startup, qui est au bord d'une startup, comme quoi chacun fait son chemin. Et ça montre aussi qu'en fait du quality engineering, c'est de plus en plus technique et qu'on peut aussi piloter de l'engineering et pas que de la qualité. De toute façon, les deux sont liés, donc c'est intéressant. Mais voilà, donc en tout cas, fécitation pour cette prise de post. Merci. Et ce changement de paradigme pour toute la communauté. Donc aujourd'hui, on va commencer peut-être un peu sur l'évolution de la QA, comment on l'a vu. Alors peut-être pas tous nos auditeurs l'ont vécu de la même façon, mais non. Toa et moi, on a déjà beaucoup échangé sur le sujet au dehors de ce podcast, où comment on est passé du contrôle qualité à la QA, à la quality assistance, voire aux QA, c'est-à-dire plus avoir du QA dans ces équipes. Toa, ta un peu tout vécu, que ce soit avant OpenCastROOM et chez OpenCastROOM. Exactement. Qu'est-ce que tu peux nous en dire là-dessus? Quelles sont les choses que tu as vu, les différentes structures? Est-ce que tu as vu des lancriers pleurer sur les parterres sur les changements? Effectivement, j'ai tout vécu. J'ai eu la chance de tout vivre, et donc c'est juste un facteur chance, pense d'être au bon moment, au bon endroit. Moi, ça fait 18 ans que je fais de la qualité logicielle. J'ai commencé dans des grands groupes pour SFR, dans une SS2Z ESM, à Stereo à l'époque. On était des plateaux, des open space de testers, avec des open space de développeurs. Ce qui était assez marrant d'ailleurs à l'époque, c'était que, par exemple, SFR avait faisait de la prestation. Pour une application, il donnait le développement à Capgemini, par exemple, et donnait le test à Astéria. Et inversement, pour une autre application, il donnait le développement à Astéria et le test à Capgemini. Ça faisait une petite guéguerre, on va dire. Là, c'est la pure qualification. C'est vraiment mettre en face les testers et les développeurs pour que le produit sorte avec toute la qualité que le client souhaite. J'ai vécu ces grandes organisations avec des cycles de 3 mois, des semaines à passer sur la conception de la priorisation, la préparation des jeux donnés, etc. Avec de vrais silos. T'endors, tu as vu le projet à parler aux clients, c'est pas au testers. C'est pas. Donc vraiment, ce monde-là, je viens de ce monde-là, juste après mon école d'ingé, et jusqu'à une étape où j'ai travaillé chez Vente privée, où là, on était déjà avec de l'agilité. On avait déjà commencé à faire un peu d'automatisation de tests, plus petits, bien entendu, plus avec des ressources internes aussi. Ça changeait les collaborations entre les personnes. Et puis après, pour OpenCassoons, là, j'ai un peu vécu tout le reste. C'est-à-dire que moi, quand je suis arrivé chez OpenCassoons, il y a 9 ans, je vais fêter mes 9 ans jeudi, je crois. Mon anniversaire. J'ai été vraiment le premier qu'on embauchait. Donc j'ai monté toute la qualité logicielle chez OpenCassoons. J'ai fait presque trop de temps où j'ai commencé à recruter une équipe, etc. On a fait de la qualité-assurance. Après, on a eu le shift pour la qualité-assistance, une raison et un besoin qu'on expliquera plus tard. Et maintenant, depuis quelques années, de la Noctua. Grandement, j'ai fait toutes ces différentes étapes chez OpenCassoons, dernièrement, en tout cas. Alors, pour ceux qui nous écoutent et qui sont perdus avec certains éléments de langage comme qualité-assistance et noctua, on va essayer de faire un petit focus avec Vincent pour qu'on comprenne ce que c'est. La qualité-assistance, c'est pas juste du rebranding de la qualité-assurance. C'était une démarche qui a été mise en place notamment par Atlassion il y a quelques années qui est de rendre autonome toute l'équipe produit sur la qualité. C'est-à-dire de tendre vers quelque chose ou potentiellement, on peut arriver à du no-cuet, c'est-à-dire plus de cuet dans les équipes. Ça veut pas dire qu'il y a plus de qualité -assistance un-dessus. Et c'est pas fait pour toutes les organisations. Il y a différentes façons de faire de la qualité-assistance. Je fais toute une série d'articles où on en parle, des gens comme Netflix ou comme Atlassion, Mano-Mano, OpenCassoons, longs paix de façon différente. Mais l'objectif est le même, c'est comment les différents parties prenantes, que ce soit le PO, les devs, les ops, les cuets, vont intégrer la qualité et le prendre au plus tôt et de façon le plus efficace et de se dire que la qualité c'est de l'affaire de tous. Alors souvent, quand je parle avec certains qui disent quand il y a qualité c'est l'affaire de tous, c'est l'affaire de personne. En fait, c'est une histoire de culture. Vincent, on en reviendra peut-être là-dessus. C'est pas grave de ce que t'as mis en place. Mais c'est comme une histoire de culture. C'est-à-dire que si c'est juste une phrase, on dit comme ça, qui déresponse, s'appelisse tout le monde, bah oui, c'est sûr qu'on va droit dans le mur. Mais si les gens, on leur donne les moyens de comprendre ce que ça veut dire et ce qu'il faut mettre en place et que ça va pas non plus être une catastrophe dans leur activité au quotidien de mettre en place, quand on a des gens intelligents en face, ça se passe bien en général. Et en général, la plupart des gens sont assez smarts. Ils appartent quelques irédictiques colloies qui veulent toujours travailler comme il y a 20 ans. J'ai dit pas de bêtises Vincent, mais... Ouais, c'est ça. En tout cas, c'est pas... Justement, cette phrase-là, effectivement, je crois qu'elle puisse être perçue de façon différente, mais c'est pas de la déresponsabilisation, c'est justement de la responsabilisation de la qualité à tous les niveaux, à toutes les personnes qui participent à cette production de valeur, on va dire, à l'utilisateur. Et c'est de la responsabilisation plus que de la responsabilisation. Ce qu'il faut voir, c'est qu'aujourd'hui, quand on veut délivrer de la valeur rapidement dans des secteurs à très haute concurrence, il y a deux activités qui sont sur le chemin critique pour aller vite en production. Les ops, ils peuvent mettre beaucoup de contrôle et tout varier, mettre encore des choses à la main. Donc, la rivée du DevOps a réduit ce point de douleur-là, et la QA, où il dit, il doit tout tester, tout à chaque fois, et le mettre en place. Il n'y a pas toujours que ça, les applicatifs, qui nécessitent de le faire ça, et dire comment le mettre en place. Et en gros, cette philosophie de la qualité de l'assistance, c'est pas c'est du get-keeper, le gardien de la qualité, on devient le chambre de la qualité. On trouve que le terme "Qualité assurance" nous a mis trop de pression sur les épaules, on doit assurer la qualité, parce que non, au meilleur des cas, on la contrôle. Celui qui assure la qualité, dans la vérité, c'est le développeur, parce que c'est lui qui met en prod. Il faut savoir qu'il va mettre en prod ce qu'il a compris, parce qu'on souhaite vraiment mettre en production. Donc, il y a de ça, et donc le but c'est de passer de ce get-keeper à un QA en ébleu. On en parlera avec ces rôles de coach, d'advisor, et de se dire comment on met en place une organisation où tout le monde va mettre de la qualité dans son quotidien pour pouvoir livrer bien en une fois. Voilà, ce qu'on appelle le "first phase" par "steals", ça fait beaucoup de temps en anglais. C'est un indicateur qui dit on arrive à livrer bien du premier coup. Plus il est élevé, plus on est dans des critères proches de ce que veut mettre Accelerate, de se dire "on livre vite, mais on livre aussi très très bien avec un haut niveau de qualité, avec une grande satisfaction des utilisateurs à la fin". Ce qu'il faut savoir, c'est qu'aujourd'hui on est dans un marché où il faut livrer de la valeur peu rapidement que le concurrent, continuer à grossir mais aussi à vivre. Parce que, si on ne le fait pas, il y a un concurrent qui va le faire certainement d'une façon différente, mieux, avec un angle différent et on risque de renier nos parts de marché ou de le mettre en place. Et si notre boîte a moins d'activité, elle va réduire ses nombres de QED, des développeurs et c'est plus difficile. La vérité, c'est que c'est un context économique qui fait que, de plus en plus de structures qui sont flexible, on tend vers cette organisation-là, mais ce n'est pas fait pour tout le monde. Aujourd'hui, dans une organisation il y a 15 applications qui communiquent les uns avec les autres. C'est beaucoup plus dur que si tu as juste un back-office, un front-office, qui communique juste avec des API dessus. Ce n'est pas fait pour toutes les organisations et dans tous les contextes, mais il y a quand même des choses à apprendre et essayer de mettre en place dans chaque organisation. C'est beau ce que tu dis. C'est beau ce que tu dis. C'est bon. Une introduction à la qualité/assistance et le No QED c'est qu'on roule la marche ultime, c'est-à-dire j'ai plus de QED qui font des tests, mais c'est fait autrement. Ah c'est la culture du "you build it, you run it" qui permet, en fait, de responsabiliser les développeurs et donc, effectivement, t'as plus besoin de QED derrière, parce qu'en fait, c'était dans une marche QED et que t'es QA dans une équipe produite, t'as réussi à responsabiliser le développeur sur la qualité. Il y a un fit complet sur qu'est-ce qu'on s'attend comme qualité et il sait ce qu'il attend, il sait les QED qu'il doit remplir. La diffusion de la qualité est partagée et en fait, grâce à ça, en fait, le QA peut se détacher petit à petit et il y aura toujours du travail parce que la qualité c'est quand même immense, c'est un champ infini de choses à faire, à voir, à observer et il y aura toujours du travail pour tout le monde. Le final, c'est pas forcément de nos QED en tant que personne, c'est nos testeurs en tant que global, ça devient une activité globalement, mais pour ceux qui disent que c'est pas possible, je pense que vous êtes beaucoup utilisés Netflix au quotidien, ils n'ont pas de QA dans leur équipe. C'est un exemple pour vous dire, ils sont quand même plusieurs milliers de développeurs et ils arrivent à le faire et ils ont aussi une architecture logicielle qui le permet. Ce que je veux dire, c'est un tout. Ils sont arrivés et ils sont transformés, ils ont eu cette culture là, à une époque où personne n'utilisait leur produit. C'est aussi ça, aujourd'hui. Je crois qu'ils ont commencé leur transformation c'était 2009 ou 2012 qui utilisait Netflix, je pense qu'ils vendaient encore, ils vont encore décasser le vidéo, mais voilà, donc ils ont vu QA4 un peu, mais c'est vrai qu'ils ont commencé leur transformation en étant quelques développeurs et petits et ils ont pu continuer en consistant à avoir cette culture et la conserver, ce qui n'est pas facile quand tu grandis. On a fini pour ce premier épisode sur la Quasity Assistance, j'espère que vous avez pu comprendre ce qu'il en est, si jamais vous avez besoin de plus de compréhension, j'ai rédivé une série d'articles sur le sujet, notamment je parle de Netflix et d'Atlasia, n'hésitez pas à aller la voir sur mon blog et je vous conseille de rester avec nous, on va rentrer un peu plus dans la Quasity Assistance sur Opencast Room, de voir comment les équipes ont mis en place, les challenges qui ont dû relever lors du prochain épisode Merci d'avoir écouté cet épisode, c'est grâce à toi que la Guile continue de grandir. Si tu as aimé, n'hésite pas à partager autour de toi et à laisser un avis 5 étoiles sur ta plateforme, référend. Je te donne rendez-vous au prochain épisode plus de conseils pour booster tes compétences.