Il n’y a plus de Quality Assurance chez Manomano & OpenClassrooms

“Nous n’avons plus de Quality Assurance”.

C’est ce que Olivier Dennemont et Vincent Dauce ont réalisé chez Manomano et OpenClassrooms, deux acteurs majeurs du digital. Le mot “QA” et sa perception ont disparu de ces organisations.

La Quality Assurance a fait place au modèle organisationnel de la Quality Assistance. Il s’agit d’adresser la qualité logicielle au plus tôt, en transverse et en continu sur la chaîne de valeur logicielle.

Dans cet interview, nous partageons leurs expériences de transformations respectives en explorant leur définition, conduite de changement et résultats obtenus. Les références évoquées sont disponibles en fin d’article.

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

Pouvez-vous commencer par vous présenter ?

Vincent : Je suis directeur qualité à OpenClassrooms. Je prépare d’ailleurs un talk à ce sujet pour la Paris Test Conf. C’est l’approche que nous avons mise en place avec notre équipe de qualité. Je fais également partie de la communauté Ministry of Testing Paris, qui interagit globalement avec les autres communautés en France.

Olivier : Je suis responsable Qualité chez Manomano. Je manage l’équipe “Qraft” qui représente le jeu de mot en Qualité et Craftsmanship. Je suis arrivé il y a 2 ans et demi sur la QA pour en redéfinir la stratégie. J’ai un background d’engineering manager principalement sur des applications mobiles.

Quelle définition donnez-vous à la Quality Assistance ?

Olivier : La Quality Assistance tranche clairement avec Quality Assurance. On associe trop souvent la notion d’être garant du logiciel qui va en production dans beaucoup de contextes.

Chez Manomano ce modèle ne fonctionne pas du tout. Notre contexte est celui d’une entreprise en hypercroissance, avec une architecture se complexifiant et qui se distribue pour répondre aux enjeux de l’organisation. Avoir des personnes qui vérifient que “la qualité est bonne” ou “qu’il n’y a pas de bugs” en fin de chaîne ne fonctionne pas.

J’ai trouvé le modèle de Quality Assistance chez Atlassian en cherchant à développer une alternative. Avec le temps, j’ai appris à appréhender et itérer sur la mise en place du modèle. Il répond à une problématique concrète de scalabilité des pratiques de Qualité. On apprend à tout le monde à mieux travailler plutôt qu’à optimiser un silo.

“Venant moi-même de l’engineering, je suis convaincu qu’il faut produire du logiciel au bon niveau au plus tôt. Agir en seconde phase n’est pas la priorité.”
Olivier Dennemont

Vincent : Je rejoins Olivier sur beaucoup de points. La grande différence est que cette approche implique beaucoup de personnes. Il faut réussir un vrai changement d’état d’esprit pour différents acteurs : le développeur, designer, product manager, etc. C’est un réel changement organisationnel.

L’objectif principal c’est d’accélérer le delivery par la collaboration finalement. On dit que l’on collabore, c’est vrai. Néanmoins, on retrouve trop souvent des silos qui se passent des patates chaudes sans réellement échanger en transverse.

Pourquoi avoir initié une démarche de Quality Assistance ?

Vincent : En juillet 2020 nous avions changé la manière de gérer nos roadmaps. Nous avions lancé un sondage commun lors des diverses rétrospectives. Lors de cet exercice, nous avons obtenu deux fois plus de feedbacks sur l’organisation de la qualité, ses difficultés et son inclusion avec la roadmap. Cela a été le point de départ.

Nous partions de loin. La QA était “responsable” de délais de livraisons en production. Des raccourcis étaient ensuite pris pour aller vite mais au détriment de la qualité. On entendait souvent “c’est la QA qui bloque”. Et pourtant, 40 à 95% des tâches assignées à la QA contenait en fait des causes racines en amont.

On a donc décidé d’adresser l’organisation pour ces soucis de performance structurels.

Olivier : Nous avons accumulé des symptômes similaires. Trop souvent la QA était jugée responsable de problématiques de livraison logicielle. Un raccourci très discutable était fait entre des problématiques de qualités rencontrées par un manque de tests de l’équipe QA. Nous devions également arrêter les erreurs et bugs récurrents.

La perception de la QA étant contradictoire avec les raisons mêmes d’existence de bugs. Ils existent pour cause d’architecture, de code ou d’incompréhensions ; pas par manque de tests. Plus de tests ou des tests différents peuvent aider à la détection. Mais ce qui nous intéresse, ce sont les causes racines.

