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

Avez-vous déjà participé à un projet logiciel qui a dépassé son budget et pulvérisé toutes ses échéances ? Bien sûr que oui. Cela nous est arrivé à tous. En réalité, si ce n’est pas votre cas, vous êtes une licorne et j’aimerais beaucoup entendre votre témoignage.

Au début de ma carrière dans le développement logiciel, j’ai appris l’importance de partir d’une échéance et de remonter dans le temps. Lorsqu’un projet doit être terminé à une date donnée et que les tests prennent un certain temps, ces informations permettent de remonter le calendrier afin de définir la date à laquelle notre projet doit être achevé. Parfait, non ?

Eh bien, pas tout à fait. Prévoir du temps pour les tests manuels permettait de réduire une partie du stress pendant les derniers jours des projets, mais il restait encore beaucoup trop de mauvaises surprises.

Prévoir du temps pour les tests d’assurance qualité est une excellente idée en théorie, mais celle-ci s’effondre rapidement en pratique dès que le premier bug ou défaut est détecté.

Combien de temps faudra-t-il pour corriger ce défaut ? Quel sera son impact sur le calendrier ? La correction introduira-t-elle de nouveaux bugs ? Comment nous assurer que chaque correction est vérifiée, tout en conservant suffisamment de temps pour réparer les éventuels problèmes créés en tentant de résoudre le problème initial ?

Au bout du compte, je n’ai jamais réussi à déterminer la durée adéquate à consacrer à l’assurance qualité. Inévitablement, des correctifs réalisés dans l’urgence étaient fusionnés à la dernière minute. J’ai appris à ne rien prévoir dans mon calendrier pendant les deux semaines suivant les lancements importants. Cette approche me permet de trier et de traiter les problèmes que nous avons manqués (ou introduits) pendant notre course effrénée vers la ligne d’arrivée.

En définitive, le problème ne résidait pas dans le temps disponible pour effectuer les tests, mais dans le moment auquel ceux-ci étaient réalisés. J’avais besoin de tester plus tôt et plus souvent. J’avais besoin des tests shift-left.

Si nous imaginons notre processus de développement logiciel comme une chronologie allant de gauche à droite, l’expression « shift-left testing » devient explicite. Pour faire simple, il s’agit de tester les premières étapes du processus et de faire participer les différents membres de l’équipe, notamment les testeurs, les développeurs et les parties prenantes, à la stratégie de test. Cette approche consiste également à intégrer plus fréquemment, tout au long du cycle de développement, les tests portant aussi bien sur les fonctionnalités existantes que sur les nouvelles fonctionnalités.

Le modèle en V constitue une façon utile de conceptualiser les cycles de développement logiciel. Si nous prenons le flux traditionnel du modèle en cascade et que nous « retournons » l’axe Y au niveau de la phase d’implémentation, nous obtenons le modèle en V.

Un cycle de développement commence par des exigences de haut niveau. Ces exigences sont progressivement affinées à chaque étape de la descente du « V », jusqu’à atteindre l’implémentation au niveau du code. Nous vérifions ensuite cette implémentation, en commençant par les tests unitaires les plus granulaires, puis en remontant progressivement le « V » jusqu’aux tests d’acceptation utilisateur, plus abstraits.

Dans un processus en cascade, l’ensemble du projet est constitué 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, nous pouvons considérer chaque sprint ou chaque itération comme un « V » de plus petite taille. En théorie, nous avons ainsi atteint nos objectifs de shift-left : tester plus tôt et plus souvent. Problème résolu, non ? Eh bien, pas tout à fait.

Vous avez peut-être remarqué que le canal de rétroaction intégré au modèle en V comporte deux libellés : vérification et validation. Ces deux notions sont importantes.

Nous devons valider que les exigences des utilisateurs permettent bien de résoudre les problèmes auxquels nous cherchons à répondre. Nous devons également vérifier que notre implémentation correspond aux spécifications découlant de ces exigences utilisateur.

Les tests automatisés peuvent être appliqués aussi bien aux activités de validation qu’aux activités de vérification. La conception pilotée par le comportement (BDD) a conduit à la création de technologies telles que Cucumber, qui permettent d’automatiser certaines parties du processus de validation. Dans le cadre de cet article, nous nous concentrerons sur les tests automatisés destinés à la vérification.

Les tests unitaires vérifient le fonctionnement d’un module précis au sein d’une application plus vaste. Le module est testé de manière isolée et toute communication avec d’autres processus externes est simulée ou remplacée par des objets factices. Les tests unitaires et le TDD représentent la première phase de développement des tests shift-left.

