Qu’est-ce que les tests shift-left ?

Le cycle en V est un moyen pratique de conceptualiser les cycles de développement logiciel. Si l’on prend le flux en cascade traditionnel et que l’on retourne l’axe Y pendant la phase de mise en œuvre, on obtient un cycle en V.

Un cycle de développement commence par des exigences de haut niveau. Ces exigences sont réduites à chaque étape en descendant le « V », jusqu’à l’implémentation au niveau du code proprement dit. L’implémentation est ensuite vérifiée, en commençant par les tests unitaires les plus granulaires et en remontant le « V » jusqu’aux tests d’acceptation utilisateur, plus abstraits.

Dans un processus en cascade, l’ensemble du projet est composé d’un seul « V ». Dans notre secteur, on a compris qu’attendre la fin d’un projet complexe pour en valider tous les aspects conduisait inévitablement à l’échec.

Dans un processus itératif, on peut voir chaque sprint ou itération comme un « V » plus petit. Et les objectifs de test ont été théoriquement atteints, en testant plus tôt et plus souvent. Problème résolu, n’est-ce pas ? Pas vraiment.

Vous avez peut-être remarqué que le canal de retour d’information intégré au cycle en V comporte deux étiquettes : vérification et validation. Ces deux éléments ont chacun leur importance.

Il faut valider le fait que les exigences des utilisateurs résolvent réellement les problèmes que nous avons décidé de résoudre. Il faut également vérifier que notre implémentation correspond aux spécifications que nous avons obtenues de ces exigences utilisateur.

Les tests automatisés peuvent être appliqués à la fois aux validations et aux vérifications. Le BDD (« Behavior Driven Design » ou « développement piloté par le comportement » en français) a permis de créer des technologies telles que Cucumber, qui peuvent automatiser certaines parties du processus de validation. Pour les besoins de cet article, nous allons nous concentrer sur les tests de vérification automatisés.

Test unitaire

Les tests unitaires vérifient la fonctionnalité d’un module spécifique au sein d’une application plus importante. Le module est testé de manière isolée et toute communication avec d’autres processus externes est simulée. Les tests unitaires et le TDD (« Test-Driven Development » ou « développement piloté par les tests » en français) représentent la première phase de développement des tests shift-left.

Tests d’intégration

Les tests d’intégration ont pour objet de vérifier la fonctionnalité globale d’un service ou d’une application, effets secondaires inclus. Ce processus s’apparente à un anti-modèle pour des raisons que nous aborderons plus tard.

Tests d’API et tests sous contrat

Les tests d’API vérifient les points de terminaison externes d’un seul service. L’étendue des tests d’API est similaire à celle des tests d’intégration. Cependant, dans un contexte de SOA ou de microservices, il est possible de considérer les tests d’API comme de nouveaux tests unitaires.

Tests d’interface utilisateur

Les tests d’interface utilisateur vérifient la fonctionnalité complète d’une application à partir de la couche d’interface utilisateur. Des outils tels que Selenium rendent ces tests automatisés largement accessibles.

Bien plus qu’une simple automatisation

L’approche shift-left ne concerne pas seulement l’automatisation. Une autre façon d’effectuer des tests plus tôt et plus souvent est de s’assurer que vos spécialistes de l’assurance qualité sont impliqués à chaque étape de votre processus, en commençant par la découverte et la collecte des exigences. Les ingénieurs chargés des tests peuvent obtenir de meilleurs résultats lorsqu’ils ont une meilleure connaissance de l’implémentation dans son ensemble, et leurs observations peuvent contribuer à rendre l’architecture plus transparente et plus résiliente.

Lorsque l’on pense à tester « plus tôt et plus souvent », le mot « continu » nous vient immédiatement à l’esprit. Bon nombre d’équipes de développement logiciel (la plupart d’entre elles à vrai dire) pratiquent une forme ou une autre d’intégration continue et de distribution continue. Les tests continus constituent une boucle de retour d’informations essentielle dans ce cycle DevOps.

Tests continus

