Notre dernier événement était dédié à la responsabilisation des équipes à la qualité logicielle.

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

• Ahmed Hafni, Responsable du Pôle Testing chez KP2i
• Anass El Bekali, CEO QSI Conseil, Président du CMTL
• Arnaud Dutrillaux, QA Lead chez Synthesio
• Benjamin Butel, passionné du test, software engineering in Test chez Klaxoon, organisateur du Ministry of Testing Rennes
• Christian Sayegh, Consultant et Spécialiste en Automatisation chez CloudNetCare,
• Hugo Casanova, QA Lead chez AOS
• Johann Gaggero, Head of Omnichannel QA chez LVMH
• Sophie Tual, QA Engineering chez PayLead
• Grace Kongo, Test Analyst chez Q-leap

Dans cet événement, nous avons en particulier abordé les questions suivantes :

• Quelle place pour la qualité logicielle dans l’entreprise ?
• La qualité logicielle, pour qui et pour quelle utilité ?
• Comment identifier la valeur de la qualité logicielle ?
• Quelle(s) organisation(s) pour transversaliser la qualité logicielle ?

Notre première question a été celle du positionnement de la qualité logicielle dans la réflexion plus globale de l’entreprise.

Quelle place pour la qualité logicielle dans l’entreprise ?

Souvent considérée comme une fonction support de second rang, la qualité logicielle se retrouve souvent positionnée entre le métier et l’IT.

Plus précisément en reporting de l’une de ces fonctions.

Ces options font amèrement penser aux DSI rattachés au CFO ou au COO, traduisant le niveau d’intérêt porté à la fonction.

Et vous, votre qualité a-t-elle siège au comité de direction?

Quelques entreprises ont fait le pas, et peuvent s’être doté d’un pertinent “Head of Product, Acceleration & Quality”.

La qualité est souvent le parent pauvre du logiciel.

Christian Sayegh

Nous avons identifié plusieurs facteurs contribuant à ce positionnement de second plan.

La proposition de valeur de la qualité logicielle n’est souvent pas raccrochée à des indicateurs et enjeux que la direction valorise.

Pour d’autres, externaliser la qualité est un choix plus ou moins délibéré pour s’en décharger la responsabilité.

Structurellement, la qualité est transverse dans ses activités, la rendant difficile à positionner entre le métier, l’ IT, et le support.

On retrouve donc des silos et cloisonnements encore fortement présents.

Des séparations qui peuvent d’ailleurs faire distancier les équipes de leur réel client. 

La qualité logicielle, pour qui et pour quelle utilité ?

Arnaud nous a introduit un élément de réponse par cette citation.

“Quality is value to some person.”

Jerry Weinberg

Cette notion de perception de valeur pour un acteur est clef.

Elle ajoute une dimension humaine, de perspectives et intérêts à prendre en compte au-delà d’un aspect statique du produit.

Prenons l’exemple d’une équipe de test en silo. Elle aura tendance à optimiser la valeur locale de qualité de sa perception, optimisant la couverture d’une matrice de tests par exemple.

Mais finalement, quelle est la valeur de cette qualité pour le client final? 

Probablement très peu.

À l’inverse, une interface minimaliste rapidement livrée avec un minimum de test d’acceptation pour être très utile à un client.

Elle sera en également de valeur à la direction souhaitant accélérer la livraison de solutions digitales pour ses clients et sa performance.

Il faut donc centrer son approche sur l’apport de valeur aux différents acteurs de l’écosystème.

Comment identifier la valeur de la qualité logicielle ?

Comprendre le point de vue des clients de la qualité est nécessaire.

L’empathie, écoute active, et capacité de reformulation sont fondamentales afin de cerner les enjeux, mots et intérêts des parties prenantes.

Articuler la valeur de la qualité nécessite souvent de se confronter à la réalité de l’expérience client et des processus de l’entreprise.

Johann partageait la co-localisation des équipes de QA au plus proche du client, jusqu’au terrain, magasin, entrepôt.

