La Qualité. Sans Tester.

La qualité ne se résume pas qu’aux tests malgré le stéréotype. D’ailleurs, est-ce vraiment à la QA de faire les tests?

Nous nous sommes attelés à travailler cette thématique lors de notre dernière table-ronde “Faire de la Qualité. Sans tests.”. Cet article résume les principaux points que nous avons partagés.

La qualité logicielle se retrouve encore trop souvent uniquement associée au test. De véritables défis de perception de valeur, de communication et de collaboration sont au cœur de cette problématique.

Je remercie les participants pour leur présence et contribution :

Arnaud Dutrillaux, Senior Quality Engineer chez La Javaness
Benjamin Butel, Coach Agile chez Klaxoon
Christophe Moustier, Expert Qualité et Test chez Inetum, Auteur
Farah Chabchoub, Head of QA chez Livestorm & Speaker
Iman Benlekehal, Spécialiste en Assurance Qualité Logicielle
Olivier Dennemont, Head of QA chez Manomano

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

La qualité commence (grandit, et termine) par la culture

“Les tests? Il faut voir avec la QA”, une phrase que l’on entend régulièrement, sans forcément avoir de contestation. Ce mythe est largement répandu et accepté dans l’industrie logicielle. Des codes, croyances et pratiques partagées qui sont à la base d’une culture. Les acteurs agissent en accord avec leur culture, pour définir, construire et maintenir les logiciels.

Faire de la qualité nécessite donc une évolution de la culture de l’organisation.

À l’instar de certaines tribus ayant développé des codes complètement différents, certaines organisations valorisent différemment la qualité. Spotify est un bon exemple qui s’est traduit par une approche produit réussie, à l’échelle et soutenable. Benjamin faisait d’ailleurs un parallèle du niveau de qualité avec nos choix de produits réels : bas, milieu ou haut de gamme.

« Il faut discerner quelle qualité de produit on construit jusqu’à la direction; veut-on du low-cost jetable, du bon marché pour 2 ans, ou mieux?”
Benjamin Butel

Pour d’autres cultures, des startups au CAC40, la qualité est souvent un modèle low-cost; on développe de nouveau tous les 2 ans, en gardant et accumulant la dette technique jusqu’au prochain mur. Ces organisations associent souvent la QA avec des tests en bout de chaîne une fois les développements réalisés, sans contact métier et encore moins client.

Cette segmentation de la QA est l’une des problématiques principales pour une qualité plus transverse. Olivier nous partageait son expérience personnelle où le contact direct avec les utilisateurs du produit, et en particulier leurs retours, lui ont fait prendre conscience de la qualité.

“La proximité avec les utilisateurs m’a très tôt sensibilisé à la qualité du produit.”
Olivier Dennemont

Cette proximité nous rappelle bien que le logiciel n’est pas que du code; c’est une solution qui doit être utile pour quelqu’un. Cette empathie est nécessaire, on peut facilement perdre de vue le client immergé dans nos questions technologiques.

Pour en revenir à la culture, les codes et mots établis sont puissants et révélateurs. L’équipe QA est-elle matérialisée par un silo organisationnel dans l’organigramme ? Est-ce que le responsable de l’équipe a un titre de “Lead Test” ? Les membres de l’équipe parlent-ils de tests, de qualité, ou de valeur métier ?

Autant de variables qui influent sur la perception de la qualité de l’organisation. Adresser l’image de la qualité est donc structurant, en commençant en premier par nous-même; Parlons-nous métier ? Allons-nous au contact du client ? Travaillons-nous à décliner les priorités stratégiques sur des axes de qualité ?

Le travail débute donc par nous-même, avant d’élargir notre impact sur le reste de l’organisation. Les changements culturels prennent du temps, et pour cette raison doivent être initiés tôt.

Un premier pas est de construire une vision partagée par la collaboration.

Co-construire un objectif commun d’entreprise, supporté par la qualité

La collaboration de différents acteurs à l’échelle d’une entreprise sera supportée par sa culture et ses objectifs communs. Sans cette étoile, les forces locales reprendront le dessus au détriment de la performance globale du système.

Faire de la qualité doit donc être un objectif commun fédérateur; une piste, ce n’est pas la qualité logicielle en tant que telle. Prenons du recul avant de parler de Shift-left, Shift-right, DevOps, microservices ou d’Holistic Testing.

L’application des principes “First things First” et “Start with Why” est plus que pertinente ici. Iman partageait le terme de “Shift-up and Spread” pour démarrer notre réflexion, soutenant un centrage sur l’entreprise et ses clients avant d’élargir notre prisme.

