Bienvenue dans cette deuxième partie de l’article. Je suppose qu’à ce stade, vous pouvez commencer à automatiser les tests, vous être heurté à un mur ou ressentir des signes avant-coureurs de la dette de test.

Nous passons maintenant à la création et à la maintenance de tests automatisés à valeur ajoutée. C’est un véritable défi dans les écosystèmes et les organisations dynamiques où la valeur de l’automatisation des tests n’est pas nécessairement partagée. C’est là qu’entre en jeu le Quality Engineering contraignant le système à la qualité.

Cet article partage les éléments clés de l’ingénierie de la qualité qui seront bientôt publiés dans l’ebook (plus d’informations en fin d’article). Il explique comment appliquer l’architecture, les méthodes, l’organisation, les compétences et la gestion pour l’automatisation des tests, en illustrant les principaux avantages.

Ces pratiques sont issues de notre table ronde « Forget Test Debt : Build Test Automation Wealth ». Je remercie chacun des participants pour leur participation et leur contribution :

• Joel Oliveira, Software Testing & Quality Assurance Evangelist, Public Speaker, Trainer, Senior Program Manager, Independent Consultant
• Rafael Amaral, Senior Software Engineer in Test chez Farfetch
• Filipa Nogueira, Engineering Team Lead chez La Redoute

Commençons par définir la valeur de l’automatisation des tests.

Suivez la QE Unit pour plus de contenu exclusif de Quality Engineering.

Quelle valeur pour l’automatisation des tests ?

L’automatisation des tests est pertinente quand elle consiste à créer de la valeur. C’est la définition de la qualité d’être une valeur pour quelqu’un qui compte, comme l’a déclaré Michael Bolton. Précisons-le dans le cadre du logiciel.

La valeur de l’automatisation des tests ne réside pas dans les tests eux-mêmes ; il s’agit des impacts sur les objectifs globaux au sein de l’organisation. Il faut donc prendre du recul du seul point de vue du test : que peut-on apporter au périmètre global de l’ingénierie ? Plus important encore, que pouvons-nous apporter à l’entreprise ? Il est important de regarder plus largement. Nous pouvons délivrer de la qualité sans tester. La qualité, c’est aussi maximiser les résultats avec le moins d’efforts, d’où la nécessité d’éliminer les déchets, ou waste.

La valeur de l’automatisation des tests est définie par les parties prenantes : vos utilisateurs, votre entreprise et les équipes informatiques. L’automatisation des tests est généralement appréciée pour améliorer l’expérience utilisateur, même en production tirant parti du SRE et de l’observabilité. Cela peut également signifier une meilleure proposition de valeur au plus tôt pour vos utilisateurs en permettant des cycles plus rapides des modifications logicielles. Les métriques d’Accelerate sont des indicateurs de support que vous pouvez utiliser comme référence. Les questions sont puissantes pour mieux prioriser les attentes : essayons-nous de réduire le risque ? Gagner confiance en nos livraisons ? Augmenter la fiabilité ?

La valeur à délivrer est donc contextuelle, s’appuyant sur vos parties prenantes et s’appuyant sur des références extérieures. La compréhension partagée que vous pouvez créer est déjà une richesse en rationalisant les activités sur les bonnes priorités. Une erreur courante de l’automatisation des tests est de faire le mauvais parallèle avec l’argent. Pour les tests automatisés, nous n’en avons pas toujours besoin de plus. Less is more (c’est aussi un débat pour l’argent, hors du cadre de cet article).

Définir la valeur est une première étape. Le prochain est de le traduire en réalité.

Architecturer la valeur de l’automatisation des tests

Nous connaissons les objectifs et les priorités communs des exercices précédents. Cependant, nous ne savons pas nécessairement comment traduire efficacement les exigences dans notre plan d’automatisation des tests. C’est le but de l’architecture, transformer les idées en réalité.

