La table ronde de la Quality Engineering Unit s’est réunie pour partager autour du thème “Comment communiquer la valeur de la qualité logicielle ?”.

Convaincre et investir de manière continue dans une démarche qualité requiert d’en percevoir sa valeur.

Souvent associée à une fonction support et de réduction de risque, la qualité logicielle est jugée difficile de raccrocher à des enjeux métiers traditionnels.

Justifier un retour sur investissement est d’ailleurs souvent demandé par les organisations, une démarche presque inversée.

Nous avons partagé les thèmes suivants :

• Que faut-il communiquer, à qui, à quel niveau, à quelle fréquence?
• Quels indicateurs sont pertinents d’utiliser? Dans quel contexte?
• Quels formats, outils et visualisations peuvent être utilisés?

Je remercie chaque participant pour leur participation et contribution :

• Luís Vicente, QA Lead Link chez Mercedes-Benz.io 
• João Santos, QA Engineer Freelance
• Filipe Sousa, QA Senior Consultant chez Noesis

Vous pouvez retrouver l’épisode en vidéo et audio.

La qualité logicielle doit apporter de la valeur à l’entreprise

Pouvoir communiquer une valeur métier implique sa création au préalable.

Dans les faits, l’alignement de la valeur de la qualité logicielle sur des objectifs valorisés par l’entreprise reste un réel défi.

C’est d’ailleurs une problématique que l’on retrouve plus globalement dans l’IT, l’alignement métier étant une réelle priorité des DSI et architectes, entre autres.

Est-ce vraiment un exercice possible pour la qualité logicielle?

Cela reste un exercice de communication et de collaboration, particulier à chaque contexte pour identifier les points pertinents.

Une chose est sûre : sans un focus sur l’apport de valeur à l’organisation, une démarche de qualité ne tiendra pas longtemps, faute de contribution, de support et de visibilité.

L’identification et la communication de la valeur est donc un thème majeur à adresser.

Quels paramètres sont valorisés par le client?

Nous en sommes venus à nous focaliser sur les attentes du client.

La première priorité est de comprendre ce qui est valorisé, attendu et imaginé pour les principales parties prenantes.

Sur une première itération, la valeur attendue ne se dégage pas directement.

Des premiers indicateurs de support ou autocentré peuvent parfois émerger sur une couverture de matrice de tests.

Les objectifs mentionnés en surface ne sont pas les seuls à considérer.

Faire preuve d’écoute active, empathie, reformulation sont des compétences clefs dans cet exercice.

Deux questions sont utiles pour un premier échange : “Pourquoi ?” et “Pour quoi (faire) ?”.

L’étape suivante est de traduire les objectifs en indicateurs.

De bons indicateurs de qualité ne sont pas de QA

La mesure de la performance d’un système ne se résume pas à celle d’un sous-ensemble.

Les indicateurs traditionnels de QA sont utiles à cette fonction en tant que telle, mais doivent être contextualisés plus largement.

Prenons l’exemple de la couverture de test.

Certains développeurs vont par exemple chercher à l’optimiser à 100% dans leurs tests unitaires.

En complément, un testeur va plutôt se focaliser sur la couverture de la matrice des cas fonctionnels, en manuel ou en automatique.

La question doit être posée dans l’autre sens : est-ce la couverture de test peut nous aider à atteindre un objectif clef de l’entreprise, valorisé par le client?

Si l’on recherche la stabilité de l’expérience client, nous pourrions par exemple combiner plusieurs indicateurs:

• La couverture de tests sur les cas d’usages les plus fréquents et à plus forte valeur ajoutée
• Le nombre de bugs rencontrés par le client qui doit être proche de zéro sur ces cas
• Le nombre de bugs détectés avant livraison et analysés par environnement, afin de juger de la pertinence de notre intégration
• Le délai de détection et de résolution d’un cas d’usage critique (a.k.a. MTTI & MTTR)

Cette combinaison d’indicateurs permet de juger de la performance du système de qualité, sur l’ensemble de la chaîne et des acteurs.

Et l’automatisation dans tout ça ?

L’automatisation n’apporte pas de valeur en tant que tel

Filipe nous a partagé une expérience où le nombre de tests automatisés seul était l’indicateur de performance du client.

