Qu’est-ce que le Quality Engineering ? Cette question en soulève d’autres comme le pourquoi, le quoi, le comment. Nous les avons couverts lors d’un échange approfondi dans de la QE Unit avec João Proença.

Nous avons décidé d’interviewer João pour clarifier la définition et la mise en œuvre du Quality Engineering au sein des entreprises. Dans cette interview, nous partageons son point de vue issu de plus de 10 ans d’expérience dans le domaine de la qualité. 

Nous nous sommes concentrés sur le partage de cas concrets pour matérialiser comment le Quality Engineering peut vivre dans les organisations. Les contenus mentionnés sont disponibles dans les références en fin d’article. La discussion peut d’ailleurs se poursuivre dans les commentaires.

Rejoignez la QE Unit pour accéder à plus de contenu exclusif et régulier de la communauté.

À propos de João Proença

João Proença est originaire de Lisbonne, au Portugal, et est Principal Quality Engineer en R&D pour OutSystems, une société qui fournit l’une des principales plateformes de développement low-code au monde.

Il a assumé divers rôles tout au long de sa carrière au cours des 14 dernières années, notamment l’assurance qualité, le développement, le support client et le marketing. Trouver des solutions innovantes à des problèmes complexes le motive le plus, il est donc toujours impatient de parler de la façon dont les professionnels surmontent les défis des tests dans le monde entier. 

En dehors de l’informatique, João est passionné par l’écriture de chansons, les films et le football. Vous pouvez le suivre sur tweeter sur tous ces sujets via @jrosaproenca .

Antoine : Peux-tu commencer par te présenter ?

Au fil des années, j’ai abordé une variété d’activités, la musique en faisant partie à un moment donné 🙂 J’ai commencé ma carrière en tant que chercheur en rendu 3D après avoir terminé l’université. C’était intéressant, je faisais du rendu pour trouver de nouvelles façons alternatives de modéliser des objets. Après un certain temps, j’ai compris que je voulais avoir plus d’impact dans le monde réel que ce que je faisais en recherche. J’ai décidé de faire autre chose.

J’ai rejoint Outsystems en devenant Quality Engineer à l’époque. À cette époque, c’était similaire à un rôle traditionnel de QA. J’étais au sein d’une équipe agile gérant à la fois les activités de tests manuels et d’automatisation. Je suis resté à cette position pendant environ 5 ans avec une expérience plus large que l’assurance qualité : j’ai effectué du développement de logiciels, de fonctionnalités à la correction de bugs. Après cette période, je ne voulais pas revenir uniquement cloisonné à l’assurance qualité.

J’ai investi plus de temps dans le développement, mais j’ai également travaillé au sein de l’équipe de support client. Ce fut une expérience enrichissante ; devoir décrocher des téléphones, répondre à des clients, heureux ou même parfois en colère. Je devais décider quoi escalader au sein de l’entreprise pour résoudre des problèmes particuliers. Compte tenu de la taille de l’entreprise, il s’agissait d’une position exigeante en raison de la complexité et de la variété du support de première ligne.

Antoine : Où as-tu évolué après cette expérience de support enrichissante ?

J’ai ensuite été invité à rejoindre l’équipe d’opérations Cloud nouvellement créée lorsque Outsystems a lancé son offre Cloud associée. J’ai été nommé pour diriger l’équipe du côté des opérations. Au même moment, je travaillais sur mon projet parallèle d’album de musique, en gérant de nombreuses activités marketing. J’ai commencé à m’intéresser davantage à ce domaine et j’ai eu une opportunité de marketing produit dans une autre entreprise. J’y ai travaillé pendant un certain temps, en tant qu’ingénieur produisant du contenu pour cette société éditrice de logiciels. Après un certain temps, j’ai réalisé que ma vocation était d’être un pur ingénieur.

J’étais alors de retour chez Outsystems avec une proposition de rejoindre le domaine Qualité. J’ai hésité car je ne voulais plus être uniquement cantonné à la qualité. Ils m’ont dit « Nous avons maintenant une vision complètement différente de la Qualité ». Ils n’avaient pas encore inventé de nom pour le concept, mais ils en avaient vraiment une perspective différente. J’ai accepté et suis Quality Engineer depuis 2017, avec de nombreuses expériences différentes depuis lors.