Les tests d’intégration tentent de vérifier le fonctionnement global d’un service ou d’une application, y compris ses effets secondaires. Ce processus s’apparente à un anti-modèle, pour des raisons que nous aborderons plus loin.

Les tests d’API vérifient les points de terminaison externes d’un service donné. La portée des tests d’API est similaire à celle des tests d’intégration. Toutefois, dans le contexte d’une architecture orientée services ou de microservices, nous pouvons considérer les tests d’API comme les nouveaux tests unitaires.

Les tests d’interface utilisateur vérifient le fonctionnement complet d’une application à partir de sa couche d’interface utilisateur. Des outils tels que Selenium rendent les tests automatisés d’interface utilisateur largement accessibles.

Le shift-left ne se limite pas à l’automatisation. Une autre façon de tester plus tôt et plus souvent consiste à veiller à ce que les spécialistes de l’assurance qualité participent à chaque étape du processus, dès la phase d’exploration et de collecte des exigences. Les ingénieurs de test peuvent travailler plus efficacement lorsqu’ils comprennent mieux l’implémentation dans son ensemble, et leurs observations peuvent contribuer à rendre l’architecture plus ouverte et plus résiliente.

Lorsque nous pensons au fait de tester « plus tôt et plus souvent », un mot précis nous vient à l’esprit : continu. De nombreuses équipes de développement logiciel, pour ne pas dire la plupart, pratiquent une forme ou une autre d’intégration continue et de livraison continue. Les tests continus constituent une boucle de rétroaction essentielle dans ce cycle DevOps.

Si nous considérons le développement piloté par les tests (TDD) comme une forme de « shift-left pour les monolithes », les tests continus constituent alors le « shift-left pour les architectures distribuées ».

Le TDD nous invitait à nous concentrer sur les tests unitaires. Dans le cadre des tests continus, nous devons nous concentrer sur les tests d’API et les tests de contrat. Les tests d’API présentent plusieurs avantages :

• Les tests d’API permettent d’éviter l’une des causes d’erreur les plus fréquentes dans une application fondée sur des microservices : la modification d’une dépendance sans synchronisation avec les services situés en amont ou en aval.
  
   

• Les tests d’API peuvent être pris en charge par l’équipe responsable du service concerné.
   

• Les tests d’API évitent la fragilité inhérente aux tests portant sur les effets secondaires et les détails d’implémentation.

Dans l’idéal, ces tests d’API doivent être exécutés en continu, aussi bien dans les environnements de production que dans les environnements de préproduction. Les outils de test de contrat peuvent contribuer à automatiser ce processus, mais ils nécessitent une infrastructure supplémentaire.

Et si nous pouvions utiliser des tests continus d’API directement intégrés à notre outil d’observabilité ? La prochaine fonctionnalité de test synthétique des API d’Instana vous permettra d’exécuter en continu des tests d’API dans tous vos environnements, avec un minimum d’efforts.

Le shift-left consiste à rapprocher les activités de test du début du cycle de développement logiciel, afin d’obtenir des retours plus rapides et de réduire le temps et les efforts nécessaires à la correction des bugs. Voici quelques bonnes pratiques pour mettre en œuvre les tests shift-left dans le cadre du développement agile :

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

2. Collaboration et communication : encouragez 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 des sprints et les rétrospectives régulières afin de garantir une compréhension commune et un bon alignement.
   

3. Automatisation des tests : investissez dans l’automatisation des tests afin de pouvoir tester fréquemment et efficacement. Les tests automatisés doivent être créés parallèlement au processus de développement et intégrés aux pipelines d’intégration et de déploiement continus. Cela permet de détecter les défauts plus tôt, de réduire les problèmes de régression et d’accélérer les cycles de rétroaction.
   
    

4. Développement piloté par les tests (TDD) : encouragez la pratique du TDD, dans laquelle les développeurs rédigent les cas de test avant d’écrire le code proprement dit. Cette approche shift-left permet de définir dès le départ le comportement souhaité et les résultats attendus, ce qui produit un code plus robuste et plus facile à tester.
    

5. Intégration continue et livraison continue, ou CI/CD : mettez en œuvre des pipelines CI/CD afin d’automatiser les processus de génération, 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 rapidement et fréquemment dans les environnements de production, réduisant ainsi le risque de problèmes d’intégration.
   
    

6. Tests de sécurité 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 revues de sécurité du code, des analyses statiques du code et des tests axés sur la sécurité afin d’identifier les vulnérabilités et de les traiter de manière proactive.
   