Si l’on considère le TDD comme un « décalage vers la gauche pour les monolithes », alors les tests continus sont un « décalage vers la gauche pour les architectures distribuées ».

Le TDD a fait concentrer les développeurs sur les tests unitaires. Pour les tests continus, il convient de se concentrer sur les tests d’API et sous contrats. Les tests API présentent de nombreux avantages :

• Les tests d’API permettent d’éviter l’une des façons les plus courantes d’introduire des erreurs au sein des applications de microservices, à savoir le fait de modifier une dépendance désynchronisée par rapport à ses services en amont ou en aval.

• Les tests d’API peuvent être effectués par la même équipe que celle qui possède le service.

• Les tests d’API évitent la fragilité associée aux tests sur les effets secondaires et les détails de l’implémentation.

Idéalement, ces tests d’API seront exécutés en continu sur les environnements de production et de pré-production. Les outils de test sous contrat peuvent contribuer à automatiser ce processus, mais cela nécessite une infrastructure supplémentaire.

Et s’il était possible d’utiliser les tests d’API continus intégrés à notre outil d’observabilité ? La prochaine fonctionnalité de tests d’API synthétiques d’Instana permettra d’exécuter des tests d’API en continu dans tous vos environnements en toute simplicité.

L’approche shift-left permet de rapprocher les activités de test du début du cycle de développement logiciel, afin d’obtenir un retour d’informations plus rapide et de réduire le temps et les efforts nécessaires à la correction des bugs. Voici quelques bonnes pratiques relatives aux tests shift-left dans le cadre du développement agile :

1. Implication précoce : Les activités de test doivent commencer le plus tôt possible dans le processus de développement. Les testeurs doivent être impliqués dès la phase de recueil des exigences afin de comprendre la portée du projet, les objectifs et les attentes des utilisateurs.

2. Collaboration et communication : Favorisez une collaboration et une communication étroites entre les développeurs, les testeurs et les autres parties prenantes. Encouragez les réunions quotidiennes, les sessions de planification de sprint et les rétrospectives régulières afin de garantir que tout le monde est sur la même longueur d’onde.

3. Automatisation des tests : Investissez dans l’automatisation pour effectuer des tests fréquemment et efficacement. Des tests automatisés doivent être créés en même temps que le processus de développement et intégrés dans les pipelines d’intégration et de déploiement continus. Cela permet de détecter rapidement les défauts, de réduire les problèmes de regression et d’accélérer les cycles de retour d’informations.

4. Développement piloté par les tests (TDD) : Encouragez la pratique du TDD, où les développeurs rédigent des scénarios de test avant d’écrire le code réel. Cette approche permet de définir le comportement souhaité et les résultats attendus dès le départ, ce qui permet d’obtenir un code plus robuste et plus facile à tester.

5. Intégration continue et distribution continue (CI/CD)  : Mettez en œuvre des pipelines CI/CD pour automatiser les processus de création, de test et de déploiement. Cette pratique garantit que chaque modification du code est testée de manière approfondie et déployée dans des environnements de production rapidement et fréquemment, réduisant ainsi le risque de problèmes d’intégration.

6. Tests shift-left : Envisagez d’intégrer les pratiques de test de sécurité dès le début du processus de développement. Réalisez des révisions de code de sécurité, une analyse statique du code et des tests axés sur la sécurité pour identifier les vulnérabilités et les corriger de manière proactive.

7. Tests exploratoires : Outre les tests automatisés, encouragez les tests exploratoires afin d’explorer l’application du point de vue des utilisateurs. Les testeurs expérimentés peuvent ainsi identifier les problèmes d’utilisation potentiels, les cas extrêmes et les scénarios que les tests automatisés sont susceptibles de manquer.

8. Tests de performance : Effectuez des tests de performance dès le début pour identifier les goulots d’étranglement potentiels et les problèmes d’évolutivité. Cela permet d’optimiser les performances de l’application et de s’assurer qu’elle répond aux critères de performance requis.