Il convient dans ce cas de réaliser son devoir de conseil pour identifier les raisons de ce focus si particulier, et si d’autres enjeux ne peuvent pas être plus pertinents.

Dans ce cas précis, on peut retrouver un besoin d’automatisation fort poussé par la direction pour industrialiser des processus et accélérer les livraisons.

Néanmoins, pour atteindre cet objectif il peut être contre-productif d’automatiser à outrance, surtout oú cela n’est pas pertinent.

La méthode des “5 Pourquoi” peut être utilisée, formellement ou informellement en fonction de votre audience, et même en exercice personnel de réflexion.

Comme pour les indicateurs, les critères d’automatisation doivent être analysés dans leur ensemble.

L’automatisation est souvent liée à des besoins d’accélération, d’optimisation des coûts et de qualité de l’exécution de processus.

Plusieurs hypothèses sont à considérer pour l’automatisation:

• Quel est l’investissement requis pour initier l’automatisation? (humain, organisationnel, outillage)
• Le périmètre d’automatisation est-il mature en termes de processus, avec une relative stabilité?
• Quel est le nombre d’exécution et la durée de vie des processus á automatiser?

Finalement, quelle est la valeur de l’automatisation versus celle de la non-automatisation?

La décision d’automatisation nécessite une prise en compte forte du contexte.

Une organisation ayant de solides fondations d’automatisation, peut par un investissement initial réduit, capter plus facilement de la valeur, même sur des périmètres restreints.

Mais l’automatisation rythme-elle avec accélération?

La vélocité de l’équipe, une valeur clef de la qualité logicielle

La qualité est souvent perçue comme un frein dans les cycles de développement logiciel.

Il faut avouer qu’ajouter des tests manuels ou automatiques retardant la capacité de valider la valeur métier d’une fonctionnalité ne semble pas attrayant.

Les expériences d’investissement de tests balayés dès la première livraison pressante et des tests instables sont courantes.

C’est pourquoi une démarche de qualité doit bien garder dans son prisme l’atteinte de cycles courts intégrant la qualité.

Cette vélocité désirée représente de réelles difficultés pour les différents acteurs.

Les développeurs ont besoin de retour rapides dans leurs itérations de développement, afin de rapidement livrer un incrément produit.

Par la suite, les équipes de qualification et métier doivent pouvoir rapidement évaluer la réponse aux exigences et de la non-régression.

Finalement, l’équipe doit pouvoir mesurer la valeur pour le client final des fonctionnalités livrées.

C’est bien ce cycle qu’il faut accélérer tout en garantissant la qualité du produit pour atteindre une réelle vélocité.

Un exercice peut être de partager un triangle à équilibrer entre rapidité, qualité et fonctionnalités.

Faut-il encore que les tests soient utiles.

Combien de bugs vos tests ont-ils détectés?

C’est une question parfois peu mesurée, au détriment de “vanity metrics” maximisant une couverture de code ou de test.

Le surcoût de développement et de maintenance de tests inutiles est rarement pris en compte.

C’est pourtant ce qui facilement arrivant dans des modèles d’organisation en silos ayant des indicateurs locaux à optimiser.

Une bonne manière de reprendre de la perspective est de considérer plusieurs facteurs pour juger de l’utilité des tests :

• Sont-ils pertinents pour votre expérience client ou objectifs mis en avant par l’organisation?
• Combien de fois ont-ils été exécutés sur le dernier mois, avec quel ratio de stabilité?
• Combien de fois ont-ils pu détecter un bug, avec quelle criticité, taux de faux-positif?

Si vos indicateurs tendent vers le négatif pour ces points, la pertinence des tests est questionnable.

En note de contexte, les tests ayant pour objectif de valider les cas d’erreurs et d’exception ne doivent pas être analysés par leur volume d’utilisation, en tout cas je l’espère pour les clients.

Calculer un coût à l’usage peut également permettre de mettre en avant le coût d’optimisations prématurées.

Tester en production peut-il être utile?

Une bonne raison de ne pas tester en production serait d’avoir un environnement hors production identique.

Étant un idéal peu réaliste, je suis convaincu que la réponse est affirmative en précisant le propos.

Effectuer des vérifications uniquement en production qui auraient dû être faites en amont n’est clairement pas recommandé.

Par contre, ils peuvent être très pertinents et complémentaires, si bien choisis.