“Avant de parler de Shift-left ou de Shift-right, la Qualité doit identifier la valeur en Shift-up.”
Iman Benlekehal

Nous en revenons au “Pourquoi” initial de l’organisation au travers de sa mission, vision et valeurs. Cette motivation d’existence doit se traduire par objectifs internes et externes, en particulier pour les clients. La déclinaison des impératifs de qualité doit dériver de cette raison d’être, soutenue à plusieurs niveaux.

Premièrement, notre démarche doit embarquer les diverses parties prenantes dans des ateliers collaboratifs, des sponsors aux opérationnels. Iman nous partageait l’objectif clef d’aligner les priorités de la qualité, au-delà des perceptions individuelles initiales. Farah a également partagé ses pratiques dans cet interview : La qualité, des opérations au comité de direction.

Secondement, la proposition de valeur de la qualité doit rapprocher au maximum la vision métier de celle de l’IT. L’essor de la digitalisation des entreprises est une opportunité à saisir dans l’articulation de valeur de la qualité. On peut y retrouver des éléments d’excellence de l’expérience client, d’itérations de développement business ou de fiabilité de notre backbone d’entreprise.

Des modèles ont émergé des grands acteurs ayant dû adresser des problématiques similaires, qui plus est, à l’échelle. Google a par exemple fait évoluer son concept de Site Reliability Engineering (SRE) vers du Customer Reliability Engineering (CRE). Ce virage intéressant montre la transversalisation des pratiques et la force des mots choisis.

Notre apport est d’articuler une proposition de valeur de la qualité en identifiant des choix pertinents dans notre contexte. Nous avons un devoir de conseil fort pour faire émerger les problématiques invisibles du métier, et les trade-offs qu’elles impliquent. Arnaud partageait la nécessité d’une qualité intégrée, en particulier dans des environnements dynamiques.

L’accélération des cycles de livraisons nécessite une qualité transverse et inclusive, il n’y a pas d’autres options.”
Arnaud Dutrillaux

Dernièrement, la qualité que nous voulons co-construire doit être renforcée par des mécanismes de renforts, ou feedback loops. C’est ici que l’inclusion de sponsors et influenceurs se révèle plus que pertinente pour des actions de communication, d’arbitrage et de défense de la qualité, en particulier quand la pression monte. Christophe mentionnait l’importance des doubles boucles d’apprentissages que nous détaillons plus loin.

Les sponsors sont également nécessaires pour faire évoluer l’organisation, un élément structurel d’amélioration de la qualité.

Évoluer de l’assurance qualité vers l’assistance qualité

Un organigramme seul aura peu d’impact sur la dynamique d’une organisation et ses activités. Les fameuses réorganisations idéalisées se révélant consommatrices de temps et sans aucune amélioration en sont un exemple. Les individus, leurs intéractions et objectifs sont au cœur du système organisationnel.

Revenons-en donc au positionnement de la qualité. On retrouve souvent une équipe de QA en silo devant être sollicitée tant bien que mal dans différents projets et assurer cette fameuse qualité. Ce mode d’organisation aura tendance à consulter la QA une fois qu’un besoin de BDD, de test ou autre se fait ressentir. C’est bien trop tard pour faire de la qualité, et encore moins délivrer la valeur d’une qualité en amont.

“Réaliser des activités de test renforce le sentiment d’ownership de la qualité”
Olivier Dennemont

Il ne nous reste donc plus qu’à faire un modèle à la Spotify, incluant des profils de QA en horizontal, sur de jolis slides d’agilité à l’échelle pour nos sponsors. Ces modèles doivent être adaptés au système dans sa globalité : la culture de l’entreprise, l’architecture organisationnelle et du produit. En complément, l’horizontalisation de la fonction renforce un besoin d’animation en verticale d’une véritable pratique, si l’on veut garder un minimum de cohérence.

Malheureusement, même si ces modèles influencent la dynamique de l’organisation, ils ne touchent pas au cœur du problème: faire de la qualité nécessite une inclusion structurelle dans les différents processus. On peut d’ailleurs identifier le concept des capabilities à cet effet.

Faire de la qualité implique de responsabiliser d’autres acteurs que la QA sur la qualité, pas juste sur des slides. Nous devons agir dans la réalité en changeant les interactions, les positionnements et les types d’activités réalisées.