Nous avions grand besoin de mettre la tête hors de l’eau pour tirer notre qualité vers le haut. Il fallait réussir à donner envie et embarquer les équipes pour également s’inclure dans les démarches Lean, Agile ou DevOps. Je suis d’ailleurs souvent surpris de l’écart de maturité dans le software engineering pour les approches qualité.

Quels changements avez-vous réalisés ?

Olivier : J’ai renommé l’équipe en “Qraft”. Le message fort était de clarifier que nous n’étions plus une équipe QA.

Nous y avons incorporé d’autres profils tels que des développeurs. Ils aident les autres développeurs avec des outils, de la collaboration, des méthodes. Nous avons également intégré des coachs craftsmen pour aider les développeurs à faire mieux à la racine. Leur but étant comme le principe d’uncle Bob “QA should find nothing”.

Pour y arriver, nous avons mutualisé les équipes craftsmanship de l’architecture au sein de cette équipe. Nous avons transformé les posts de Quality Assurance Engineers en Quality Advisors. Ces derniers sont délégués dans les équipes produit pour collaborer au plus tôt, au plus proche et en continu de la chaîne logicielle.

Différents rôles sont nécessaires. Nous avons des managers, des coachs, et également des ambassadeurs. Animer l’ensemble des acteurs est fondamental au changement.

Vincent : Nous avons changé beaucoup de choses de manière itérative. L’équipe QA a également été renommée en Quality Engineering. J’ai moi-même changé de poste de QA manager pour Quality Director. Nous voulions marquer le coup en faisant disparaître le terme “QA” trop associé à “Quality Assurance”.

Nous avons aligné la mission de l’équipe pour clarifier notre intention. Loin de faire du test ou uniquement chercher des bugs, notre mission s’est axée sur “accelerate the achievement of shippable quality that makes education accessible”. Les deux concepts importants sont “accelerate” et “shippable quality”.

Nous avons beaucoup communiqué partout dans l’organisation, au produit, à la tech. J’ai organisé un kick-off officiel en transverse pour expliciter où nous voulions aller. Nous avons également favorisé l’acculturation avec divers contenus comme la vidéo d’Alan Page sur Adventures in Modern Testing. En 2021, nous avons fait intervenir une société externe pour nous aider à définir la Qualité : partager les perceptions, ses critères et ses objectifs.

Nous avons décliné notre mission en objectifs pour accélérer la livraison, en supprimant les bottlenecks tout en garantissant la qualité. Fini les indicateurs sur le nombre de tickets vérifiés et le focus local. Nous regardons des objectifs transverses tels que le cycle-time alignés avec notre mission.

L’engagement des différents acteurs était fondamental pour obtenir leur besoin, leur soutien et permettre une réelle transformation vers une collaboration transverse.

Quels résultats avez-vous obtenus ? Pour quelle création de valeur ?

Vincent : Nous sommes revenus sur la mesure un an après avoir lancé la démarche.

Plusieurs améliorations structurelles ont pu être constatées :

Une amélioration du cycle-time de 34% de la fin du développement à la disponibilité en production ;
La disparition des plaintes de “bottleneck de QA” lors des diverses rétrospectives ;
Une amélioration des tests “utiles” et créés par des autres acteurs que ceux historiques de la QA.

En complément, nous avons également lancé un sondage sur la perception de la QA. 60% des équipes nous ont jugé indispensables, 30% très utiles et 10% utiles. C’est un vrai marqueur de changement dans l’organisation passé un an. Nous avons même un peu peur d’être indispensables.

C’est compréhensible dans notre phase de maturité et nous y travaillons.

Olivier : Nous avons mesuré en premier le nombre d’anomalies connues et d’ouvertures en production. Pendant la première année, nous avons accumulé sans voir de changements structurels. C’était d’ailleurs préoccupant, je commençais presque à ne plus y croire.

Mais nous avons ensuite constaté une inverse de la tendance. Nos 800 defects ont été réduits de l’ordre de moitié.

Nous sommes également sortis du cercle vicieux du broken window. À l’instar d’une politique de zéro-bug, la présence d’un seul bug générait de suite une réactivité pour le traiter au plus vite. Auparavant, un bug parmi tant d’autres était considéré comme normal et restait un temps considérable ouvert.

Le rôle de l’équipe est en fait de créer et maintenir cette pression constante pour la qualité sans la rendre étouffante. Cette contrainte doit permettre de libérer les énergies pour adresser en pro-actif la qualité portée sur l’expérience utilisateurs et les améliorations plus que le traitement de défauts.

