« C’est la faute de la QA ».
C’est l’excuse récurrente et facile d’une nouvelle release retardée et pleines de bugs. Il faut un coupable, et pour une fois on ne peut pas blâmer le réseau. La QA, responsable de la qualité est une cible idéale.
En plus, « ce n’est pas compliqué de faire des tests. ». En prenant un peu de recul, cette position fait l’hypothèse que qualité rime avec tests. Pourtant, on fait des prises de sang sans pour autant être en bonne santé.
Cette ségrégation de la QA atteint rapidement ses limites pour contribuer à la création de valeur. On arrive au mieux à exécuter quelques tests automatisés pour trouver des anomalies ayant un coût de rework élevé en bout de chaîne.
Cet article partage les éléments clefs du modèle de Quality Assistance inspiré d’acteurs de référence tels que Atlassian ou GitLab. Vous pouvez retrouver leur mise en place chez Manomano et OpenClassrooms dans cet article.
Suivez la QE Unit pour plus de contenu exclusif de Quality Engineering.
La Quality Assistance, nécessaire à la création de valeur
La traditionnelle QA est trop souvent perçue comme le cabinet de tests médicaux réalisant des tests une fois le développement logiciel terminé. La suite logique est celle d’un silo organisationnel incompris et limité en apport de valeur. Et le plus important, ses objectifs initiaux ne sont pas remplis.
La création d’un département QA émerge d’une volonté d’adresser la qualité du logiciel. Un retour sur investissement est attendu, matérialisé par la création de valeur. Encore faut-il en avoir une définition partagée entre les différentes parties prenantes ; certaines chercheront à améliorer le nombre d’utilisateurs, accélérer la livraison logicielle tandis que d’autres à en améliorer la stabilité.
« Le problème avec la QA traditionnelle est de ne pas créer assez de valeur à temps. On passe d’un investissement à du gaspillage, inutile en Quality Engineering. »
Antoine Craske
Une équipe QA n’a rien de mal en soi. Les problèmes se matérialisent dans son intégration dans l’organisation. Olivier et Vincent ont partagé les mêmes souffrances d’une équipe isolée en mal de performance : une meilleure qualité attendue par les tests « de la QA », un routage de l’insatisfaction du logiciel vers l’équipe « de QA ». Pendant ce temps, le logiciel continue mal construit à sa base pour des utilisateurs qui n’ont pas de temps à perdre.
Le contexte actuel requiert une capacité de livraison continue de valeur, le Quality at Speed. Déléguer des tests à un silo organisationnel loin des besoins de l’utilisateur et de la création du logiciel est loin d’adresser les véritables attributs de la Qualité. Le but est de créer et délivrer du logiciel au niveau attendu au plus tôt. Il faut donc développer une « Quality as a capability » intégrée à l’organisation.
Pour cela, le silo de QA fait place à la Quality Assistance.
La Quality Assistance, une approche systémique de la Qualité
La Quality Assistance n’est pas une équipe, c’est le résultat d’une collaboration d’entreprise créatrice de valeur par la qualité. C’est un paradigme différent intégrant une approche systémique. On peut parler de Quality Assistance quand la qualité logicielle est adressée à la base, en transverse et en continu.
La Qualité à la base
Une conviction fondamentale au Quality Assistance est que la qualité est intrinsèque au produit dès sa création. On ne peut donc pas miser uniquement sur des tests a-posteriori pour « assurer la qualité » du logiciel. Il faut assurer sa création au plus tôt, en mesurant que le niveau de livraison est égal ou supérieur à la définition de la Qualité. La collaboration et l’alignement en transverse des acteurs est donc nécessaire.
La Qualité en transverse
Partager la définition de la Qualité permet aux profils nécessaires à la création de logiciel d’avoir une mission commune. Le product owner, analyste, architecte, développeur et opérateur sont tous dans le même bateau (vous remarquerez qu’il n’y a plus forcément de rôle de « QA »). Si l’équipe ne sait pas livrer au niveau de Qualité en continu, c’est leur problème et celui du management, plus uniquement celui de la QA.
La Qualité en continu
La Quality Assistance s’inspire du Lean pour délivrer rapidement au niveau de qualité attendu. Les acteurs doivent collaborer efficacement et rapidement. Ils doivent pour ça utiliser des méthodes efficaces et avoir les bonnes expertises. En complément, l’organisation doit favoriser la performance en ayant le leadership, management et support nécessaire. C’est ici le rôle pivot de la Quality Assistance.
Malgré son nom, la Quality Assistance n’ambitionne pas de créer des assistés, bien au contraire.
La Quality Assistance crée un écosystème pour le Quality at Speed
Il faut voir la Quality Assistance comme une pièce à double face. D’un côté, elle se matérialise par l’atteinte du Quality at Speed, délivrant du logiciel de qualité rapidement et en continu. D’un autre, elle est supportée par un leadership et un management pour créer et maintenir cet écosystème de qualité.
La transformation vers le Quality Assistance ne se fait pas du jour au lendemain. Une véritable dynamique alignée sur une vision doit se créer dans l’organisation. Ce rôle de leadership est la responsabilité du management qui doit prendre ce thème à bras le corps. La conduite du changement doit impliquer les acteurs en transverse pour qu’ils se sentent engagés dans la transformation.
Ces démarches ont par exemple été prises par les responsables de QA dans le cas de Manomano, OpenClassrooms et MangoPay. Pour réussir, il ne s’agit pas uniquement d’afficher « La qualité est l’affaire de tous ». Des leaders de Qualité doivent piloter cette initiative en transverse dans l’organisation. Ils doivent à la fois réinventer leur organisation mais également celles des autres équipes.
Basculer vers la Quality Assurance démarre souvent par des changements visibles et porteurs de messages. Le nom et responsabilités de l’équipe « QA » est souvent changé pour un acronyme différent comme « Qcraft » (Manomano) ou « Quality Engineering » (OpenClassrooms). On revoit également les attentes des rôles existants pour être au plus près des équipes (coaching, support) ou en animation transverse pour maintenir un équilibre.
Le modèle de Quality Assistance pose de réelles questions d’évolution des compétences.
La Quality Assistance nécessite une évolution des compétences
Les habitudes changent en Quality Assistance pour l’ensemble des acteurs. L’engineering manager est explicitement responsable de la qualité de son produit sans pouvoir se décharger sur une équipe de QA. L’historique profil de QA doit être bien plus dans l’échange pour aligner ses priorités.
Le premier pivot important en Quality Assistance est la responsabilisation de la qualité des livrables aux équipes de première ligne. Il faut donc composer une équipe avec les bonnes expertises du cycle de développement logiciel pour délivrer du Quality at Speed. C’est ici la force du modèle : dans certains contextes un réel profil d’automatisation de tests est nécessaire, dans d’autres, seul un QA manuel plus proche du fonctionnel fera la différence.
La décentralisation de la Qualité nécessite une contre force centrale afin de maintenir un écosystème cohérent. L’accumulation d’optimisations locales finit par créer une performance négative pour l’ensemble du système. Le rôle historique de QA manager évolue donc vers un rôle d’orchestration, garant au final de la performance des différentes personnes contribuant à la Qualité. Les acteurs qu’il anime ne sont d’ailleurs pas tous de la QA.
Pour terminer, le leader de Qualité doit également élargir son impact en transverse avec ses pairs du produit, de l’engineering et des opérations. Il faut donc savoir utiliser son background de QA tout en restant sensible, curieux et intéressé par les sujets transverses pour être pertinent dans les échanges. La valeur de QA en elle-même n’existe pas, elle doit améliorer les attributs de Qualité.
C’est ici que la Quality Assistance contribue à la création de valeur.
La Quality Assistance permet la création de valeur
Nous sommes tous payés pour résoudre des problèmes. La Quality Assistance vient nous aider à résoudre celui d’une QA en déclin, maltraitée et mal perçue dans les organisations. L’objectif est de pro-activement adresser la Qualité de nos produits pour mieux la maintenir en continu, en pouvant le démontrer.
La mesure de création de valeur est un réel sujet. Il ne s’agit pas de calculer un ROI financier en première instance. Cet exercice serait très probablement faux en plus de ne pas être la première priorité. Le changement vers le Quality Assistance se mesure d’un point de vue client et également d’un point de vue interne. Cela se rapproche d’un exercice de Balanced Scorecard.
On mesure l’amélioration de l’expérience utilisateur de diverses façons. L’utilisation du NPS et des mesures d’attraction et de rétention sont de bonnes options. Il faut garder à l’esprit leur limite d’interprétation de corrélation et de causation. La performance business et la recommandation des pairs restent in-fine les mesures les plus significatives.
Sous un autre-angle, les mesures internes permettent de relier les outputs aux outcomes de la Quality Assistance. Olivier et Vincent ont notamment mentionné les métriques du rapport Accelerate tels que le cycle-time, la disponibilité ou la réactivité en cas d’incident. On retrouve également en commun la mesure des bugs critiques en production et son backlog ; sa diminution est un signe de qualité adressé au plus tôt.
La Quality Assistance est un modèle différent du logiciel.
La Quality Assistance, une face organisationnelle du Quality Engineering
La Quality Assistance est un changement structurel des responsabilités au sein des organisations en transformation. Vue de loin, il s’agit d’intégrer la Qualité au plus tôt dans les chaînes de valeur logicielle. Les modèles de contrôle qualité issue de la révolution industrielle n’ont pas leur place dans l’écosystème actuel.
Le Quality Engineering est un paradigme transverse agissant sur les 5 piliers de MAMOS : Methods, Architecture, Management, Organization et Skills. La Quality Assistance s’inscrit dans le framework de Quality Engineering principalement dans les domaines de l’organisation et des compétences.
Il ne suffit pas de changer de langage de programmation pour améliorer structurellement notre logiciel. Les fondations organisationnelles sont fondamentales. Les transformations réussies suivent d’ailleurs le principe du “Why, Who, Then What”. Avoir les bonnes personnes avec les bonnes compétences dans la bonne organisation est donc une des priorités majeures.
Êtes-vous prêt pour la Quality Assistance ?