La Table Ronde de la Quality Engineering Unit s’est réunie pour discuter de la transition de l’Assurance Qualité (QA) à l’Ingénierie de la Qualité (QE).

Le domaine du Software Quality Engineering  vise à inclure la qualité dans la transversalité des équipes , procédés et technologies de construction de produits.

Cependant, avoir un mot d' »ingénierie » ne veut pas dire qu’il s’agit de mettre en œuvre uniquement des outils.

Nous partageons les thèmes suivants:

• Quels thèmes pour une transition du QA au QE?
• Quelles pratiques peuvent être utilisées, avec quels points d’attention?
• Comment définir vos priorités?

Je remercie chaque participant pour sa participation et sa contribution:

• João Proença, Principal Quality Engineering chez Outsystems et International Speaker
• Diogo Rede, Engineering Lead & Test Engineer chez Farfetch
• Luis Bastião Silva, CTO chez BMD Software
• Filipa Nogueira, Engineering Team Lead chez La Redoute
• André Macedo, Architecte de solutions chez Sky Technology Center

Contextualisation de l’événement

Nous avons partagé en introduction avec João Proença autour du Quality Engineering, plus de contenu dans cet épisode.

Nous avons commencé l’événement en identifiant les sujets d’intérêt dans cette matrice de priorisation.

Luís Bastião Silva a entamé notre conversation sur la transversalité des risques.

La conscience des risques est essentielle

Connaissez-vous la règle de ne pas faire de release le vendredi?

De nombreuses expériences rapportent un week-end compliqué où cette règle n’a pas été respectée.

Cette règle relève du bon sens dans un écosystème complexe qui n’est pas encore au niveau de qualité attendu.

Pour préciser la question, toute l’équipe est-elle consciente des risques?

La conscience des risques est fondamentale à toute l’équipe, pas seulement celles d’opérations.

Luís Bastião Silva

Luis partageait que les risques appréhendés sont différents entre les équipes, ce qui aboutit finalement à de réels problèmes opérationnels.

Une matrice des risques, transversale, intervient dans ce contexte pour favoriser un partage des risques impliqués dans le processus de développement.

La question des risques doit devenir un réflexe de l’équipe au fil du temps.

Des points que vous pouvez évaluer dans votre contexte, partagés après :

• Êtes-vous personnellement conscient des différents risques dans la chaîne de valeur?
• Y a-t-il une formalisation de ces risques, avec priorisation?
• Comment définir, partager et animer votre utilisation avec l’équipe?

Avec le pouvoir de déploiement en production, vient la responsabilité

Qui est responsable de l’installation du logiciel de production dans votre organisation?

Pour des raisons historiques plutôt que techniques, on trouve souvent des opérations avec ce rôle.

Le problème n’est pas lié à l’équipe qui le fait, mais plutôt à qui est en première ligne à suivre.

Là aussi, les développeurs peuvent passer à côté, laissant ce travail à des équipes opérationnelles et de support en tant que premier contact.

Être responsable de bout en bout d’un produit est essentiel à sa qualité.

Diogo Rede

De nombreux bons arguments d’efficacité organisationnelle et de processus s’inscrivent dans ces modèles, tels que la séparation des préoccupations, les services partagés.

En retour, ils créent d’autres problèmes, comme un product owner ou un développeur qui n’a aucun retour direct sur l’utilisation réelle de son produit.

Nous partageons le besoin fondamental pour l’équipe d’avoir la boucle du retour d’utilisation en production, des utilisateurs aux couches les plus techniques.

Cela peut impliquer de revoir les processus et l’organisation.

Nous pouvons souvent trouver des solutions qui maintiennent les avantages des modèles et qui permettent cette feedback loop.

Ce que vous pouvez questionner dans votre contexte :

• Qui est aujourd’hui responsable de la mise en œuvre et du suivi du déploiement?
• Y a-t-il encore des raisons valables pour lesquelles le développeur n’y ait pas accès?
• Quels mécanismes de feedback automatiques peuvent-être implémentés?

Les risques sont présents au contact le plus proche du client

