Le domaine de la Quality Assurance évolue plus ou moins rapidement dans sa transversalisation dans les organisations.
Parler de « coach agile » ou de « test enabler » devient monnaie courante pour des rôles de qualité autrefois inspiré du contrôle qualité de l’industrie.
Une qualité uniquement en bout de chaîne, a posteriori a mainte fois montré ses limites et difficulté à s’intégrer au produit.
En parallèle, le mouvement DevOps s’est largement divulgué dans l’écosystème.
Même s’il reste souvent perçu comme un sujet particulièrement technique, ses aspects culturels, d’organisation et conduite du changement sont les plus clefs à adresser.
Au croisement de l’Agile, de la Developer Expérience et de l’automatisation à l’échelle, le platform engineering supporté par une équipe transverse émerge comme un modèle performant.
L’émergence du Platform Engineering
Nous pouvons retourner la problématique en se demandant : que se passe-t-il sans platform engineering?
Chaque équipe résoudra en silo, en parallèle et probablement différemment des problématiques similaires.
On déploie des services manquant d’interopérabilité, d’évolutivité et de maintenabilité.
Imaginez-vous à tenter d’intégrer des systèmes sans standard d’intégration, avec des environnements, headers d’APIs ou de gestion d’autorisations différents.
Ces types d’impacts restent limités à petite échelle, et grandiront avec la croissance de l’organisation.
Les points les plus structurants menant à une démarche de Platform Engineering sont :
- Le besoin d’accélération et de scalabilité organisationnelle
- La capacité à intégrer les technologies complexes
- La maîtrise des coûts nécessaires à une croissance rentable
Tout comme un produit digital aux mains des clients, les différents acteurs peuvent accéder à une plateforme supportant l’automatisation, le self-service, etc.
La plateforme se retrouve souvent supporté par une équipe dédiée, au service des autres équipes.
Figure 1 : Un exemple d’équipe de Platform Engineering https://wichon.com/platform-engineering
Mais qu’en est-il de la QA ?
L’horizontalisation des interactions et l’accélération des rythmes de livraisons poussent également la QA à se réinventer.
Pour assurer son impact dans l’écosystème de livraison logiciel, ne doit-elle pas également évoluer en transversalité, fournissant des services aux différents acteurs ?
Le manque d’inclusion de qualité dans les différentes étapes du processus est un point de difficulté souvent remonté.
Même si nous partageons sur le BDD, le Test en Production, les pratiques se retrouvent rarement intégrées au cycle de développement.
Nous devons apprendre et accélérer en apprenant de la maturité des autres disciplines.
La valeur apportée par la qualité sera augmentée par sa transversalité et impact global dans l’organisation et ses chaînes de valeur.
On veut idéalement atteindre un Quality Built-in piloté et animé par les différents acteurs : Product owner, développeur, testeur, etc.
C’est pourquoi je suis convaincu que structurer une démarche de Quality Engineering avec une vision de plateforme, peut permettre d’augmenter l’impact de la qualité dans l’organisation.
Au-delà d’une perspective de Developer Expérience et de Developer Productivity, la qualité doit assurer que la valeur métier délivrée est bien celle attendue pour les clients, tout en fournissant un système productif en support.
On parle donc plutôt de Business Quality Engineering et d’Engineering Productivity.
La qualité doit-elle donc faire le travail de tout le monde ?
C’est une possibilité mais qui ne sera ni pérenne ni scalable, comme l’écosystème DevOps s’en est aperçu.
Un goulot d’étranglement finira par se matérialiser et la qualité sera réduite.
En alternative, la qualité peut se voir positivement, comme fournisseur de services à valeur ajoutée pour les différents acteurs.
Contre-intuitivement, c’est cet investissement sur une plateforme qui permet aux acteurs de la qualité de passer plus de temps en collaboration avec leurs utilisateurs.
Elle doit, à l’instar du DevOps, automatiser les tâches et demandes répétitives, permettant d’en améliorer leur performance et scalabilité.
La qualité ne doit donc pas faire le travail de tout le monde, mais doit réussir à intégrer les différentes dimensions de la qualité dans les processus de l’organisation.
Peut-on parler de Quality Engineering Platform ?
Je suis convaincu que c’est une piste intéressante d’explorer et de vérifier par des expériences concrètes.
Analysons certains cas d’usages d’une telle plateforme et quelle en serait sa différentiation.
En amont des cycles de développement, on retrouve le besoin d’identifier les différences exigences, qu’il faut ensuite aligner en vérifications.
Pour les use-cases, on aimerait pouvoir les valider automatiquement avec du BDD. Pas uniquement entre le product owner et le testeur, mais les rendre disponible au développeur dans ses itérations de développement.
Une fois en production, nous aimerions également que les use-cases principaux soient supervisés.
Ces besoins sont souvent répondus par des processus manuels et semi-automatiques en silos.
On aligne des use-cases avec des tickets de développement, en intégrant du BDD aux tests manuels et par chance, un framework BDD pour le développeur.
La partie supervision en production restera aux mains des opérations, jugé un peu trop technique pour le métier.
N’est-ce pas ces processus que la qualité cherche à y être systématiquement intégrée ?
Les services qu’une plateforme de qualité peut disponibiliser
Les services doivent répondre à plusieurs exigences.
Ils doivent être disponibles en self-service, automatisés tout en répondant aux besoins de sécurité, traçabilité, performance.
Aujourd’hui, il est possible de fournir les premières bribes de cette plateforme.
Systématiser des quality gates dans les templates de pipelines de CI/CD est une première étape.
On peut ensuite ajouter des tests dès le déploiement en production, qui seront complémentés par de la supervision des parcours utilisateurs identifiés par leur use-case.
Demain, nous pouvons envisager de fournir des services à plus forte valeur ajoutée et de maturité, à l’instar du chemin fait dans le DevOps.
Nous pourrions permettre au Product Owner de choisir les customer journeys qu’il souhaite superviser, et comment en être notifiés.
Le développeur pourrait activer la bi-synchronisation du référentiel des cas de tests avec ses cas de BDD locaux.
Pourquoi pas intégrer du crowd testing automatiquement via des APIs à chaque livraison, ouvrant les tickets nécessaires et notifiant les équipes ?
La qualité requiert une Quality Engineering Platform pour accélérer son impact
Ma conviction est que la qualité doit évoluer dans l’automatisation et la mise à disposition de services.
Cela revient à architecturer une réelle plateforme autour des besoins des différents acteurs de l’écosystème.
Cette plateforme sera en support des différentes phases du projet, de la définition du besoin jusqu’aux opérations.
L’écosystème de qualité sera de plus en plus intégré dans l’écosystème technologique, suivant les avancées réalisées pour le développement logiciel et le DevOps.
Cette maturité croissante est ce qui permettra une meilleure interopérabilité et mise à disposition de services par une plateforme de QA.
Une plateforme, qui aura pour but ultime ne l’oublions pas, de permettre une meilleure collaboration des acteurs.