“Chez Manomano, les équipes de QA ne font plus les tests pour les autres; nous sommes une équipe de Quality Assistance.”
Olivier Dennemont

Intégrer la qualité semble une évidence. Néanmoins, combien de ces réorganisations d’agilité à l’échelle incluent un plan de changement culturel, une vision partagée et une redistribution des rôles pour une qualité intégrée ? Pas la majorité au vu de l’écosystème continuant à associer qualité aux tests. Des modèles adaptatifs émergent tels que le X-teams.

Une conséquence concrète à adresser est l’évolution du rôle des product et engineering managers devant prendre en considération une qualité plus globale; c’est un bon sujet d’évolution organisationnelle. Certains modèles prônent la disparition des managers, ce n’est pas forcément le sujet s’ils sont remplacés par des coachs en craftsmanship ou le dernier outil de feedback collaboratif à la mode.

Ce concept de Quality Assistance matérialise plus clairement les responsabilités attendues de chaque équipe. Ce n’est pas le seul concept poussant à plus de responsabilisation d’équipes transverses, tout en leur fournissant des outils: on peut mentionner l’engineering productivity ou la developer platform.

D’ailleurs, l’acronyme QA possède une autre variante disponible dans les références, celle de “Question Asker”.

Permettre la priorisation de la qualité au coeur des processus

Cette section débutant par le mot “prioriser”, on peut se demander le lien avec notre “Question Asker”. Faire de la qualité en tant de QA passera de plus en plus par supporter les équipes produits responsabilisées et actrices en première ligne. Des questions pertinentes et ouvertes supporteront les équipes dans leur inclusion de la qualité.

Nous estimons souvent à tort notre niveau de compréhension d’un sujet, le questionnement en toute humilité est déjà une pratique de qualité. Si nous voulons en complément avoir de l’impact sans être sous les feux de la rampe, poser des questions à valeur ajoutée montreront l’intérêt d’intéragir avec les équipes de qualité.

Une qualité intégrée doit également être réalisable. L’accélération des livraisons, de la complexité des produits et des organisations nécessitent un modèle scalable d’inclusion de la qualité. Ajouter des profils de QA en fin de cyle ne scale pas la qualité, en plus d’être inefficace. La priorisation doit donc être réalisée par les acteurs du produit, aidés par les équipes qualité dans leur démarche, priorisation et implémentation.

“Nous sommes là pour aider les équipes à tester en amont, sur leur manière de travailler, pas sur le produit fini.”
Olivier Dennemont

Les ressources des entreprises sont limitées face aux enjeux et objectifs qu’elles souhaitent réaliser, c’est la réalité. La priorisation est clef et se retrouve dans les concepts de Work In Progress du LEAN. La valeur de passer initialement par un “Shift-up & Spread” prend ici toute son importance.

Pour certaines équipes, le Shift-left focalisé sur des techniques de BDD peut être le bon choix dans leur contexte. À l’inverse, le CRE et la gestion du support le seront pour une autre équipe. Le contexte est fondamental dans l’exercice continu de priorisation, les derniers modèles et acronymes à la mode sont à voir dans un second temps; ou à garder pour la pause café.

Une priorisation collaborative se matérialisera par des actions à entreprendre, souvent dans le cadre de sprints. Le sujet de l’affectation des tâches peut démarrer, sans rester la chasse gardée de la QA.

Composer dans les itérations en mesurant le progrès

Les étapes précédentes ont consisté à sécuriser le “right product”, laissant le défi équivalent de délivrer le “product right”. C’est dans les itérations que nous allons éprouver notre modèle et nos hypothèses, à la recherche de création de valeur par la qualité.

Nos itérations doivent garder le cap sur l’objectif initial commun de création de valeur pour l’entreprise. Maintenir la direction est une réelle difficulté durant les cycles d’exécution où l’on peut vite perdre du recul. La mesure est importante pour vérifier l’adéquation de nos actions, mais quelles métriques utiliser?

Les indicateurs sont pertinents quand ils sont contextualisés, comme l’organisation et ses priorités. Pour la qualité, nous avons retenu l’utilisation des doubles boucles d’apprentissages : celle de la création de valeur (“right product”), et celle de l’amélioration du système produisant cette valeur (“product right”).

Le choix, interprétation et communication des indicateurs présentent de réelles complexités d’implémentation. Nous pouvons subir nos biais cognitifs, manquer de pertinence métier et difficilement démontrer une corrélation de nos actions. Les sujets d’Observability, de Value-Stream et d’Analytics sont à investir tout au long de la démarche.