Nous sommes des êtres humains, nous adaptons nos comportements en fonction de l’expérience et souvent de retours émotionnels.

Par conséquent, afin d’améliorer la prise en compte des risques, l’équipe doit être en contact avec ceux-ci.

Les risques du logiciel se matérialisent dans son utilisation: fonctionnalités bloquées, dégradées, lenteur, perte de données, etc.

Comment obtenir ces informations?

Une équipe doit être aussi proche que possible de la production.

João Proença

Nous avons identifié ici un point d’observabilité du produit, un domaine à forte accélération due aux bénéfices qu’il peut apporter.

C’est également un parallèle au pattern de shift-right.

Cependant, jusqu’à ce que nos tableaux de bord soient automatiquement créés, optimisés et gérés avec Data Science, nous devons agir.

Une pratique concrète consiste à mettre l’équipe en contact avec le client, directement quand c’est possible, indirectement quand ce n’est pas le cas.

Nous avons eu des plaintes de lenteur, ce que l’équipe produit ne reconnaissait pas. Ils ont passé une semaine avec les utilisateurs et sont revenus avec des points d’amélioration.

Antoine Craske

Vous pouvez matérialiser cela des pratiques simples telles que placer des utilisateurs dans l’équipe produit, organiser des sessions avec un panel de bêta-testeurs, …

Les outils pragmatiques ne manquent pas pour enregistrer des écrans, accéder à l’analytique et des graphiques qui peuvent se concentrer sur des points d’utilisation particuliers.

Points à retenir dans votre contexte:

• Comment se matérialise le fonctionnement de mon produit?
• Qui sont les utilisateurs finaux? Quels sont leurs points d’interactions?
• Comment l’équipe pourrait-elle être plus proche des opérations et des utilisateurs?

Le Quality Engineering implique une responsabilité et un esprit d’équipe

Sentez-vous une équipe unie sur la qualité de votre produit?

C’est l’une des actions prioritaires à entreprendre avant d’entamer des changements de processus ou d’outils.

L’équipe doit se sentir comme une unité de la conception à l’exploitation du logiciel, en commençant à inclure le risque à tous les niveaux.

La responsabilité de la qualité est celle de l’équipe, pas seulement d’une seule personne.

João Proença

L’évolution de la réflexion et de la dynamique de l’équipe est souvent mise en arrière-plan.

En réalité, ils sont les fondements pour permettre à une équipe d’améliorer la qualité de son produit, en trouvant elle-même les meilleurs mécanismes transversaux.

Diogo Rede a partagé, par exemple, des cas dans lesquels l’équipe finit par atténuer les risques dès la conception avec des mécanismes tels que le features-toggle.

Des mécanismes d’atténuation doivent être identifiés en amont par l’équipe.

Diogo Rede

Avec la maturité, une équipe parvient à avoir une démarche d’amélioration continue basée sur les opérations du produit, dans laquelle elle itère sur des pratiques qualité.

C’est le résultat qu’il faut rechercher plus qu’une architecture technique parfaite à un moment donné.

Des questions que vous pouvez utiliser pour votre contexte :

• Quel est le niveau de transversalité de mon équipe aujourd’hui?
• Quelles interactions seraient les plus utiles à initier?
• Quels exemples et cas concrets puis-je utiliser comme premiers succès?

Commencer et livrer de la valeur comme première priorité

«Plus qu’un dernier détail et ce sera prêt».

Vous devez avoir entendu cette phrase plusieurs fois par la même personne pendant des jours, sans livrer quelque chose de fonctionnel.

Plusieurs facteurs entrent en jeu ici, la personnalité de la personne, la culture de l’organisation, les objectifs et la perspective qui ont été donnés au projet.

Obtenir un produit le plus rapidement possible et testable en exploitation est une priorité pour le Quality Engineering.

«Start Small», une transition vers le QE est un processus itératif.

João Proença

João a partagé le besoin de voir le QE comme un chemin incrémental et itératif, loin d’être un projet fixe.

Il faut expérimenter différentes techniques afin de développer ce qui fonctionne le mieux pour votre produit.