Notre première action est de définir le quoi, puis de prioriser son périmètre. Le Quoi concerne généralement les cas d’utilisation les plus utiles à décliner en techniques de test adéquates. Certains tests seront d’ailleurs plus pertinents si exécutés manuellement ou pas du tout. Cette étape est importante pour fixer ce type de choix. À ce stade, vous pouvez penser « Et les pyramides de test ? ». 

Les pyramides de test sont des modèles largement connus pour divers fins. Elles nous aident à comprendre les différentes couches de tests que nous pouvons effectuer. De plus, ils peuvent aider à définir les priorités d’automatisation des tests. Il faut être prudent à ce stade car votre pyramide d’automatisation de tests peut être différente des pyramides génériques. Les pyramides de test manquent également d’un élément essentiel, les priorités du business.

Vous pouvez dire de manière générique d’utiliser le niveau le plus bas possible pour un test particulier. C’est un bon raisonnement. Mais n’oubliez pas les objectifs métier et votre contexte. Un raccourci est de se concentrer largement sur les tests unitaires étant plus rapides, plus locaux, etc. Mais dans des contextes particuliers, votre priorité sera sur l’expérience utilisateur, et vous n’aurez peut-être pas un triangle parfait.

C’est le but, utiliser des modèles et des guides sans oublier de voir la situation dans son ensemble et avec bon sens. L’activité suivante consiste à concevoir la mise en œuvre par des incréments réalistes.

Définir les méthodologies d’automatisation des tests

La réalisation des activités peut être améliorée avec des méthodologies, maximisant les résultats et minimisant les efforts. Nous soulignons ici les méthodes clés pour appliquer le Quality Engineering à l’automatisation des tests.

Les méthodologies Agile, Pareto et LEAN sont utiles à considérer à ce stade. Vous ne pouvez pas tout planifier, mais vous pouvez organiser pour réagir à l’incertitude. Une approche pragmatique consiste à travailler par incréments sous délais fixés, en priorisant par la valeur. Les rituels agiles et lean peuvent ensuite être mis à profit pour la planification, la résolution des problèmes et les rituels de rétrospectives. 

Nous pouvons déjà nous sentir prêts à démarrer le prochain sprint. En prenant du recul par rapport à notre expérience de dette de test, « il s’agit des décisions que nous prenons et ne prenons pas ». Pour anticiper l’effet des boucles de feedback retardées, nous devons clarifier l’effort de maintenance des tests dès le départ. Cela signifie concrètement allouer du temps pour l’optimisation, la refonte et peut-être la suppression (nous en parlerons plus tard) des tests. Le temps alloué doit être à la fois défini et limité pour contenir l’entropie.

Notre architecture d’automatisation des tests est correcte mais doit s’intégrer globalement. Le prochain domaine est l’architecture de l’organisation.

Architecturer l’organisation pour soutenir la livraison de valeur

Les tâches d’automatisation des tests seront menées à bien par les acteurs faisant partie d’un système plus large. Il est donc important de s’assurer que le contexte organisationnel favorise l’atteinte des objectifs. Il s’agit également d’éviter la dette et le gaspillage.

Le premier élément concerne l’ajustement de l’architecture technologique. Votre travail sur la conception de l’automatisation des tests s’est davantage concentré sur les adhérences internes et directes. Il faut ici prendre du recul sur l’écosystème IT global, en interne et externe, pour réduire les risques de surprises d’intégration. Nous devons à nouveau agir en tant que poseur de questions car la connaissance est plutôt hors de notre portée. La pipeline de CI/CD standard est-il viable ? Qu’en est-il de l’évolutivité de l’infrastructure ? Quelles en sont les limites ? Peut-on faire des tests en production ? Quelle est la taille des environnements de pré-production ?

C’est le type de questions que vous devez utiliser pour valider ou invalider vos hypothèses. Changer un plan sur le papier est relativement facile, même si frustrant. C’est bien mieux que de se heurter à un mur pendant l’exécution, perdant ainsi l’investissement précédent. Une pratique clé pour limiter le niveau de risque est celle des itérations rapides de bout en bout. Ainsi, vous pouvez vérifier rapidement l’intégration transversale en mettant en place plus tôt des fondations réutilisables. L’architecture suivante concerne celle des acteurs.