9. Environnements et données de test : Mettez à disposition des environnements de test qui ressemblent étroitement à ceux de production pour garantir le réalisme des tests logiciels. Veillez également à ce que des données de test suffisantes et représentatives soient disponibles pour simuler des scénarios réels.

10. Apprentissage et amélioration continus : Mettez en place une culture d’apprentissage et d’amélioration continus. Organisez régulièrement des réunions rétrospectives pour réfléchir aux processus de test, identifier les goulots d’étranglement et mettre en œuvre des changements afin d’améliorer l’efficacité des tests shift-left.

En mettant en œuvre ces bonnes pratiques, les équipes agiles peuvent améliorer la collaboration, accélérer le retour d’informations et améliorer la qualité des produits logiciels grâce aux tests shift-left.

Les boucles de retour d’informations plus courtes intégrées aux processus shift-left apportent plusieurs avantages. Les défauts peuvent être détectés plus rapidement, les correctifs peuvent être appliqués plus efficacement et les leçons apprises au cours d’une itération peuvent être appliquées dans la suivante, pour n’en nommer que quelques-uns.

Quelle que soit la méthodologie de gestion de projet ou la cadence de livraison de votre équipe, vous pouvez bénéficier des boucles de vérification plus courtes des tests shift-left.

Économies de coûts

Un défaut détecté par un test unitaire automatisé sur la machine locale d’un développeur coûte moins cher à identifier et à corriger. En effet, le coût de correction augmente lorsqu’un défaut se propage dans un environnement orienté client.

Bien-être des développeurs

Correctement réalisés, les tests automatisés et l’intégration continue apportent la confiance dont les ingénieurs logiciels ont besoin pour effectuer des déploiements fréquents, même les vendredis. Trouver les défauts plus tôt signifie moins de moments de panique. Dans la mesure où les lancements se font sans difficulté, il est aussi plus rapide et plus facile de corriger les quelques erreurs qui ont échappé aux développeurs.

Architecture résiliente

De même qu’un logiciel plus accessible est généralement plus facile à utiliser pour tout un chacun, un logiciel plus testable est généralement plus facile à analyser et à gérer. En envisageant de tester à un stade précoce, il est possible de mieux séparer les préoccupations et de renforcer la résilience de l’architecture globale.

Une meilleure qualité globale

Améliorer l’expérience client est notre objectif ultime. L’approche shift-left élimine certains incidents que les utilisateurs finaux peuvent rencontrer et réduit les répercussions des autres incidents. Il est possible d’utiliser l’observabilité pour compléter cette boucle de retour d’informations et améliorer l’état global des logiciels.

Avec les puissants outils d’automatisation à notre disposition, il peut être tentant d’implémenter tout type de test sur chaque ligne de code. Or, c’est une voie relativement périlleuse.

L’idée de tester les effets secondaires est intéressante : par exemple, cet enregistrement a-t-il réellement été consigné dans la base de données ? Mais tester les détails de l’implémentation est un anti-modèle car ces tests sont extrêmement fragiles. Il faudra peut-être les modifier à chaque changement apporté à votre application. Et comme l’interface utilisateur est également un détail de l’implémentation, il en va de même pour les tests d’interface utilisateur.

Les tests de vérification se concentrent uniquement sur le « quoi », et non sur le « comment » ou le « pourquoi ». Idéalement, les exigences des utilisateurs ont pour but de valider le « pourquoi ». Pour répondre au « comment », il est possible de s’appuyer sur une automatisation plus puissante sous la forme d’une plateforme d’observabilité.

Les tests shift-right consistent à effectuer des tests plus tard dans le processus de développement, généralement dans des environnements de production. Bien que cela puisse paraître étrange, les tests shift-left et shift-right sont complémentaires.

Les tests shift-right permettent d’identifier les problèmes de production avant que les clients ne le fassent. Les boucles de retour d’informations plus courtes des tests shift-left permettent de répondre et de remédier rapidement à ces problèmes de production.

Utiliser les tests d’API synthétiques sur une plateforme d’observabilité est le moyen idéal de combiner les avantages des pratiques shift-left et shift-right.