L’accent doit être mis sur la valeur générée, pas sur une optimisation technique dans un silo dans lequel on peut facilement s’isoler.

Ce que vous pouvez faire dans votre contexte:

• Quel est votre produit le plus simple qui apporte de la valeur à l’entreprise?
• Comment pouvez-vous le mettre en œuvre le plus rapidement possible?
• Comment permettre à l’équipe d’apprendre de la première expérience pour définir la prochaine itération?

Plus de qualité n’est pas uniquement plus de conception

Faut-il investir davantage dans la conception initiale pour inclure la qualité dans le processus?

C’est une possibilité et semble être du bon sens.

Cependant, contre-intuitivement, théoriser ne devrait pas être la première action à entreprendre.

Il faut se confronter à la réalité le plus rapidement possible.

Vous devez avoir le courage d’affronter la réalité, tôt.

Antoine Craske

Ce point se réfère au besoin de l’équipe d’être en contact avec les clients et le fonctionnement de leur produit tôt.

Elle s’applique également à la mise en œuvre de ses processus, technologies et outils qualité dans le cycle de vie du logiciel.

Concrètement, comment pouvez-vous vous confronter plus rapidement et plus régulièrement à la réalité, hypothèses et modèles dont vous disposez?

Quels tests prioriser pour le Quality Engineering

Nous avons commencé par aborder la question des typologies de tests à utiliser, avec quelle priorité et quel effort..

Luís a partagé son expérience où les tests de bout en bout étaient la première priorité qui a fini par apporter beaucoup de valeur à l’entreprise.

Dans le contexte en question, ils ont permis de valider que les principales fonctionnalités étaient stables dans le produit. 

Sans nécessairement trouver la source exacte du problème en question, ils apportent de la valeur à l’entreprise et à l’équipe.

L’adaptation au contexte et priorités du business est essentielle pour créer de la valeur.

Diogo Rede

Au fil du temps, ils ont été complétés par d’autres types de tests ayant des objectifs différents.

Les tests unitaires se sont révélés utiles pour améliorer la prise en compte des cas d’utilisation par des développeurs, et la modularisation de leur code.

Nous sommes d’accord sur l’erreur de vouloir tout automatiser, surtout lorsque le plan de test existe et provient de tests manuels.

Nous avons partagé que les pyramides de test sont des outils fournissant un cadre de réflexion sur les typologies de tests.

João a partagé que la pyramide est une métaphore, dans laquelle la granularité des composants à tester entre en compte.

Il ne faut pas tester en test bout-en-bout ce qui peut être testé sur uen couche inférieure.

João Proença

L’équilibre du coût et du bénéfice des tests inclut la perspective de valeur pour l’entreprise, obligeant à les formaliser.

Ce qui compte, c’est le risque réduit et à quel prix.

Comme nous l’avons partagé lors de la table ronde sur l’automatisation des tests, la quantité n’est pas la qualité, bien au contraire.

De plus, nous avons constaté que l’exécution des tests dès le début, que ce soit de bout en bout ou non, vous permet de valider rapidement l’ incorporation de la testabilité dans votre produit.

Une transition vers le QE est une dynamique transversale et incrémentale

Pour revenir à notre question initiale, «Du QA au QE, par où commencer?». Nous avons abordé plusieurs points.

La responsabilité transversale de l’équipe ayant accès aux opérations de votre produit est un prérequis.

Se concentrer sur la livraison d’un produit rapidement testable dans la réalité est l’une des clés de l’itération, que ce soit dans le logiciel final ou dans les processus de support.

La question des tests nécessite le même raisonnement: quelle est la valeur pour l’entreprise? Quel est leur ratio de coûts versus bénéfices? Quelle solution est la plus adaptée?

Lors de la mise en œuvre, le QE s’appuie sur les pratiques existantes, de l’assurance qualité et du DevOps, pour l’automatisation des tests ou du déploiement par pipeline, par exemple.

Les patterns du marché tels que le shift-left et shift-right se matérialisent également dans le Quality Engineering, tant organisationnellement que techniquement.

Pour votre réussite, votre transition vers le QE est une démarche qui doit être menée incrémentalement.