Pragmatiquement, notre recommandation est de s’axer en priorité sur la mesure de la valeur métier communément recherchée.

Une autre recommandation est de passer plus de temps à effectivement tenter de créer de la valeur que de tenter de la mesurer (tester ?). Iman l’a très bien imagée sur l’exemple des prises de sang : en faire plus ne nous garantira pas une bonne santé.

“Faire plus de prises de sang (i.e. test), ne vous garantira pas une bonne santé (i.e. qualité).”
Iman Benlekehal

La réalité n’est pas faite que de succès, et même si nous aimerions toujours partager des exemples de succès en early-wins, il faut parfois savoir reconnaître que l’on s’est pris un mur. On retrouve cette notion dans le Fail-fast, intéressant par la pression mise à valider les hypothèses structurantes avant d’aller plus loin, combinant mesure de la valeur et réduction du risque.

Les murs font réagir les entreprises, mais notre objectif est d’en éviter un maximum et en diminuer leur taille. La communication est donc clé pour convaincre, le plus en amont possible.

Communiquer, communiquer et communiquer

Le terme DevOps est tellement répandu que nous en oublions même l’effort colossal de communication qui a été réalisé. Notre qualité deviendra une partie intégrante de notre organisation, de sa culture et de ses processus avec une communication systématique et holistique. Nous devons normalement prévoir 10 fois plus que ce que l’on a imaginé.

Néanmoins, quantité ne rime pas avec qualité, et contre-intuitivement, communiquer sur la qualité ne concerne pas que la qualité.

Une communication au service de la transversalisation de la qualité doit être omniprésente, sans forcément qu’elle y soit directement associée. Les indicateurs de création de valeur pour l’entreprise en sont un bon exemple, leur seule présence est déjà une réussite d’une qualité plus présente. Leur utilisation, rappel constant et inclusion dans les mécanismes de feedback loop du système soutiendront leur valorisation.

L’important est de sécuriser la fréquence, la couverture et inclusion des diverses parties prenantes de la valeur et de la qualité dans nos actions. Nous devons savoir parler à une direction et l’heure d’après, avec une équipe de développement. Une qualité transverse sera supportée par une communication transverse.

Durant les cycles de développement, notre priorité est de faire émerger les critères de qualité, par nos communautés, intéractions et rôle de Question Asker. Arnaud partageait son expérience où l’identification des exigences a permis une prise de conscience. La présence de divers sujets de qualité est le premier pas pour qu’ils soient considérés. Le reste du travail réside dans la culture et la capacité à accompagner l’atteinte de résultats.

Les démarches à plus fort impact sur l’organisation sont d’ailleurs par nature transverse. Prenons l’exemple de notre SRE transformé en CRE, il combine expérience utilisateur, engineering et opérations. L’ajout d’error-budget viendra balancer le besoin d’accélération et de stabilité de l’expérience, un autre élément de qualité inclusive.

En réalité, une qualité intégrée devient naturelle et transparente, c’est probablement un côté frustrant et décevant si nous cherchions la gloire au lieu de la qualité.

La Qualité a besoin de tests, loin de s’y restreindre

Faire de la qualité sans tests est donc possible, en gardant à l’esprit qu’ils sont nécessaires; Tester n’est pas exclusif à la qualité ni au cœur du sujet. Nous avons en réalité de vrais défis d’évolution des cultures et des organisations dans l’écosystème.

“Faire de la qualité est premièrement une conduite du changement organisationnel.”
Antoine Craske

Olivier et Arnaud nous ont partagé leurs modèles d’une QA comme véritable levier de qualité pour le reste de l’organisation, ne s’occupant pas directement des tests. Les organisations plus transverses sont donc plus adaptées, si nous adressons collaborativement les sujets de culture, d’alignement, et autres mécanismes partagés.

Les changements culturels à l’échelle sont de temps long; des générations entières sont souvent nécessaires pour vérifier des évolutions structurelles. Espérons que nos efforts nous permettront d’accélérer cette transformation de la qualité et capacité d’innovation de nos entreprises, pour celles qui survivront.

Encore une fois, la perspective que nous prenons fait toute la différence. À notre échelle, nous devons transformer notre organisation pour une qualité intégrée; à une échelle plus globale, c’est tout un écosystème digital qui doit évoluer jusqu’à atteindre son Tipping Point, pour plus largement transformer la culture de la qualité logicielle.

Travaillons donc à cette mission commune pour avoir la chance de vivre cette transition.