Le support client est d’ailleurs une excellente source d’informations quant à la perception de  qualité que toute organisation devrait avoir en visibilité.

La qualité doit être au plus proche du métier, jusqu’à l’entrepôt et au contact du client.

Johann Gaggero

Définir les parcours utilisateurs bout en bout via des personas permet également d’axer l’ensemble d’une équipe autour de mêmes enjeux.

Les supports de communication doivent aussi refléter le langage métier, du client final et des interlocuteurs en interne.

Finalement, pourquoi agir différemment du métier ?

Cette capacité d’adaptation, presque de caméléon, permet de s’imprégner et d’être intégré par les équipes métier.

Articuler la valeur de la qualité logicielle requiert donc une pro-activité initiale.

Comment articuler la proposition de valeur de la qualité logicielle ?

Identifier les contours de la valeur est une première étape.

Arnaud rappelait que la qualité logicielle ne se résume pas qu’aux tests, un élément souvent important de rappeler aux non-initiés.

D’un point de vue protecteur, la réduction du risque est souvent citée, néanmoins, la qualité logicielle ne s’effectue pas qu’à posteriori en bout de chaîne.

La qualité est une composante clé dans l’apport de stabilité, de confiance et de réduction des cycles d’itérations.

N’est-ce pas l’accélération maîtrisée que beaucoup d’organisations cherchent à atteindre ?

La qualité peut donc être défendue par la capacité à accélérer les capacités d’apprentissages, livraisons et de réactivité de l’organisation.

Pourquoi ne pas appliquer l’ingénierie des exigences à ses processus de quality engineering, au-délá du seul produit ?

Comment identifier les exigences d’une démarche de Quality Engineering ?

Les exigences doivent permettre de traduire les besoins de l’organisation dans la démarche plus globale de qualité.

La catégorisation en besoins fonctionnels et non-fonctionnels est également pertinente.

Les exigences fonctionnelles doivent permettre de répondre à des cas d’usages pour les différents acteurs identifiés : product owner, product analyst, software engineer, …

Par exemple, les services requis par un développeur doivent pouvoir se retrouver disponible en self-service sur la plateforme de développement.

Quant aux exigences non-fonctionnelles, même si nombreuses, leur alignement en termes de définition, priorité et planification est plus que nécessaire.

L’accélération et la stabilité sont des attentes courantes même si rarement explicitées et mesurées dans une démarche.

La portabilité peut par exemple être un valorisé par l’organisation, pouvant nécessiter d’utiliser des abstractions et séparations explicites des systèmes.

La scalabilité mérite un atelier de définition de par ses diverses interprétations et perceptions possibles, du déploiement jusqu’à la parallélisation.

La sécurité est également à clarifier pour valoriser et identifier la réduction de risque possible.

Ce sujet mérite plusieurs articles, le message étant de capitaliser sur l’ingénierie des exigences.

Quelle(s) organisation(s) pour transversaliser la qualité logicielle ?

L’architecture de l’organisation de la qualité est un réel sujet.

Comme pour un projet, il convient d’en définir les objectifs et enjeux.

Les étapes précédentes ont dû permettre d’identifier les leviers de capture de valeur de la qualité logicielle.

La conception d’organisation est fortement liée aux interactions qu’elle va favoriser ou au contraire défavoriser.

Comme pour beaucoup de sujets, je pense que la réponse est dans l’équilibre.

Déployer à l’extrême des modèles en features-team aura tendance à créer des silos parallèles, propices à des duplications et conflits à moyen-terme.

Au contraire, une équipe fermée verticalement dans un mode shared services pourra avoir tendance à optimiser ses flux de processus propres, se distanciant des besoins des clients finaux.

Les modèles SaFE et d’agilité à l’échelle possèdent des éléments de réponse dont on peut s’inspirer : coach agile ou enabler, équipes transverses alignées sur des OKR métier, communautés transverses en interne.

Dans tous les cas, la qualité doit réussir à être incluse by design, au plus tôt du besoin métier.

Le positionnement et l’organisation de la qualité doivent donc avoir été pensés, formulés et mis en place.