Antoine : Un parcours intéressant avec des expériences diverses, de l’ingénierie, du support, des opérations, de la musique et du marketing. Pour partager avec l’audience, peux-tu en dire un peu plus sur l’entreprise et ses enjeux ?

Outsystems fournit une plate-forme logicielle low-code pour le développement rapide de différents produits, des expériences Web aux expériences mobiles. Au fil des années, elle a trouvé son marché et accéléré sa croissance dans le monde entier à partir du Portugal. C’est l’une des principales licornes dans le domaine de la technologie, avec des défis d’hypercroissance et de mise à l’échelle.

Je me souviens du jour où l’entreprise comptait moins de 100 employés. Actuellement, nous sommes entre 1500 et 2000. J’ai vu différentes étapes et niveaux de complexités selon la taille de l’équipe. Nous sommes actuellement en expansion; il est difficile de savoir combien nous sommes précisément à un moment donné.

Antoine : Le Quality Engineering n’est pas communément défini. J’ai voulu approfondir ce thème avec ton expérience professionnelle et ce que tu partages lors de conférences. Avant de commencer, peux-tu partager tes principales priorités en tant que Principal Quality Engineer?

Un défi majeur découle directement de la croissance accélérée de l’entreprise. Nous devons permettre aux pratiques de Qualité de se maintenir malgré l’expansion de l’organisation. Cela signifie que de nombreuses nouvelles équipes doivent s’aligner sur notre culture, nos pratiques et nos standards communs de qualité. Nous voulons éviter les silos de qualité qui manquent de partage en transverse dans l’organisation. Une priorité clé est d’avoir des équipes partageant une compréhension commune de la façon dont elles doivent aborder la qualité.

Personnellement, je travaille avec une équipe spécifique tout en évoluant vers un rôle plus transversal, guidant plusieurs équipes. Ces équipes peuvent ou non avoir des Quality Engineers intégrés. J’incite les équipes à communiquer ensemble, à sensibiliser les différentes personnes aux différentes pratiques et opportunités en qualité, ou encore à aborder des sujets plus larges que ceux d’une seule équipe. C’est un rôle plus stratégique qui m’oblige à être plus au fait des tendances de l’industrie pour m’assurer que la qualité est intégrée à ces différentes équipes.

Antoine : Les dimensions que tu partages démontrent un bon niveau de maturité qualité, également lié aux objectifs d’entreprise de faire évoluer et de maintenir la qualité du produit. En résumé, ton rôle est de concrétiser la Qualité à un niveau local, au sein de chaque équipe, tout en veillant à ce qu’elle contribue à une valeur globale à l’échelle de l’entreprise ?

Oui, exactement. Un aspect concret est de pousser les Quality Engineers à travailler plus étroitement avec des équipes spécifiques. Beaucoup d’améliorations sont à aller chercher par les aspects humains plutôt que par les aspects techniques. Je coache beaucoup d’autres ingénieurs dans leur approche de la qualité, leurs interactions avec les autres équipes et leurs efforts pour résoudre des problématiques.

Les Quality Engineers sont de véritables facilitateurs et enablers. Ils ne sont pas les seuls à faire des activités de qualité ; ce n’est pas le but pour nous. Savoir comment activer les équipes sur la gestion des risques ou la stratégie de test est, par exemple, plus précieux. Parfois, la façon dont vous facilitez un atelier spécifique change la donne, c’est le type d’impact que nous cherchons à atteindre.  

Antoine : Oublions maintenant pour un temps le contexte spécifique d’Outsystems. Comment définirais-tu le Quality Engineering en une phrase ? Qu’est-ce que le Quality Engineering de ton point de vue ?