Quels freins avez-vous rencontré ? Quels apprentissages en tirez-vous ?

Olivier : Il a été difficile de tenir le cap sans obtenir de résultats dans les premiers mois. Nous avons dû expliquer que le modèle était viable et pérenne sans pouvoir le justifier dans notre contexte.

Les acteurs étaient trop habitués à rythme confortable d’exécution de contrôles a posteriori. En réalité, il était impossible d’adresser la qualité de cette façon. Il faut pouvoir challenger les choix d’architecture, de design et même de solutions.

“La résistance au changement était la principale problématique à adresser.”
Olivier Dennemont

Nous avons dû avoir une réelle force d’affront et d’assertivité pour remettre en cause certains choix. La pédagogie était essentielle en faisant références à d’autres secteurs, d’autres organisations comme Atlassian, en les raccrochant à des exemples internes.

Les fausses équations de “qualité = test” et “test = qualité” ont également dû être démantelées dans les esprits. Cela parait évident, mais il faut faire reprendre du recul aux différents acteurs sur la place du test dans la chaîne de valeur logicielle.

J’aime beaucoup les travaux de James Bach à cet égard qui décorrèlent les tests qui peuvent être automatisés ou non. On peut atteindre une des limites du modèle quand on doit réaliser des tests nécessitant une expertise de testeur réel. Il faut avoir les bonnes compétences pour réaliser les bons tests.

Vincent : On a rencontré les freins classiques à tout changement. Des acteurs qui posent des questions, dubitatifs du modèles, à critiquer le modèle, remettre en cause les processus et propositions. Ces freins font parti du processus.

Nous avons avancé avec les personnes qui étaient le plus appétants à cette démarche. Petit à petit, cela a fait boule de neige sur le reste de l’organisation avec des gens qui finissent par se prendre au jeu.

Les problématiques principales concernent les rôles et responsabilités de chacun dans une approche Quality Assistance.
Vincent Dauce

On dit souvent “la qualité est l’affaire est l’affaire de tous”. On peut être d’accord avec ce principe, faut-il encore le décliner dans le reste de l’organisation. En Quality Assurance, le modèle était clair mais inefficace. En Quality Assistance, il faut mettre en place un effort collectif qui requiert une clarification qui peut être nuancée en fonction des contextes. Parfois, la collaboration est la réponse.

Il a fallu également adresser les rôles et compétences. Nos rôles existants ont dû évoluer pour plus de support et de coaching au lieu d’uniques contributions opérationnelles. Certains ont évolué sur du code review, du TestingOps.

En parallèle, notre organisation a grandi dans un contexte de croissance qui a rendu difficile notre tâche. Nous avons dû intégrer des gens qui n’avaient complètement connu le monde d’avant ni été embarqués dans la démarche. L’alignement des acteurs par une clarté de responsabilité et une communication soutenue ont été fondamentales.

Quelles sont vos prochaines priorités de Quality Assistance ?

Olivier : Nous nous focalisons sur le Quality Management qui va même au-delà de la Quality Assistance.

Je travaille à sensibiliser le top management sur les problématiques de Qualité. L’objectif est que la Qualité devienne un critère intégré aux décisions structurantes d’entreprise. Le débat doit être transverse et remonter jusqu’au niveau du comité de direction, pour ensuite permettre des investissements encore plus structurels.

J’ai un effort fort de communication à réaliser en utilisant des données et en reliant le sujet aux enjeux de l’entreprise. C’est un effort constant pour augmenter cette pression positive à la Qualité.

Les métriques focalisées sur l’expérience utilisateurs sont par exemple très puissantes et facilement déployables à l’ensemble de l’organisation.

Vincent : J’ai travaillé sur un document de formalisation de l’évolution de nos pratiques de Qualité chez OpenClassrooms. C’est en fait la formalisation de tout notre effort et notre vision pour aligner les acteurs et nous aider dans la suite.

La Qualité a toujours été une composante forte chez OpenClassrooms. Nous avons des profils de qualité directement affectés à la qualité des cours au sein des équipes de contenus. La qualité est un sujet culturel à garder en vie au quotidien.

Notre prochaine priorité est de consolider puis de monter au niveau de maturité suivant du modèle de Dan Buckland. Nous voulons évoluer vers la Phase 2 où la majeure partie des autres équipes réalisent les activités de Qualité.

Nous adressons par exemple la pratique des tests d’intégration avec les développeurs, tant sur le front que sur le back end. Notre objectif est de fournir des boîtes à outil pour les rendre autonomes sur les tests automatisés.