Si les modèles existent, pourquoi cela reste-t-il si difficile ?

Quels freins à une transversalisation de la qualité ?

La conduite de changement des organisations passe par les individus et les dynamiques de groupe existantes.

Les egos des diverses parties prenantes ne doivent donc pas être sous-estimés.

Les intérêts sont des moteurs forts du comportement, de la motivation à la volonté de se transformer et d’agir hors de zone de confort.

La problématique ne serait-elle pas dans les silos et les différents egos ?

Benjamin Butel

Benjamin nous partageait la posture parfois arrogante de la MOA versus la MOE, voulant presque se substituer au client final.

Dans ce cas, c’est un vrai frein à la transversalisation de la responsabilité de la qualité, même avec un modèle d’organisation horizontalisé.

C’est aussi le cas pour les développeurs ou un profil opérations : pourquoi irait-il à des réunions supplémentaires au lieu de faire tranquillement ses tâches habituelles ?

Le changement et sa conduite doivent être pensés, animés et renforcés.

Nous en revenons également aux sponsors, si différenciants et de poids dans la mise en place d’une démarche qualité.

Quels intérêts pour les sponsors d’une démarche de qualité ?

Un projet sans budget est probablement peu prioritaire et avec une forte probabilité d’échouer.

Même si irritante, cette question de l’existence d’un budget demandé par des commerciaux en phase de prospection en montre l’apprentissage.

La réalité est qu’un réel budget doit être débloqué par des sponsors pour une démarche qualité à impacts.

Pour convaincre, il faut cerner les intérêts des sponsors en plus des enjeux de ceux de l’organisation.

Un projet sans sponsor rime souvent avec un projet sans budget.

Christian Sayegh

Dans certains cas, ils seront alignés avec ceux de l’organisation.

Parfois, ils seront avec une orientation plus politique ou d’enjeux personnels, qu’il convient d’en juger l’alignement avec l’entreprise.

La perception de maturité et de sensibilisation à la qualité dans l’organisation est nécessaire, pour ajuster et cibler son effort.

Arnaud nous posait la question d’une qualité logicielle qui resterait trop sur ses appuis historiques, en retrait. 

Elle doit effectivement être pro-active jusqu’aux sponsors, même en étant souvent mal positionnée dans l’organisation.

Finalement, comment faire de la qualité l’affaire de tous ?

La qualité logicielle est un ensemble d’activités, pas une responsabilité individuelle.

En faire l’affaire de tous revient à en faire en priorité pour l’organisation, par les divers jeux d’influence et d’animation, et à en orchestrer des activités en maturité croissante.

Les objectifs de la démarche doivent être de réels apporteurs de valeur, tant pour le client final que pour les intérêts des différents acteurs.

Adapter les objectifs par étape de maturité de l’organisation permet de passer les étapes.

Hugo nous partageait le cas d’entreprises qui, même récentes et seules sur leur marché ou leader principal, intègre la qualité à un niveau d’exigence poussé afin de garder une longueur d’avance.

L’architecture de l’organisation, en particulier des interactions, est un élément différenciant pour l’atteinte des objectifs du système.

Il est effectivement très difficile d’obtenir des résultats pour lesquels le système et l’organisation n’ont pas été conçus.

L’ensemble de l’organisation doit être embarquée et motivée par la démarche, afin de se sentir responsable, active et avec un impact sur son évolution.

C’est également ce qui permettra d’avoir de réels mécanismes d’apprentissages organisationnels mis en place et structurellement performants à long-terme.

Nous nous sommes également demandé si la qualité devrait devenir un critère de valorisation des entreprises, ou intégré comme la responsabilité sociale.

La qualité doit en tout cas être partie intégrante du produit dès sa conception, qu’elle soit ou non renforcée par des mécanismes d’incentives.

Au-delà d’intérêts individuels, un réel leadership et pro-activité sont nécessaires.

Faut-il attendre un nouveau CxO de la qualité logicielle pour y arriver ?

À priori non, nous pouvons déjà agir comme ce leader aujourd’hui.