La notion de tests en production à valeur doit être différenciée entre :

• De réels tests exploratoires visant à découvrir des défauts par l’expérimentation à l’échelle
• Des tests fonctionnels automatisés réguliers de non-régression, souvent associés à de la supervision d’expérience utilisateur
• Des tests de disponibilité, résistance et de fiabilité basé sur les pratiques du “chaos engineering”
• Des tests de vérification des exigences de temps de réponse, chargement d’éléments ou de sécurité par exemple

Ceux réalisables en amont de la chaîne doivent l’être, en gardant pour la production la complémentarité des spécificités de cet environnement.

Un processus incrémental de création et de communication de métriques

Vous êtes peut être familier avec un projet “Quality Dashboard V1” en route depuis des mois, en effet tunnel, sans aucun tableau de bord disponible? 

On aborde plus facilement l’agilité pour les projets à composante métier, mais la néglige pour les projets internes.

La définition, collecte et communication des métriques est un processus qui a plus de probabilité de succès par une démarche itérative.

Beaucoup d’hypothèses sont initialement présentes, il convient donc de prioriser les actions pour pouvoir rapidement s’adapter.

Sélectionner les métriques à plus forte valeur ajoutée dans un premier temps, et essayer de les mesurer le plus rapidement possible.

Une première collecte de données peut révéler des problèmes structurants de qualité, disponibilité ou même de pertinence.

Inutile donc de s’attarder sur des flux de données automatiques et des dashboards colorés, le focus doit être de valider les indicateurs.

La seconde étape est de valider leur perception de valeur auprès des parties prenantes, qui sont focalisés sur les objectifs clients et de l’entreprise.

Utiliser les réunions existantes de point d’équipes, rétrospectives et autres rituels est la meilleure manière d’obtenir du feedback, en complément de demandes informelles.

Une fois cette première version atteinte, après quelques itérations, l’automatisation, le déploiement sur d’autres produits et l’ajout de métriques peut démarrer.

Quels supports pour favoriser une diffusion plus globale ?

Les reportings ont-ils une valeur pour les parties prenantes ?

Dans l’hypothèse où les objectifs ont été bien définis, les supports de communication doivent être adaptés à l’audience.

J’ajouterais presque, adapté à la personne ou à vos “personas” internes.

Comme dans la vraie vie, il est difficile de plaire à tout le monde.

Un directeur fortement en déplacement préfèrera probablement un format simple disponible sur une application, sauf s’il préfère avoir une mise à jour téléphonique directement.

Une équipe de développement aime normalement avec des tableaux de bords colorés en “dark mode”.

D’autres profils vont préférer un reporting sur tableur afin d’explorer et d’accéder à la donnée.

Travailler par étape, en fournissant au plus grand nombre, puis de gérer les exceptions est une approche 80/20.

Un dashboard simple peut être construit et disponible pour tous, comme source de vérité.

Si possible, ajoutez-y une capacité d’export, et envoi d’alertes par email ou téléphone pour satisfaire le plus grand nombre.

Une bonne pratique, quand cela est possible, est d’afficher ce tableau de bord sur un lieu de passage des équipes, le partager aux daily, et proposer aux équipes de l’ajouter en onglet automatique d’ouverture de leur navigateur.

En définition, les tableaux de bords ont de la valeur s’ils sont partagés, à jour, régulièrement poussés aux équipes, adaptés aux canaux d’usages et utilisés en pilotage.

Utiliser les mécanismes existants pour communiquer la qualité

On peut vite vouloir créer des instances spécifiques pour parler de la qualité.

Une approche pragmatique, favorisant le message de transversalité, est d’ajouter la qualité aux points existants.

Prenons en premier exemple le daily stand-up de l’équipe, c’est une belle opportunité de partager et de communiquer sur la qualité.

Les points réguliers de rétrospective et de planning doivent également être utilisés pour y intégrer la qualité comme un réflexe et une partie intégrante.

Ajouter des indicateurs et des actions sur un processus de rétrospective d’incident est également une bonne manière d’identifier le besoin de qualité sur toute la chaîne.

Enfin, avec un bon travail d’influence en interne, les réunions d’équipes et de l’entreprise doivent laisser de la place à la qualité.

À l’instar de la publicité, la qualité doit être présente, communiquée et valorisée régulièrement pour avoir un impact.