Je vais essayer de donner la meilleure définition possible du Quality Engineering, forcément influencée par mon expérience. Je viens d’une « l’école des tests » fondée sur: la “whole team approach to quality”, les “modern testing principles” que Brent Jensen et Alan Page ont posé. Lorsque je suis devenu Quality Engineer en 2017 chez Outsystems, je l’ai fait en travaillant avec le nouveau responsable de la qualité, João Neto, qui venait de Microsoft, d’où sont nés ces principes. Il a travaillé pour apporter cette école de pensée à notre organisation. 

Je pourrais m’appuyer sur l’un de ces contenus, mais je peux d’abord partager une histoire. En 2018, je suis allé aux Agile Testing Days en Allemagne. Les gens parlaient de sujets similaires, et j’ai découvert la keynote d’Anne-Marie Charrett, originaire d’ Australie. Elle a partagé que le Quality Engineering, venant d’autres domaines d’ingénierie, entrait maintenant dans le monde du logiciel. Le Quality Engineering arrive pour moi en ce moment, liée à d’autres tendances comme le DevOps et l’Agilité.

« Le Quality Engineering englobe une perspective holistique. »

João Proença

L’assurance qualité a tendance à se concentrer davantage sur la validation et la vérification, avant et après la mise en œuvre ; parfois très localisés dans le cycle de vie du logiciel. Le Quality Engineering apporte une vision plus holistique de la qualité à construire en premier lieu par différentes équipes sur toutes les étapes. Un visuel utile est celui de Dan Ashby: il y a le schéma infini de DevOps où les tests et la qualité se produisent à chaque étape. Cette vision de la qualité s’appuie également sur les pratiques de qualité et de test existantes.

Antoine : Quelles sont selon toi les pratiques clés du Quality Engineering ? Quelles sont celles les plus différenciantes et novatrices ?

Je ne vois pas de recette unique. Je peux identifier plusieurs actions que j’ai faites en tant que Quality Engineer, pas si courantes et relevant de mes responsabilités. Tout d’abord, considérer la qualité dès la phase de conception. Les risques sont pour moi très importants. Être axé sur les risques, c’est considérer sérieusement les risques comme la source de beaucoup de choses que vous faites, et en particulier les risques de qualité. Notez que souvent les équipes parlent de risques en faisant référence aux « risques projet » qui sont différents à mon avis des « risques qualité ». Les risques du projet mettent en danger le succès d’un projet particulier.

Dans les risques qualité, nous réfléchissons à la façon dont le produit pourrait mal tourner, ne pas satisfaire les attentes de nos utilisateurs. J’ai vu beaucoup de discussions sur les risques sans un cadre clair pour les aborder de manière approfondie ou systématique. Par conséquent, j’ai appris l’évaluation des risques grâce à la prise de risques, une pratique fondamentale pour discuter de la qualité dès le départ. J’ai même discuté de l’intérêt de le faire à la fois tôt et en continu avec leurs créateurs, Beren Van Daele et Marcel Gehlen.

« Le Quality Engineering consiste à trouver le juste milieu entre la création de valeur tout en gardant la capacité de réagir. »

João Proença

Pour l’évaluation des risques, il est essentiel de la faire au bon moment dans un projet. Au tout début, vous ne serez pas clair sur ce que vous essayez de créer et de fournir aux utilisateurs, de sorte que les risques que vous encourez ne sont pas si complets. Plus tard, lorsque vous êtes déjà en train de développer, vous pouvez être trop avancé dans la mise en œuvre pour actionner des mesures de réduction des risques dont vous avez besoin pour votre équipe. Vous avez une bien meilleure compréhension des risques mais moins de marge de manœuvre pour agir sur eux. Le sweet spot est juste au milieu lorsque vous commencez à matérialiser la valeur du produit tout en n’ayant pas trop d’engagement. Atteindre cet état nécessite un modèle de collaboration en amont, au plus tôt. Atténuer les risques implique bien sûr de nombreux tests, mais cela peut également impliquer d’autres pratiques telles que les tests dans des techniques de production telles que les shadow-deployment, ou en observabilité. Ces pratiques vont au-delà des tests et permettent de mesurer les risques et de s’adapter en amont. 

