23 avril 2020
Par Frédéric Vaugeois, développeur en automatisation
Zentelia, firme de génie logicielle et expert en assurance qualité logicielle
Le Continuous Testing Report édition 2020, publié le 31 mars dernier, conclut que les entreprises doivent accélérer le passage au test continu des logiciels afin de rester compétitives. Rappelons que le rapport présente les résultats d’un sondage mené auprès de 500 principaux décideurs d’entreprises en Amérique du Nord et en Europe, d’octobre 2019 à janvier 2020. Autre constat important de ce rapport : la majorité des testeurs logiciels rencontrent des embûches dans leur travail. C’est d’ailleurs le contenu de mon article précédent : Testeurs logiciels, vous n’êtes pas les seuls à éprouver des difficultés! En contrepartie, le rapport propose des solutions que je vous présente par catégorie : l’utilisation de pratiques adéquates, l’optimisation ou l’orchestration des tests, et l’intégration de la formation et du développement des compétences en T au cœur des équipes de développement.
Utilisation de pratiques adéquates
Tout d’abord, il est à noter que les solutions de cette catégorie corrigent surtout les problèmes liés au shift left. En effet, c’est surtout en amont du processus de développement que les bienfaits se feront sentir. Par exemple, les auteurs du Continuous Testing Report 2020 proposent que les analystes d’affaires ne se concentrent pas nécessairement sur l’écriture des récits utilisateurs, mais plutôt sur la construction d’un flux basé intégralement sur les exigences des utilisateurs. En utilisant les modèles du système, comme un diagramme de flux de données, on limite les risques de mauvaise interprétation. Il s’agit là d’un conseil assez concret qui permet de minimiser le risque associé à l’interprétation des exigences. Ce conseil nous amène au point suivant : l’utilisation du MBT (Model-Based Testing).
L’optimisation et l’orchestration des tests en continu sont une solution à une multitude de problèmes que rencontre pratiquement toute entreprise qui commence à structurer ses tests logiciels. Cela se traduit souvent en une phrase : « on ne sait pas quoi tester! » Dans ces cas, les suites de tests sont inefficaces et redondantes, et on a de la difficulté à voir rapidement les effets de nos changements dans le code. Tout cela ralentit notre temps de réaction.
« Avec l’arrivée du mode agile, l’utilisation de schémas et de modèles a été un peu laissée de côté, alors que c’est le point d’entrée de toute application. »
L’utilisation de schémas système, de diagrammes UML ou de diagrammes de flux de données, par exemple, force la définition des entrants et des sortants attendus. Ainsi, le simple fait d’avoir recours à ces modèles nous permet de répondre à la question récurrente : « Qu’est-ce que je dois tester? ». La réponse se trouve directement dans le modèle et il s’agit là d’un très bon point de départ. De plus, il est primordial qu’au tout début d’un développement, chacun soit capable de comprendre le modèle initial et soit au fait du comportement que le système devrait adopter dans différents contextes. De plus, le rapport souligne à plusieurs reprises que ces pratiques ne sont absolument pas exclusives. Par exemple, le MBT fonctionne très bien avec le BDD (Behavior-Driven Development) ainsi qu’avec le TDD (Test-Driven Development). Ces méthodes, toutes très populaires en ce moment, incluent un lot de meilleures pratiques de développement qui sont très difficiles à maîtriser, encore plus si elles sont combinées. L’accompagnement d’un expert peut d’ailleurs faciliter l’intégration de ces techniques de façon moins risquée et plus efficace. Par conséquent, ces bonnes méthodes augmentent considérablement le contrôle sur le déploiement qui, à son tour, réduit l’introduction d’erreurs tôt dans le système.
Réduction du temps d’exécution
Optimisation et orchestration des tests
« Fort heureusement, il s’agit là de problèmes qui peuvent facilement être résolus au moyen d’une application d’orchestration utilisant l’intelligence artificielle. »
Effectivement, il n’est pas étonnant de voir que le deuxième élément le plus difficile à gérer par les entreprises est le maintien de suites de tests pertinentes. C’est normal : on ne veut naturellement pas avoir de mauvaises surprises et, pour éviter les problèmes, on se dit qu’il vaut mieux tout tester de façon exhaustive pour s’assurer que tout le code fonctionne. Cependant, en admettant qu’une mise en production ait lieu et qu’elle ne touche que l’API (couche de services), par exemple de la fonctionnalité liée aux finances (API Finances), et la base de données de l’application, l’optimisation de tests permettrait de dégager les tests minimaux qui devraient être exécutés pour s’assurer de la qualité de cette mise en production. Donc, on exécuterait uniquement les tests d’API et les tests de base de données. En admettant maintenant que seules l’API Finances et les tables qui lui sont associées ont été changées, on pourrait penser qu’il nous suffirait d’exécuter les tests qui sont directement associés aux changements en question. On pourrait alors rencontrer un problème de régression* qui pourrait survenir parce que cette partie de l’application n’est pas assez bien modularisée. On pourrait aussi rencontrer un problème si on ne teste pas l’API et la base de données en intégralité. Qu’est-ce qui arriverait si notre interface était, pour une raison obscure, complètement dépendante de la base de données? La réponse réside dans l’orchestration des tests de façon automatisée. * ISTQB, problème de régression (regression testing).
« Avec les avancées en apprentissage profond des dernières années, nous pouvons déjà commencer à voir apparaître des systèmes permettant de cibler les tests minimaux à exécuter selon les changements apportés, de prioriser les suites de tests, de quantifier leur risque et, par-dessus tout, de cibler et de supprimer les tests dupliqués. »
Naturellement, le temps d’exécution des tests sera considérablement réduit, puisque le système pourra être déployé plus rapidement et les erreurs pourront être détectées encore plus rapidement; c’est l’un des principaux objectifs. En analysant les données des sprints précédents, celles-ci peuvent être calculées et mises en évidence pour tous les acteurs. En priorisant les tests et en leur attribuant un facteur de risque, il devient encore plus facile d’annuler automatiquement un déploiement si un critère quelconque n’est pas respecté, ce qui permet de revenir à la version précédente (normalement plus stable) en quelques secondes.
Système d’orchestration avec l’IA
Voici ce qu’un système d’orchestration utilisant l’intelligence artificielle sera capable de nous procurer : • Un système de livraison continu qui automatise le build, l’analyse du code, les tests et l’analyse de ceux-ci en temps réel; • Des scripts de tests adaptatifs qui répondent aux changements des interfaces utilisateurs; • De la génération de données de tests en temps réel où les données d’intérêt sont disponibles sur demande; • Une gestion des défauts automatisée où un changement sera refusé si une mise en production est fautive; • Une surveillance continue du système avec de la validation et des health checks en temps réel. Ainsi, l’approche du Developer-Driven Release prend tout son sens : son impact sera beaucoup moins grand sur la production et si un problème majeur a lieu, le système reviendra automatiquement en arrière. Ainsi, le cycle de déploiement sera extrêmement court et il a été prouvé à maintes reprises qu’il s’agit d’une métrique extrêmement importante : plus le cycle est court, plus on a de contrôle. En contrepartie, il s’agit d’un système assez complexe à implanter et l’apprentissage profond est une technologie encore très jeune, mais les auteurs du Continuous Testing Report édition 2020 ont bon espoir que la technologie nous permettra bientôt de simplifier ce processus afin de répondre à tous les problèmes de visibilité de l’information. Par Frédéric Vaugeois, développeur en automatisation Zentelia, firme de génie logicielle et expert en assurance qualité logicielle