Vos utilisateurs attendent une expérience client à la hauteur du high-standard défini par les principaux acteurs. Offrir une expérience utilisateur de haut niveau nécessite une amélioration continue, ce qui explique le besoin d’une livraison logicielle plus rapide. Mais l’accélération s’accompagne d’effets secondaires d’une qualité dégradée sans des contre-forces mises en place.

Le paradigme du Quality at Speed est notre objectif. Nous devons fournir rapidement des modifications logicielles qui répondent aux exigences de qualité. Les tests de manière traditionnelle manquent de l’élément essentiel de rapidité, ce qui explique le besoin de tests continus dans un environnement de livraison continue.

Le monde du Testing a évolué de diverses manières : shift-left, shift-right, test en production, entre autres. Mais qu’est-ce qui change réellement avec les tests continus ? Que voulons-nous atteindre? Quels sont les impacts en pour les utilisateurs ?

Dans cet article, nous couvrons les vrais changements à venir avec le Continuous Testing :

• Favoriser un alignement à l’échelle de l’entreprise
• Atteindre le Graal du Continuous Shift-left et Shift-right
• La fusion du SDLC et STLC en feedback loops unifiées
• La visibilité à toutes les parties prenantes en continu
• Créer une valeur globale au lieu d’optimisations locales
• Pousser la Technologie à plus de self-service, intégration et intelligence

Le Continuous Testing représente un vaste ensemble de pratiques. La question des priorités se pose rapidement. La première valeur des tests continus est de pousser à un alignement à l’échelle de l’entreprise.

Le Continuous Testing favorise un alignement à l’échelle de l’entreprise

Le Continuous Testing est la conséquence naturelle de l’évolution des pratiques de qualité hors de leur silo naturel d’équipes de test et d’assurance qualité. Des tests continus seront considérés comme utiles en apportant de la valeur aux parties prenantes, d’où la nécessité d’un alignement transversal en première instance.

Une condition préalable à l’alignement des priorités du Continuous Testing est d’effectuer un exercice de Shift-Up & Spread . Cette pratique est partagée par Iman Benlekehal, illustrant la nécessité d’un alignement transversal entre les parties prenantes sur les attentes, les significations et les attributs de qualité. Une fois cet exercice effectué, nous pouvons nous concentrer sur la mise en œuvre du Graal du Continuous Testing, en fournissant les pratiques de test les plus pertinentes sur la chaîne de valeur logicielle.

Les pratiques de base restent essentielles, comme effectuer des tests dans des environnements de non-production, mettre en œuvre des tests automatisés, gérer la qualité du code. La principale différence avec le Continuous Testing est de les effectuer systématiquement, en prenant en charge des boucles de rétroaction rapides. Prenant l’exemple des tests automatisés, nous pouvons mettre en place une suite de tests pendant des semaines sans effectivement l’utiliser. Au lieu de cela, nous devons aligner notre flux de travail en flux tiré sur les petites modifications logicielles qui sont effectuées. De cette façon, nous pouvons fournir rapidement un retour sur le développement effectué, en s’ajustant directement si nécessaire. 

Si les pratiques de base sont essentielles, nous devons agir de manière transversale, en se déplaçant à gauche et à droite sur le cycle de vie du logiciel.

Atteindre le Graal du Continuous Shift-left et Shift-right

L’expansion de la qualité tout au long du cycle de vie du logiciel est identifiée par le Shift-left et le Shift-right. Pour le Shift-left, il s’agit d’agir en amont sur les exigences par exemple. Le Shift-right est plus étroitement lié à l’expérience utilisateur réelle en production.

Du point de vue Shift-left, le Continuous Testing nécessite de tirer parti de l’automatisation tout en travaillant dans des incréments de temps plus courts. Un exemple concret consiste à vérifier les cas d’utilisation en évaluant leur pertinence, leurs attributs de qualité et leur description. Nous pouvons tirer parti des pratiques BDD ou ATDD avec des contrôles automatisés pour le premier niveau de vérification, complétés par la suite par un examen humain. Au fil du temps, nous pouvons créer une meilleure bibliothèque de composants réutilisables, permettant des boucles de test continus plus rapides.