Une autre pratique que j’ai trouvée très percutante est d’agir au niveau de l’architecture. Pour certains problèmes, les tests étaient inutiles ; nous avons collaboré avec des architectes pour résoudre des problèmes structurels. Cela vous permet de réaffirmer le pourquoi, le quoi et le comment, ce qui vous rend plus explicite sur les risques et les priorités les plus importants. Je parle déjà de nombreuses pratiques qui sont vraiment différentes de ce que ferait une équipe de test ou d’assurance qualité traditionnelle.

Antoine : Le Quality Engineering prend en compte la qualité et agit dans son ensemble, oú les équipes d’assurance qualité jouent un rôle fondamental. Comment manager le Quality Engineering ? Recommandes-tu des mesures spécifiques à utiliser ?

En définitive, mon travail est de permettre aux équipes de penser une qualité intégrée et transversale. En rétrospective, ce que nous avons essayé de faire l’année dernière  était de faire comprendre aux équipes deux choses: ce que signifie la qualité pour eux et pour leur produit. Nous avons formalisé certaines mesures qu’ils peuvent utiliser et adapter pour évaluer leur performance actuelle et cible dans leur propre contexte. 

Nous avons nommé notre modèle le “Radar de qualité”, il fournit un ensemble de processus, d’habitudes et de principes qui peuvent être évalués. Le Radar s’est fortement inspiré du Quality Culture Transition Guide d’Alan Page. Le modèle aborde différents domaines comme la culture qualité, les typologies de tests ou encore la maintenance. Par exemple, nous avons des équipes qui travaillent activement sur la dette technologique et promeuvent son traitement de manière qualifiée.

Sa mise en œuvre repose sur la définition et l’animation du radar. Le but n’est pas d’évaluer les équipes mais de leur permettre de faire leur propre bilan et plan d’action. Une équipe peut comprendre « Hey, nous ne sommes vraiment pas au niveau sur l’Observabilité, que pouvons-nous faire ? » Le radar leur donne les premiers pas qu’ils peuvent faire par niveau de maturité. Nous améliorons continuellement le modèle, certains domaines étant expérimentaux.

Antoine : Ce partage nous amène à la valeur du Quality Engineering. La perspective du produit et de l’équipe les aide à travailler pour combler en permanence l’écart de valeur. Y a-t-il des mesures précieuses spécifiques à prendre en compte à cet effet ?

Il y a deux idées principales concernant la mesure et les métriques. Les métriques qui ne sont pas contextualisées par rapport à votre organisation, produit ou équipes ne fonctionnent généralement pas ; il n’y a pas de mesures universelles à utiliser. Cela oriente la discussion sur les métriques les plus importantes pour les équipes dans leur contexte. Une chose que nous avons essayée sont les “Objectifs de qualité des produits” pour que les équipes définissent leurs priorités de qualité pour leurs applications.

Les objectifs de qualité des produits ont été en partie inspirés par le concept des Northstars. Les Northstars des produits sont la mesure clé du succès d’une équipe produit. Pour Facebook, c’était le nombre de likes ou de partages si je me souviens bien. Cela guide vraiment la prise de décision. En déterminant les mesures clés qui comptent pour vous, vous pouvez ensuite aligner des actions pour combler l’écart entre vos niveaux actuels et cibles. C’est utile surtout lorsque les assets technologiques d’une équipe changent au fil du temps ; les acteurs sont plus liés à la valeur à livrer qu’à un produit déjà construit qui pourrait venir à complètement changer. 

Nous avons apporté cette idée des Northstars au domaine de la qualité et je suis convaincu que les équipes doivent trouver les métriques par elles-mêmes. Vous pouvez leur fournir le moyen d’y parvenir, mais pas les mesures en elles-mêmes. J’ai également découvert tout un ensemble de perspectives de métriques avec nos Quality Engineers, les communautés et même avec Lisa Crispin qui a travaillé avec nous chez Outsystems. J’ai remarqué que les gens s’accordent à dire que les métriques à plus forte valeur ne peuvent pas être universelles. Si vous voulez vraiment des métriques “standard de l’industrie” pouvant s’appliquer généralement, alors il vaut mieux parier sur celles de DORA du livre Accelerate.