7. Tests exploratoires : parallèlement aux tests automatisés, encouragez les tests exploratoires afin d’étudier l’application du point de vue de l’utilisateur. Les testeurs expérimentés peuvent identifier des problèmes potentiels d’utilisabilité, des cas limites et des scénarios que les tests automatisés risquent de ne pas détecter.
    

8. Tests de performance : réalisez les tests de performance suffisamment tôt afin d’identifier les éventuels goulots d’étranglement et problèmes d’évolutivité. Cela permet d’optimiser les performances de l’application et de garantir qu’elle satisfait aux critères de performance exigés.
    

9. Environnements et données de test : fournissez des environnements de test ressemblant étroitement aux environnements de production afin de garantir des tests logiciels réalistes. Veillez également à disposer de données de test suffisantes et représentatives pour simuler des scénarios réels.
   
    

10. Apprentissage et amélioration continus : favorisez une culture d’apprentissage et d’amélioration continus. Encouragez l’organisation régulière de rétrospectives afin d’analyser les processus de test, d’identifier les goulots d’étranglement et de mettre en œuvre des changements destinés à améliorer l’efficacité des tests shift-left.

En appliquant ces bonnes pratiques, les équipes agiles peuvent améliorer leur collaboration, obtenir des retours plus rapides et produire des logiciels de meilleure qualité grâce aux tests shift-left.

Les boucles de rétroaction plus courtes intégrées aux processus shift-left nous donnent les moyens d’agir de plusieurs façons. Les défauts peuvent être détectés plus rapidement, les correctifs peuvent être appliqués plus efficacement et les enseignements tirés d’une itération peuvent être mis à profit dès l’itération suivante, pour ne citer que quelques exemples.

Quels que soient la méthode de gestion de projet ou le rythme de publication adoptés par votre équipe, vous pouvez bénéficier des boucles de rétroaction de vérification plus courtes offertes par les tests shift-left.

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 revanche, lorsqu’un défaut atteint un environnement accessible aux clients, son coût de correction augmente.

Lorsqu’ils sont correctement mis en œuvre, les tests automatisés et l’intégration continue peuvent donner aux ingénieurs logiciels la confiance nécessaire pour effectuer fréquemment des déploiements, même le vendredi. Détecter les défauts plus tôt réduit le nombre de situations de panique nécessitant la mobilisation de toutes les équipes. Les mises en production étant beaucoup plus simples, les quelques erreurs qui parviennent malgré tout à passer entre les mailles du filet sont également plus rapides et plus faciles à corriger.

Tout comme un logiciel plus accessible est plus facile à utiliser pour tout le monde, un logiciel plus facile à tester peut être plus simple à comprendre et à maintenir. Prendre les tests en considération dès le départ peut conduire à une meilleure séparation des préoccupations et à une architecture globale plus résiliente.

Notre objectif est d’améliorer l’expérience client. Le shift-left peut éliminer certains incidents susceptibles d’affecter les utilisateurs et réduire l’impact d’autres incidents. Nous pouvons utiliser l’observabilité afin de compléter cette boucle de rétroaction et d’améliorer la santé globale de nos logiciels.

Avec les puissants outils d’automatisation dont nous disposons, il peut être tentant de mettre en œuvre chaque type de test sur chaque ligne de code. Cette approche est dangereuse.

Tester les effets secondaires, par exemple, vérifier que cet enregistrement a bien été sauvegardé dans la base de données, peut sembler séduisant. Toutefois, tester les détails d’implémentation constitue un anti-modèle, car ce type de test est fragile. Ces tests pourraient devoir être modifiés à chaque changement apporté à votre application. L’interface utilisateur étant elle aussi un détail d’implémentation, les tests d’interface utilisateur se retrouvent dans la même situation.

Les tests de vérification s’intéressent uniquement au « quoi », et non au « comment » ou au « pourquoi ». Dans l’idéal, les exigences utilisateur ont été conçues de façon à valider le « pourquoi ». Pour répondre à la question du « comment », nous pouvons nous appuyer sur une forme d’automatisation plus puissante : une plateforme d’observabilité.

Les tests shift-right consistent à réaliser les activités de test plus tard dans le processus de développement, généralement dans les environnements de production. Bien que cela puisse sembler étrange, les tests shift-left et shift-right sont complémentaires.

Les tests shift-right nous permettent d’identifier les problèmes en production avant que nos clients ne les découvrent. Les boucles de rétroaction plus courtes offertes par les tests shift-left nous permettent de réagir rapidement à ces problèmes de production et d’y remédier.

Intégrer des tests d’API synthétiques à votre plateforme d’observabilité constitue le moyen idéal de combiner les avantages des pratiques shift-left et shift-right.