Nous passons au contexte Shift-Right lorsque nous nous concentrons sur l’expérience utilisateur, les opérations logicielles et le support. Les pratiques SRE tirant parti du monitoring sont un exemple simple de Continuous Testing ; nous effectuons toutes les 5 minutes une vérification des parcours utilisateurs. La différence avec le Continuous Testing est d’appliquer le paradigme de boucles de rétroaction plus fréquentes avec un large éventail de pratiques. Par exemple, un test de charge réalisé tous les 6 mois avant une grosse période de soldes est utile mais reste risqué. Que se passe-t-il si des problèmes structurels ont été ajoutés il y a 4 mois et qu’ils sont maintenant trop difficiles à changer ? C’est là que Continuous Load-Test peut nous aider à détecter plus tôt ce type de problème.

Par conséquent, le Continuous Testing nécessite des changements profonds du cycle de vie existant, à savoir la livraison de code et des tests logiciels.

La fusion du SDLC et STLC en feedback loops unifiées

Le cycle de vie de livraison de logiciel (SDLC) et le cycle de vie de test de logiciel (STLC) étaient traditionnellement deux processus distincts. Les logiciels se sont concentrés sur la spécification, la mise en œuvre et le déploiement du logiciel, tandis que les tests sur celui des tests. Le Continuous Testing change ce paradigme en boucles de rétroaction unifiées.

Atteindre le Quality at Speed exige à la fois une livraison rapide et de qualité. Les boucles de rétroaction unifiées permettent de répondre aux exigences de qualité tout au long de la chaîne. Le CI/CD avec des Quality Gates en est un exemple concret et à valeur ajoutée : les CI/CD issus du monde du logiciel sont complétés par des étapes de test automatisées tout au long du processus. On peut par exemple bloquer la pipeline dans un environnement de test pour des modifications logicielles ne répondant pas aux exigences de qualité attendues.

Un véritable changement à venir avec le Continuous Testing est l’inclusion d’étapes de qualité systématiques dans le processus de développement logiciel. Nos exercices précédents d’identification des pratiques de Shift-left et Shift-right sont utiles à cet effet. Nous pouvons hiérarchiser les incréments de test continu à plus forte valeur sur les étapes logicielles identifiées. Par exemple, nous pouvons ajouter des contrôles de sécurité sur le build ou au moment de l’exécution des applications. 

Lors de la mise en œuvre du Continuous Testing, les acteurs collaboreront plus étroitement sur une mission commune qu’ils doivent mesurer.

La visibilité à toutes les parties prenantes, en continu

Les approches de test traditionnelles ont tendance à optimiser le silo de l’assurance qualité avec un code ou des métriques de test spécifiques. Bien qu’une couverture de test puisse être une mesure de soutien utile, elle ne mesure pas la création de valeur dans une perspective plus large. Le Continuous Testing fait la différence, en donnant un retour continu aux différentes parties prenantes.

Les feedbacks sont la condition préalable à une adaptation plus rapide et plus efficace. La rétroaction continue que nous pouvons exploiter avec les tests continus est donc essentielle pour réduire le risque de perdre des efforts sur des activités sans valeur. Un aspect clé est de mesurer la bonne métrique pour le bon objectif. Les métriques de vanité comme le nombre de tests doivent être oubliées. Nous devons à nouveau revenir au processus Shift-up, où nous identifions l’impact attendu par nos parties prenantes.

La mesure continue amène la question supplémentaire du timing. Comme pour la tension artérielle ou la perte de poids, vous n’avez pas besoin de vérifier vos indicateurs chaque minute ou chaque jour. Dans le Continuous Testing, cela dépend de la métrique impliquée. Pour le SRE sur les parcours des utilisateurs, nous pouvons mesurer les indicateurs de service dans un intervalle de secondes tout en utilisant des graphiques de séries chronologiques pour une perspective analytique. 

Cette perspective partagée et globale apportée par le Continuous Testing crée l’habitude de mesurer l’impact global d’optimisations locales.

Créer une valeur globale au lieu d’optimisations locales

Lorsque vous démarrez le Continuous Testing, la première question est « Par où commencer ? ». Vous n’êtes plus limité à un environnement de test pour optimiser les tests automatisés. Par conséquent, le Continuous Testing aide les acteurs à avoir une image globale, contribuant à avoir un impact pour le client et l’organisation.

Cet impact global apporte un autre défi pour les acteurs de l’assurance qualité et des tests. Ils doivent embrasser un plus large éventail d’interactions pour fournir des éléments de qualité à valeur ajoutée. Ils doivent s’impliquer dans la gestion des produits, l’ingénierie, l’infrastructure et la plateforme. La liste des mots à la mode illustrant cette transformation vers le Continuous Testing est interminable : DevTestOps, BusOps, etc. En partageant de manière transversale, les priorités des acteurs seront plus alignées sur les objectifs globaux du système.