Elles sont aujourd’hui considérées comme des métriques DevOps. De mon point de vue, ces mesures sont bénéfiques pour l’ensemble de l’industrie. Je recommande à quiconque d’effectuer l’exercice de mesure dans son modèle de maturité.

Antoine : Les priorités du Quality Engineering sont donc contextuelles aux priorités de l’entreprise, du client à la maturité et à l’organisation. Existe-t-il des modèles organisationnels spécifiques au Quality Engineering ? Quel impact cela a-t-il sur ce que doit concrètement réaliser un Quality Engineer ?

Les activités et même les responsabilités des Quality Engineers dépendent de la taille, du contexte et de l’histoire de l’organisation. Outsystems a plus de 20 ans et a connu différents niveaux d’échelle et de défis au cours de son existence. Nous avons vu que leur définition et la manière dont ils abordent la qualité évoluent, reflétant ses changements de priorité et de maturité de l’organisation.

Antoine : Je pense que c’est plus une question d’état d’esprit et d’actions que l’on autorise, tolère et priorise. Un CTO peut-il être le seul Quality Engineer d’une start-up ?

Exactement! La nature de l’entreprise, du produit et de l’organisation sont des éléments de contexte essentiels à considérer. Je me souviens avoir parlé avec une de mes amies, Melissa Eaden, qui travaillait chez Unity où Alan Page travaille maintenant. D’un point de vue organisationnel, ils poussaient également les équipes à développer leurs mesures à plus forte valeur. C’est un excellent exemple de la façon dont les équipes doivent être responsables de leurs mesures de qualité et de leurs plans d’action.

Les mesures peuvent être dangereuses mais en même temps stimulantes. Bien fait, elles permettent à l’équipe de prendre le contrôle de leurs plans d’amélioration, de définir et d’apprendre des expériences. Cet alignement collaboratif et partagé est vraiment bénéfique pour des organisations agissant sur un objectif plus large.

Antoine : Cela me fait penser à quel moment les entreprises devraient commencer à avoir des postes de Quality Engineer. De notre partage on comprend que le Quality Engineering doit être présent à chaque étape de la maturité de l’entreprise. Le besoin de postes dédiés apparaît-il à partir d’une taille spécifique ou de types de sujets à adresser ? Quand cela devient-il une exigence et pas seulement une option ? (Une question subsidiaire est de savoir ce qui arrivera aux grandes entreprises qui n’abordent pas sérieusement le Quality Engineering)

Le Quality Engineering fait sens dans la plupart des scénarios. Il ne s’agit pas seulement de la taille de l’entreprise. Si vous souhaitez lancer une toute nouvelle start-up demain, vous ne commencez probablement pas avec une pratique dédiée à l’assurance qualité, alors penser au Quality Engineering peut être un bon pari. Ce qui est important, c’est de mettre en œuvre les idées et les principes qui sous-tendent ces domaines.

Je me retrouve parfois à penser que l’assurance qualité avait plus de sens autrefois. Il était très difficile d’agir une fois le logiciel déployé en production pour diverses raisons. Il y avait des limitations pratiques comme la livraison de logiciels sur des CD physiques qui, une fois expédiés, la publication de mises à jour était un réel problème. L’adaptation continue du logiciel n’a pas été si simple, renforçant le besoin d’une gestion de la qualité et des risques très préventive.

Aujourd’hui, la dynamique est très différente. DevOps est un exemple de changement radical dans la façon dont nous créons, livrons et exploitons nos logiciels. Le Quality Engineering a beaucoup de sens dans les logiciels d’ingénierie actuels et en relation avec nos utilisateurs.

Antoine : Quelles étapes recommandes-tu pour commencer à explorer le Quality Engineering ?

Je recommanderais d’examiner en profondeur l’approche du “whole team approach to quality” et les principes de test modernes. Certains doutent de leur mise en œuvre pratique. Je peux vous assurer que bien fait, ils fonctionnent. Dans de nombreux endroits dans le monde, les pratiques sont mises en œuvre sans y faire directement référence.

