Notre dernier événement était le premier clairement orienté sur le thème du Quality Engineering, en partant du pivot “De la QA au QE, par où démarrer? ».
Je remercie les participants suivants pour leur présence et contribution :
- Xavier Pigeon, Expert méthode et stratégie Qualité & IT, auteur de gearsoftesting.org et fondateur de TestAsYouThink
- Florian Fesseler, Head of Engineering at iObeya
- Fatima-Zahrae Abbadi, Lead Quality Assurance Engineer chez Odigo
- Nicolas Guyon, Expert Test & QA, CI, DevOps and Agile deployment chez Murex
Dans cet événement, nous avons abordé les questions suivantes :
- Quelle est la vision et la perception actuelle du Quality Engineering?
- Quelles premières actions sont les plus pertinentes pour initier une démarche?
- Quelles démarches et pratiques actionner en transverse?
Contextualisation de l’événement
Le partage a démarré par un échange autour du Quality Engineering afin de mieux en cerner les contours.
Nous avons également partagé des points d’accroche entre la QA et le QE avant de passer à la phase pratique.
Chaque participant a pu lister les thèmes retenus ci-après.
Les challenges du Quality Engineering
Nous avons commencé par contextualiser quels challenges le Quality Engineering doit-il aider à résoudre.
Les défis se retrouvent balancés et alignés du métier vers la technique, et contre-intuitivement en dehors de la pratique pure d’ingénierie.
Apporter une qualité structurelle induit une perspective transversale du système, d’où l’importance du premier point de communication entre les diverses parties prenantes.
L’instabilité des besoins vient complexifier la capacité des acteurs à s’aligner sur une vision, nécessitant d’orienter la discussion sur des points plus stables, nous y reviendrons.
La tendance de fond du “anywhere, anyplace, anytime” est matérialisée dans la notion d’always-on complexifiée par la diversité des modèles de déploiements.
Le besoin de délivrer une expérience utilisateur utile, de qualité et régulièrement mise à jour est l’une des attentes clef du QE.
Antoine Craske
Ce besoin d’itération rapide implique en sous-jacent une expérience de développement fluide de bout-en-bout.
La capacité à mesurer la valeur apportée vient en support de la démarche, sans être uniquement basée sur des indicateurs de performance.
Les indicateurs peuvent effectivement être limités à une fin d’analyse qualitative des livrables.
On y retrouve également en fondation le besoin de se focaliser plus largement sur la valeur délivrée que sur le domaine technique d’intervention local.
Cette identification reste un vrai défi comme nous avons pour le partager dans cette table ronde.
Quelles différences entre la QA et le QE ?
Nous avons ensuite basculé sur l’articulation de la Quality Assurance (QA) et de la Quality Engineering (QE).
Intuitivement les deux pratiques partagent des fondations de gestion de la qualité, également applicables au domaine du logiciel.
J’ai trouvé les deux définitions suivantes permettant de faire émerger les perspectives respectives de chacun des domaines.
Comme toute définition, elles ont des biais d’interprétation, sont superficielles et peuvent manquer de contexte.
Néanmoins, je trouve intéressant de noter les mots ensure (garanti) et software development process, clarifiant la perspective transversale.
La QA est quant à elle limitée dans cette définition et fortement associée à un processus de contrôle à posteriori.
Comme dans une usine, la QA peut être uniquement en bout de chaîne, mais par un leadership et pro-activité s’inclure dans toute la chaîne de valeur.
Des diverses études récentes autour de la qualité logicielle, je prends parti que la QE est une branche évolutive de la QA, qui doit encore s’étoffer en matière.
Voici une compilation de perspectives du Quality Engineering.
Quels critères de succès de transition ?
Nicolas a lancé cette question, relevant la nécessité d’identifier les objectifs du management se cachant derrière l’amélioration de la qualité.
Nous avons retrouvé le mal souvent nécessaire d’une organisation de se retrouver face au mur pour prendre pleinement conscience de la situation, et réellement agir.
De manière plus précise : être face au mur et se rendre compte d’un n-ième fix par un développeur héroique ne peut plus résoudre la problématique.
J’ai partagé une expérience personnelle où nous avons été confrontés à cette situation. Notre premier objectif a été de livrer un petit changement le plus rapidement et sereinement possible.
Savoir livrer un changement simple la même journée sans organisation spécifique est un critère de succès du QE.
Antoine Craske
Cette démarche n’est pas évidente à convaincre d’un point de vue métier, car à court-terme on a le sentiment de ralentir, régresser, et d’accumuler du travail en attente.
Cela vous rappelle des lectures de démarches LEAN, de pratiques chez Toyota ou l’acronyme WIP (Work In Progress)?
C’est bien le cas en ajoutant donc cette brique de system-thinking et de LEAN pour du Quality Engineering structurellement efficace.
Quant aux objectifs Quality Engineering, ils doivent être orientés sur l’accélération, la stabilité et la qualité du court-terme au long-terme.
Le résumé des questions à se poser pour les critères de succès d’une transition vers le QE :
- Y a t-il des objectifs client et métier clairement identifiés?
- L’organisation semble être mature pour accepter un autre modèle de mesure de la valeur livrée?
- Quels éléments de contexte utiliser pour argumenter un besoin de changement, dès à présent?
Quelle place pour le CI/CD dans le QE?
C’est une bonne question, le CI/CD étant souvent associé au DevOps, il reste néanmoins lié à la qualité par le pattern de Quality Gates.
Notre échange nous a amené à identifier le CI/CD comme l’une des briques nécessaire dans une démarche de QE.
Elle reste à intégrer dans la démarche globale de par ses impacts multiples : culturel, organisationnel, processus, outils et maintenance.
Un CI/CD structurellement et organisationnellement fonctionnel revient à passer de l’artisanat à la petite usine.
Antoine Craske
Sur le volet culturel, le CI/CD requiert en partie une transversalité de la responsabilité de la livraison logicielle, de sa conception à son utilisation.
Abordé uniquement sous un aspect d’outillage, il risque de s’essouffler en plus d’apporter des contraintes et frustrations plus que la valeur métier initialement identifiée.
Une démarche CI/CD doit donc être posée dans sa transversalité :
- Quels problèmes cherchent-on à résoudre par l’automatisation des processus?
- Par quoi le CI/CD doit-il être complémenté pour résoudre les problèmes identifiés?
- Comment le CI/CD s’intègre t-il dans les processus, de bout en bout, et avec quels impacts?
La DoD ne se limite pas qu’aux User Stories
Xavier nous a partagé sa vision des Definition of Done (DoD), trop souvent limitée aux tâches de développement.
Les exemples de tâches autres ne manquent pas : correction de bug, organisation d’un sprint ou d’une release.
Chacune des DoD mérite donc d’être identifiée et définie dans les diverses tâches d’une équipe.
Ce diagramme d’écran radar de la DoD exemplifie bien les différentes typologies et niveaux de livrables.
On note les critères d’utilisabilité et de mesure du livrable, faisant le lien avec le besoin d’aligner les enjeux clients dans la démarche de Quality Engineering.
Concrètement pour votre contexte:
- Quelles sont les typologies de livrables les plus pertinentes à identifier?
- La DoD intègre t-elle les besoins d’automatisation, qualité jusqu’à son utilisation?
- Comment piloter sa réelle utilisation? Ces DoD sont-elles co-définies, partagées et automatiquement suivies dans un outil de gestion de tâches?
Quelles pistes pour acculturer les développeurs au Test?
Cette question a émergé dans un objectif de transversaliser l’adoption des tests en dehors de la QA.
Cette étape nous a semblé clef afin d’intégrer la qualité dans tout le cycle de développement et de livraison du logiciel.
Faire changer ses habitudes reste un défi pour des êtres humains.
Partager les enjeux, donner du sens, et expliciter en quoi cela va apporter de la valeur à la personne concernée est nécessaire.
Dans le cas d’un développeur, les tests doivent donc permettre, à minima, de livrer plus rapidement du code dont il est satisfait en qualité, tout autant que son client.
Dans un même temps, ces nouvelles possibilités doivent limiter les impacts négatifs sur l’existant et fournir une réelle valeur, au détriment d’être mis de côté.
Un développeur doit pouvoir avoir accès, utiliser et visualiser les différentes typologies de test.
Florian Fesseler
On retrouve la Developer Experience (DevEx) comme l’un des piliers du Quality Engineering, afin d’apporter de la valeur aux acteurs impliqués dans les processus.
Cette notion de plateforme nécessite en contrepartie de l’avoir prévue et intégrée en amont, sur un pattern de shift-left.
Des gardes-fous restent nécessaires sur les éléments structurants de la chãine, sécurisés par l’automatisation et complémentés par une gestion d’accès bien pensée.
Si l’équipe se pose cette question une fois que la livraison est en cours, il est probablement trop tard pour les itérations actuelles.
Les pistes possibles pour élargir les tests en dehors aux développeurs:
- Quels sont les objectifs attendus et en quoi contribuent-ils à l’objectif global?
- Quels use-cases et expérience sera fournie au développeur?
- En quoi cela change les habitudes existantes? Quels sont les apports, freins et limitations?
Le Quality Engineering doit fournir une plateforme aux différents acteurs
La valeur apportée par l’inclusion de la qualité dans tout le processus s’étend également aux autres acteurs du système.
À l’image de la QA, les équipes d’exploitation historiques doivent évoluer vers la mise à disposition d’une plateforme pour les développeurs.
Un exemple concret est par exemple de fournir le déploiement graduel (canary release, A/B testing, …) ou la supervision As A service.
Ces changements sont largement abordés dans le paradigme DevOps, il est intéressant d’en faire le parallèle pour les autres rapprochements nécessaires.
Le Quality Engineering vise une transversalité entre les différents acteurs, inspiré du DevOps, focalisé sur la qualité à l’échelle de l’équipe.
Antoine Craske
Quant aux équipes du Produit, elles doivent pouvoir itérer sur différentes fonctionnalités pour en juger la valeur pour les clients.
Cela implique par exemple que le développeur ait prévu la gestion de cette activation graduelle, et qu’il s’en préoccupe jusqu’en production.
En fondation, les équipes d’opérations doivent avoir permis l’utilisation d’un tel outillage par le développement.
Nous espérons également que l’application est correctement supervisée, peut-être complémentée par du test en production?
Les questions à se poser:
- Quels sont les acteurs collaborant autour du Produit sont susceptibles d’agir sur sa qualité?
- Quelles informations, use-cases et actions pourraient leur permettre de contribuer?
- Quelles organisations, processus et outils pourraient supporter les besoins identifiés?
Comment co-créer une stratégie de test
Une stratégie de test est trop souvent définie par une seule personne (indice: quelqu’un de la QA), manquant d’inclusion et d’alignement transverse.
Cela reste un vrai défi :comment impliquer le product management, architecture, développeur dans la définition de la stratégie de test?
Inspirée du Moving Motivators du Management 3.0, le jeu de carte “What’s My QA” de Florian Zilliox nous donne une piste d’animation.
L’exercice doit être réellement collaboratif et ludique dans sa préparation et animation afin de garantir une contribution équilibrée et avec intérêt.
Le processus consiste à préparer un jeu de cartes par participant, qu’ils devront chacun ordonner par priorité selon leur point de vue.
L’équipe partage ensuite leurs différentes perspectives pour ensuite réussir à aligner ses priorités pour sa stratégie de test.
Cette démarche – si correctement animée et supportée – présente certains avantages :
- L’inclusion des objectifs du métier et du client dans la stratégie de test
- L’amélioration de la collaboration par l’empathie créée entre les participants
- La matérialisation d’une dynamique transversale
Comment prioriser son effort de qualité?
Nous avons abordé le manque d’inclusion du contexte et objectifs métier des pyramides de test.
Elles restent utiles pour fournir un cadre des typologies de tests et leur possible priorisation dans un contexte donnée, historiquement de QA.
Le Quality Engineering ambitionne de fournir une intégration structurelle de la qualité dans tout le processus d’ingénierie logicielle, en partant du client.
Quels modèles pouvons-nous donc utiliser, tant pour la QA que le QE?
Xavier nous a partagé un modèle personnel, le Software Testing Quadrants qui recoupe certains points de la démarche de Lisa Crispin et Janet Grégory sur l’Agile Testing.
Le modèle a l’avantage de renforcer le besoin d’équilibre pour adresser structurellement la qualité.
On trouve une balance nécessaire entre la bonne construction du logiciel intégrant de base la durabilité, son acceptation et la réponse au besoin métier.
Les quatres quadrants matérialisent les différents objectifs du produit par la définition du ready, goal, success et done.
Je trouve intéressant de noter que certaines pratiques n’ont pas vocation à être automatisées, ce qui semble pertinent au vu de la maturité de l’écosystème actuel.
Ce modèle peut supporter l’exercice collaboratif de stratégie de test dans une démarche agile en sécurisant les points suivants:
- Adresse-t-on les différents prismes de la qualité dans notre priorisation?
- Avons-nous une définition claire pour chacun des blocs?
- Quel modèle organisationnel peut nous permettre de livrer les différents blocs?
Le Quality Engineering, une démarche de plateforme collaborative
Nos différents échanges ont remonté des points actionnables pour initier une démarche de QE.
Comme pour la QA, on retrouve le besoin d’aligner les objectifs de l’organisation et les critères de succès qui seront utilisés.
La performance de la transition doit être mesurée par étape et mérite une approche itérative et incrémentale par la complexité des acteurs et processus impliqués.
À l’instar du logiciel, une phase d’architecture et de conception sont nécessaires à des fondations évolutives et maintenables, intégrant en partie du CI/CD.
L‘objectif du QE étant de fournir une réelle plateforme, elle doit être orientée pour les différentes acteurs tels que les développeurs et au reste de l’équipe.
Enfin, la stratégie de qualité définie en collaboration permet d’aligner les différents acteurs, leurs objectifs et de matérialiser la transversalité nécessaire.
Contenus évoqués
Radar Screen of Definition of Done
https://gearsoftesting.org/tempo-of-testing.html#content4-2b
What’s my QA – exercice collaboratif de pyramide de tests
https://github.com/FlorianZilliox/whatsmyqa/blob/master/whatsmyqa.pdf
Test typology
https://gearsoftesting.org/test-typology.html#content4-2u
Article Quality Engineering, Accenture
https://www.accenture.com/us-en/insights/technology/quality-engineering-new
Agile Testing, Lisa Crispin & Janet Grégory
https://agiletestingfellow.com/
Moving Motivators, Management 3.0