Cet article met en lumière l'importance de la phase de test dans la boucle infinie du DevOps. Nous y passons en revue les outils, frameworks et méthodes, les différents types de tests, ainsi qu'un panorama de l'écosystème AWS et des services disponibles pour mettre en œuvre les bonnes pratiques DevOps, et plus particulièrement la phase de test. Il ne s'agit pas d'un article technique, mais plutôt d'un contenu généraliste et informatif. Vous n'y trouverez pas de détails techniques sur la mise en place d'un pipeline ou le déploiement de code sur votre infrastructure : nous nous concentrons sur les points clés, les options et les services impliqués.
La phase de test
Les pratiques DevOps imposent une livraison rapide des logiciels, avec parfois plusieurs déploiements par jour. Pour répondre à ces exigences, les équipes doivent pouvoir tester le code en quelques minutes et le plus fréquemment possible. La phase de test détermine si le build est prêt à passer à l'étape suivante, ou s'il doit être bloqué selon les résultats des tests, sans intervention humaine.
Tester un logiciel est une étape essentielle du cycle de vie du développement logiciel (SDLC) : détecter les bugs au plus tôt et les corriger avant la mise en production a une valeur inestimable. Intégrer une phase de test dans votre pipeline présente l'énorme avantage d'identifier les bugs existants. Pendant cette phase, on s'appuie sur des outils de test automatisés, qui varient selon l'application. Par exemple, Newman permet de tester facilement les méthodes publiques d'une API, JUnit/Xunit ou Jest sont parfaits pour les tests unitaires de votre code et de vos composants, et Playwright ou Cypress sont idéaux pour des tests e2e complets jusqu'au niveau de l'interface utilisateur si votre application est une application web.
La phase de test est aussi le moment d'intégrer des outils de gestion de tests comme TestRail. Cet outil génère des rapports complets sur la base de code et les résultats de tests, offrant aux parties prenantes une visibilité sur le cycle de développement et la maturité de l'application. Les décideurs de l'entreprise disposent ainsi d'un reporting utile pour mieux appréhender le cycle de développement et la maturité applicative. Une bonne pratique consiste à adopter un état d'esprit où la qualité s'inscrit partout dans l'organisation, et non plus seulement dans les frontières d'un service QA. Cet état d'esprit vous aidera à atteindre les meilleurs résultats, et la phase de test vous permettra de tracer la voie vers la réussite.
Pourquoi la phase de test est-elle importante
L'avantage le plus déterminant de la phase de test, c'est de permettre que les tests, la validation qualité et l'évaluation des performances aient lieu le plus tôt possible dans le SDLC. Cette pratique de shift left tranche avec les approches traditionnelles ou manuelles, qui interviennent surtout en fin de cycle.
Voici quelques bénéfices évidents de la phase de test :
- Mettre en place les tests dès le début du SDLC permet un processus de test continu, qui ouvre la voie à une livraison plus rapide et continue des logiciels. Cette approche favorise des tests rapides, fréquents et précoces, et réduit le risque que des erreurs passent inaperçues.
- L'automatisation des tests élimine le facteur humain qui consiste à passer à côté d'erreurs, en contrepartie d'une maintenance et d'une mise à jour régulières des scénarios de test. Une équipe dédiée de développeurs spécialisés dans le test peut donc s'avérer nécessaire.
- Chaque étape du SDLC fait appel à différentes formes de tests (tests unitaires, tests d'API, tests e2e et tests d'interface). Cela limite les retours en arrière en cas de détection d'une erreur.
La mise en œuvre de cette phase réduit le délai de livraison des applications et minimise les erreurs et les bugs. Elle contribue ainsi à instaurer un modèle de responsabilité partagée de la qualité, où l'ensemble du département Engineering est responsable de la qualité applicative.
À propos de la pyramide des tests
La pyramide des tests est un concept bien connu du développement logiciel, abordé dans de nombreux articles et ouvrages, mais sa description originelle revient à Mike Cohn dans son livre Succeeding with Agile. La métaphore de la pyramide aide à visualiser les différentes couches de tests à mettre en place dans le développement logiciel.
Les tests orientés comportement (Behavior-Driven) sont les plus efficaces, car ils intègrent à la fois les scénarios de test et les résultats attendus. On considère qu'ils couvrent l'intégration entre composants, ce qui rend les tests d'intégration les plus précieux : ils éprouvent le système dans son ensemble ou des modules complexes isolés, et non simplement des unités individuelles. Investir dans les tests e2e d'interface (exécutés sur le système après son déploiement et son intégration complète) peut donc sembler une excellente idée — et c'est en grande partie vrai. Mais cela comporte aussi quelques pièges : ne miser que sur les tests e2e d'interface peut conduire à des dépenses disproportionnées, à un casse-tête de maintenance et à beaucoup de stress.
Investir uniquement dans les tests end-to-end d'interface mène souvent à l'anti-pattern dit du cornet de glace dans la pyramide des tests, aussi appelé pyramide atypique ou inversée.
La maintenance d'un tel cornet vire vite au cauchemar, les coûts peuvent s'emballer, les résultats des tests deviennent incohérents, et votre organisation perdra probablement les bénéfices d'une véritable phase de test.
Passons maintenant en revue les couches de la pyramide des tests, les types de tests les plus répandus et les avantages de chacun.
- Tests unitaires : les plus basiques et les plus granulaires, ils ciblent une seule unité de travail, généralement une méthode ou un composant. Situés à la base de la pyramide des tests, ils peuvent être compilés et exécutés dès l'étape de Build. Faciles à mettre en œuvre, peu coûteux et simples, ils constituent une première ligne de défense pour la qualité du code.
- Tests d'intégration / tests d'API : l'intégration s'effectuant via l'API, tester cette couche est crucial pour vos systèmes. Ces tests doivent valider la capacité du système à fonctionner en intégration (et donc vérifier que les unités de travail peuvent coexister et fonctionner ensemble). Ils peuvent être implémentés par les développeurs ou par les spécialistes qualité, selon la structure de l'organisation. Au final, personne n'aimerait monter à bord d'un avion qui n'aurait été soumis qu'à des tests unitaires…
L'automatisation des tests, c'est…
Lorsque votre parc logiciel ne cesse de grossir — et même lorsqu'il reste relativement stable —, tester votre application manuellement devient vite difficile. Garantir l'exécution correcte d'un processus répétitif tout en réduisant le facteur d'erreur humaine est quasi impossible à la main. C'est là que l'automatisation entre en jeu : elle est devenue un standard dans presque tous les domaines, de l'infrastructure à l'orchestration des builds, en passant par le test du code et des applications.
Concrètement, les développeurs se concentrent sur l'écriture des tests unitaires et d'intégration dans le cadre de leurs livrables ou de leurs tâches, tandis que les spécialistes qualité prennent en charge l'écriture des tests e2e d'interface, à partir des scénarios fournis par les équipes métier ou les product owners. La phase de découverte des tests, principalement réalisée en manuel, intervient comme étape préalable à l'automatisation.
Pour automatiser la phase de test, vous pouvez vous appuyer sur l'un des nombreux outils disponibles aujourd'hui sur le marché. Les possibilités sont infinies et dépendent surtout de vos besoins et des compétences de votre organisation de développement. Playwright et Cypress vous aideront à atteindre vos objectifs sur les tests e2e d'interface ; chacun a ses avantages et ses inconvénients, et vous pouvez aujourd'hui les utiliser comme solution unique (couvrant toutes les couches de votre pyramide des tests) si votre stack est en JS, par exemple. Pour la couche d'intégration, le choix est également vaste : Katalon, Newman by Postman, et bien d'autres. Examinez toujours les fonctionnalités et tenez compte de la complexité, de l'interopérabilité et de la capacité d'intégration au pipeline CI/CD (puisque tout l'intérêt de ces outils est de pouvoir les intégrer à votre phase de test, et donc à votre pipeline CI/CD). Reste enfin la couche des tests unitaires : pour les écrire et les exécuter, choisissez les outils les plus adaptés à votre base de code — XUnit pour le code .Net, JUnit pour Java, et Jest pour le code en JS ou TS (ou, comme évoqué plus haut, des outils modernes et polyvalents comme Playwright vous permettent, si votre code est en JS ou TS, de tester l'ensemble de votre pyramide. Reportez-vous à la documentation officielle de Playwright).
AWS CodePipeline pour mettre en œuvre votre phase de test
La phase de test peut s'implémenter avec différents outils et services présents aujourd'hui sur le marché. Des services comme Jenkins ou CircleCI suivent les mêmes étapes pour atteindre le résultat souhaité : récupérer votre code depuis la source > le builder > le tester > déployer en pré-production (Staging) > éventuellement le tester à nouveau > déployer en production. Et voilà, le déploiement est terminé.
De nombreux outils et services existent, mais penchons-nous sur les services AWS. AWS CodePipeline est un service de livraison continue (CD) entièrement managé qui permet de construire des pipelines, d'orchestrer les étapes et de livrer des mises à jour à votre application et à votre infrastructure. AWS CodePipeline s'intègre parfaitement à d'autres services DevOps AWS comme AWS CodeDeploy, AWS CodeCommit et AWS CodeBuild, ainsi qu'à des fournisseurs tiers reconnus tels que Jenkins et Github.
Le cas d'usage le plus simple d'un pipeline est le suivant : récupérer le code > le builder > le déployer. Cela paraît simple, et dans ce scénario vous ne pouvez exécuter que les tests unitaires lors de l'étape de Build. Très bien ! Mais qu'en est-il d'un pipeline plus complexe, dont la phase de test inclut des tests d'intégration et même des tests e2e d'interface ? Le pipeline ressemble alors à ceci : récupérer le code > le builder > déployer en Staging > le tester > déployer en Prod. La différence, c'est qu'en étendant le pipeline, on ajoute une étape de test capable d'exécuter des tests d'intégration et/ou des tests e2e d'interface sur l'environnement de Staging déployé à l'étape précédente. Bien plus efficace ! Ajouter la phase de test ici est très simple : il suffit d'introduire une étape supplémentaire (Stage) via la page d'édition du pipeline existant et de configurer l'exécution de vos tests à l'aide du framework natif d'exécution de tests (selon l'outil retenu).
Ce service étant polyvalent et capable d'interagir avec de nombreux autres services AWS et tiers, il est difficile d'en isoler un pour servir d'exemple. Il convient toutefois de mentionner certaines fonctionnalités utiles et importantes d'AWS CodePipeline :
Option de détection : propriété d'un pipeline qui déclenche son exécution. Selon l'emplacement source des artefacts, AWS recommande d'utiliser les webhooks Github pour Github, ou Amazon CloudWatch Events pour des artefacts stockés dans un bucket AWS S3, par exemple.
Désactivation/activation des transitions : la transition relie les étapes du pipeline et est activée par défaut. Si, pour une raison quelconque, vous ne souhaitez pas passer automatiquement d'une étape à l'autre, vous pouvez la désactiver via le bouton Disable transition ; vous interrompez ainsi l'exécution continue du pipeline. La réactivation est tout aussi simple.
Ajout d'étape : pour modifier la séquence du pipeline et introduire une nouvelle étape ou en supprimer/mettre à jour une existante, il faut cliquer sur Edit sur le pipeline, ce qui ouvre la page d'édition où vous pouvez ajouter des actions à votre étape, en série ou en parallèle des actions existantes. Cette fonctionnalité rend votre pipeline flexible et extensible.
Action d'approbation : lorsque vous souhaitez piloter les étapes de votre pipeline, par exemple imposer qu'une personne valide l'étape de déploiement, vous pouvez utiliser cette fonctionnalité. Elle met le pipeline en pause jusqu'à l'approbation, puis reprend l'exécution une fois celle-ci accordée.
Parmi les autres services DevOps AWS qui s'intègrent bien à CodePipeline :
- AWS CodeCommit
- AWS CodeDeploy
- AWS CodeBuild
Synthèse et conclusion
Aucun pipeline ne devrait exister sans phase de test, et aucune mise en production ne devrait avoir lieu sans elle. Réduire le facteur humain et s'appuyer sur l'automatisation et sur les outils mis à disposition pour y parvenir : voilà ce qui doit guider le spécialiste DevOps responsable du CI/CD. Et cela ne concerne pas seulement le spécialiste DevOps qui construira probablement le pipeline, mais l'ensemble de l'organisation de développement, y compris les développeurs, les équipes QA et l'équipe DevOps. La bonne approche consiste à voir la qualité comme la responsabilité de tous, et la phase de test comme une étape disponible, pratique, flexible et infaillible. Le recours à un service adapté comme AWS CodePipeline aidera à atteindre les résultats attendus !
Liens et ressources :