De nombreuses pratiques émergentes dans nos domaines sont parfois commentées par des « Ça a l’air bien en théorie, mais en pratique, je ne l’ai jamais vu fonctionner ». J’ai été confronté à un exemple pratique et récent avec les tests de contrats (i.e. contract testing). J’ai participé à des ateliers, j’en ai appris davantage, j’ai même assisté à des ateliers lors de conférences pour le mettre en œuvre. J’ai trouvé beaucoup de détracteurs qui ne l’ont pas mis en œuvre. J’ai finalement parlé à un de mes amis, Rob Meaney, qui m’a donné les premiers exemples d’endroits où cela a en fait réussi.

La capacité à traduire le concept en pratique est crucial, ce n’est pas donné à toutes les équipes. Il faut un niveau de compréhension, d’excellence et d’engagement pour en faire une priorité. C’est comme le TDD. C’est une pratique à forte valeur, mais difficile de concrétiser correctement dans une organisation. En résumé, si les gens doutent de ces pratiques comme seules théories, je les contredirais.

Le Quality Engineering a développé beaucoup de ces principes avec une perspective plus transversale et holistique, nous offrant plus d’options. 

Antoine : En terminant sur une note personnelle, as-tu des contenus inspirants spécifiques, comme des citations, des livres, même en dehors de la Qualité ?

Les tests modernes ou Modern Testing sont très bénéfiques pour moi. Vous pouvez trouver le podcast AB Testing avec des centaines d’épisodes sur leur site et rejoindre leur slack pour s’engager avec la communauté.

J’ai évoqué la keynote d’Anne-Marie Charrett sur le Quality Engineering, « Is your quality on the road to nowhere? ». Elle partage également régulièrement sur son blog.

En termes de livres, je recommande fortement de lire Accelerate et Leading Quality, définissant les connaissances et les perspectives essentielles. Je vais aussi commencer à lire le projet Unicorn qui fait suite au projet Phoenix, deux autres grands titres.

Antoine : Merci beaucoup João pour cet entretien Quality Engineering. Je te souhaite une mise en place impactante du Quality Engineering chez Outsystems, et des talks différenciants aux conférences, comme celles sur les biais cognitifs. Vous pouvez suivre João sur @jrosaproenca.

Références 

Brent Jensen & Alan Page, Principes de test modernes, AB Testing Podcast  https://moderntesting.org/  

Dan Ashby, Continuous Testing in DevOps. https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/ 

Brent Jensen & Alan Page, Le guide de transition de la culture de la qualité https://testingpodcast.com/ab-testing-episode-93-the-quality-culture-transition-guide/ 

Alan Page, Le guide de transition de la culture qualité https://docs.google.com/spreadsheets/d/1kan20hYsdbvk7HW4si-X6Ve1fLtCeTI2H_PjiniKsxY/edit#gid=1897633328 

Lisa Crispin, L’approche de l’équipe entière en pratique https://lisacrispin.com/2011/04/26/the-whole-team-approach-in-practice/ 

Janet Grégory, Tests holistiques https://janetgregory.ca/testing-from-a-holistic-point-of-view/ 

Anne-Marie Charrett, Keynote “Anne-Marie Charrett : Is your quality on the road to nowhere?” https://www.youtube.com/watch?v=46QFPrs5dT0. Agile Testing Days

Anne-Marie Charrett, blog personnel sur https://www.annemariecharrett.com/ 

Beren Van Daele et Marcel Gehlen, Riskstorming

Nicole Forsgren ; Jez Humble ; Gene Kim (2018), Accélération : La science des logiciels Lean et DevOps : Construire et faire évoluer des organisations technologiques hautement performantes https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339

John Ronald Cummings, Owais Peer (2019), Qualité leader : comment les grands leaders fournissent des logiciels de haute qualité et accélèrent la croissance https://www.amazon.com/Leading-Quality-Leaders-Software-Accelerate/dp/1916185800 

Google, le rapport Accélération https://cloud.google.com/devops/state-of-devops

Every Product Needs a North Star Metric https://amplitude.com/blog/product-north-star-metric