La conception organisationnelle soutient la réalisation d’une mission partagée par un groupe d’acteurs, appelé équipe, lorsqu’ils collaborent pour des objectifs communs. La loi de Conway clarifie l’impact de l’organisation sur le système de collaboration qui en résulte. L’architecture de l’organisation est essentielle à la fois pour assurer la livraison de tâches spécifiques et pour soutenir l’architecture technologique que nous avons conçue. L’équipe peut être organisée pour deux optimisations : flux ou ressources. L’orientation flux est la plus appropriée pour l’automatisation des tests en cours de sprint qui prendra en charge les boucles de rétroaction rapides des modifications logicielles.

Les processus sont les conditions préalables à des interactions efficaces.

Les interactions au cœur de la performance organisationnelle

Les interactions des acteurs nécessitent également une organisation par des processus, appelés aussi méthodologies. Nous couvrons déjà certains d’entre eux avec l’Agile et le Lean. Nous avons identifié les processus spécifiques nécessaires pour créer une richesse d’automatisation des tests. La première consiste à définir une Definition of Done partagée, comprenant les étapes spécifiques pour l’automatisation des tests. Il ne s’agit pas nécessairement d’automatiser chaque use-case. Le plus important est de s’interroger systématiquement sur sa pertinence et sa valeur. Des questions complémentaires devraient être ajoutées comme celle de la maintenance, l’optimisation ou la suppression de tests particuliers.

La culture a également un impact sur le comportement de l’acteur. Nous n’aborderons pas le thème dans cet article. Les lignes directrices générales de « le test est de la responsabilité de tous » sont superficielles sans en détailler sa justification et mise en musique. Les différents éléments que nous identifions ici favorisent une mission et une culture partagées. Les responsabilités nécessitent toujours un minimum d’affectation pour une clarté des attentes et des rôles entre les acteurs. La qualité des interactions contribue également à la qualité du travail effectué. Les activités de revues par les pairs sont donc essentielles.

La dernière partie, qui ne vient pas en dernier dans l’exécution, est de sécuriser les compétences humaines et d’automatisation des tests. Les contributeurs réels à ces tests sont les plus prioritaires. Les parties prenantes secondaires participeront activement lors des sessions collaboratives. Les compétences signifient que du budget et du temps doivent être alloués, idéalement avec une approche continue. Apprendre, c’est pratiquer et nécessite du temps. Il s’agit rarement d’un effort one-shot. Le contournement de cette étape peut entraîner des copier/coller de divers forums, loin de devenir des tests automatisés à valeur ajoutée.

La réalité ne suivra qu’une mise en œuvre effective.

Agir, mesurer et s’adapter avec le Quality Engineering

L’automatisation des tests avec le Quality Engineering est un processus itératif reposant sur la livraison, la mesure et l’adaptation incrémentale. C’est là qu’il est utile de savoir quoi et comment détecter les signes avant-coureurs de la dette de test.

Le principal moteur de nos actions doit rester aligné sur la définition commune du pourquoi et de la valeur avec les parties prenantes. Notre travail consiste à combler en permanence cet écart de valeur. La valeur doit être mesurée pour assurer l’impact de nos actions et en permettre sa communication.

Les risques et les incertitudes font partie du jeu ; il n’y a pas de raccourci. Les méthodes sont importantes pour suivre un processus structuré. L’écosystème est un monde en perpétuelle évolution dans lequel nous devons naviguer.

L’automatisation des tests avec le Quality Engineering cible à combler un écart de valeur communément défini, où les tests automatisés font partie de la création de valeur globale. Il ne s’agit pas d’accumuler le maximum de tests, de tomber dans les pièges des métriques de vanité.

Au passage, supprimez les tests sans valeur.