Une fois qu’un acteur de QA sort de sa zone de confort, il est confronté aux défis de la mise en œuvre de pratiques plus larges. Ce challenge est valable pour tous les acteurs du Continuous Testing ; comme l’équipe travaille de manière transversale pour augmenter l’impact de leurs activités, leurs pratiques ont évolué pour plus de transversalité. Un exemple concret est de passer du Site Reliability Engineering (SRE)  au Customer Reliability Engineering (CRE). Nous ne sommes plus uniquement concernés par les métriques du site ou du service ; nous regardons en amont du point de vue de l’utilisateur.

Le Continuous Testing apporte un dernier défi pour aider les acteurs à atteindre cette transversalité, celui de la Technologie.

Pousser la Technologie à plus de self-service, intégration et intelligence

Les boucles de rétroaction unifiées apportées par le Continuous Testing nécessitent rapidité et adaptation. D’un point de vue technologique, nous pouvons commencer par tirer parti du libre-service et de l’automatisation pour accélérer nos cycles-times. De plus, le paradigme unifié nécessite de composer les différentes technologies du logiciel et des tests pour fonctionner en harmonie. Enfin, des systèmes plus intelligents sont notre espoir pour l’outillage de demain.

Le libre-service est obtenu grâce à des processus automatisés matures. Nous étions habitués à travailler avec des processus papier, que nous avons ensuite transformés en systèmes d’information. À l’heure actuelle, un grand nombre de services standards sont disponibles en libre-service. Vous pouvez accéder à de nombreux services gouvernementaux à partir d’un portail par exemple. Nous avons les mêmes stades de maturité à atteindre en Continuous Testing. Par exemple, garantir le déploiement évolutif des Quality Gates nécessite une bibliothèque robuste de modèles et de connecteurs pour permettre à l’équipe d’ingénierie de les déployer de manière autonome.

L’interdépendance des technologies de test avec celles qui font partie de la chaîne de livraison de logiciels crée une pression pour la composition. Nous devons être en mesure de déployer rapidement une nouvelle activité de test au sein d’un processus existant, en quelques minutes. Dans le même temps, nous avons besoin d’un degré élevé de flexibilité pour adapter nos processus ; certains outillages peuvent devenir obsolètes, d’autres processus évoluent, etc. La capacité d’intégration des produits de test est donc structurante. Notre écosystème en évolution ne peut pas fonctionner de manière isolée avec verrouillage, provoquant l’obsolescence du système à moyen terme.

Le dernier impact du Continuous Testing sur la technologie est d’en faire plus avec moins d’efforts. Nous devons maximiser la valeur et la fréquence de la boucle de rétroaction. Du point de vue du système, la partie humaine est le facteur limitant. Nous pouvons automatiser les tests, le déploiement et l’observabilité production, mais les décisions les plus complexes que nous prenons restent pour les acteurs. C’est là que la data science peut nous aider en automatisant des matrices de décision complexes à grande échelle. Nous visons une automatisation maximale des étapes pour des boucles plus rapides.

En réalité, le Continuous Testing prend en charge les boucles d’apprentissage continu pour améliorer la proposition de valeur client.

Le Continuous Testing supporte la mesure continue de valeur utilisateur

Le mot test peut induire des erreurs pour les besoins de Continuous Testing. Nous ne parlons pas d’impacts de ou pour les tests. Notre objectif est d’accélérer le taux d’adaptation à valeur ajoutée pour l’expérience utilisateur et à la proposition de valeur.

Le Continuous Testing est une pratique qui s’inscrit dans le paradigme du Quality Engineering, contraignant la livraison de logiciels à la qualité. Nous pouvons analyser son impact sur le prisme du Quality Engineering Framework, MAMOS :

• Methods pour la mise en œuvre du paradigme de qualité totale à la livraison logicielle
• Architecture tirant parti du libre-service, automatisation, composition avec scalabilité
• Management conduisant les acteurs vers le high-standard et la livraison de valeur continue
• Organization permettant la composition d’expertise et collaboration efficace 
• Skills nécessitant plus de transversalité, d’apprentissage continu et de discipline

Il n’y a pas de fin, mais seulement un parcours d’amélioration continue pour atteindre et rester au high-standard.

Quelles seront vos premières feedback loops de Continuous Testing à plus forte valeur ajoutée ?