Bonjour chers lecteurs, bienvenue ! Cet article fait partie de la série Z to A Pulse : Report spotlight, où nous publions nos réflexions sur les conclusions de noms réputés tels que : World Quality Report, Gartner, McKinsey, Forrester, etc. Nous analysons leurs conclusions et leurs tendances avec l’aide de nos leaders en ingénierie, puis nous partageons les idées pour vous aider à atteindre l’excellence en matière d’ingénierie. Abonnez-vous en cliquant sur le bouton ci-dessus pour lire les prochaines éditions.

Dans le sujet…

Ces dernières années, nous avons assisté à un changement dans la manière dont les logiciels sont construits, perfectionnés et livrés aux utilisateurs. Avec l’arrivée de DevOps, les équipes d’ingénierie se trouvent désormais à l’avant-garde d’une nouvelle ère, marquée par une volonté incessante d’automatisation et de circulation transparente du code à travers des pipelines d’intégration et de livraison continues (CI/CD).

Nous sommes à un carrefour où les tests continus ne sont pas seulement une bonne pratique ; c’est un lien important pour s’assurer que votre logiciel n’est pas seulement opportun, mais aussi d’une qualité inébranlable.

Rejoignez-moi dans ce voyage passionnant pour explorer le concept de DevOps et l’importance des tests continus dans la livraison de logiciels modernes d’aujourd’hui.

Bonjour ! Je suis Keerthi V, stratège marketing chez Zuci Systems.

Rencontrez nos experts :

1. Saraswathi Jayaraman
2. Pratapsinha Suryawanshi

Saraswathi et Pratap ont passé plus de 50 000 heures à aider les équipes d’ingénieurs à réaliser des expériences utilisateur exceptionnelles dans le contexte dynamique de CI/CD.

Voici ce qu’ils ont à dire sur le sujet.

Pratap : Les tests traditionnels de logiciels dans le cadre d’une méthodologie de développement en cascade sont bien connus pour être un processus lent et coûteux qui retarde les versions tout en apportant une valeur commerciale discutable. Les logiciels devenant la clé de la création d’un avantage concurrentiel sur tous les marchés, les entreprises ne peuvent plus s’offrir le luxe de choisir entre la “vitesse” et la “qualité” lorsqu’elles fournissent des logiciels. Ces deux éléments sont essentiels.

Aujourd’hui, avec la maturité et l’acceptation des initiatives agiles et DevOps dans les entreprises, la stratégie de test continu aide les entreprises à accélérer et à prioriser les tests pour répondre aux besoins des initiatives Agile et DevOps qui évoluent rapidement. Cette nouvelle stratégie aide les entreprises à tester de manière plus intelligente, de sorte que les tests permettent d’obtenir rapidement des informations sur ce qui compte le plus pour l’entreprise.

Mise en œuvre de tests continus :

Le pipeline DevOps est une série d’étapes qui automatisent le processus de développement de logiciels, de la validation du code à la mise en production. Les tests continus doivent être intégrés à chaque étape du pipeline, des tests unitaires aux tests d’acceptation.

L’une des principales activités techniques consiste à élaborer et à maintenir un ensemble de suites de tests automatisés, notamment :

Tests unitaires : Ces tests visent à valider la fonctionnalité d’une méthode, d’une classe ou d’une fonction isolée. Leur objectif premier est de garantir aux développeurs que leur code fonctionne comme prévu. Pour s’assurer que le code est testable et que les tests restent maintenables, il est conseillé d’adopter la pratique consistant à écrire des tests unitaires avant d’écrire le code proprement dit, une méthode communément appelée développement piloté par les tests (TDD).

Tests d’acceptation : Ces tests se situent à un niveau plus élevé et évaluent une application ou un service en cours d’exécution. En règle générale, ils interagissent avec le système testé (souvent en remplaçant les dépendances par des doubles de test) pour vérifier que les fonctionnalités les plus larges fonctionnent comme prévu et qu’aucune erreur de régression n’a été introduite. Les tests d’acceptation servent à valider divers aspects, tels que le respect des critères d’acceptation de l’entreprise pour une histoire d’utilisateur ou la garantie de l’exactitude d’une API. Une bonne pratique consiste à intégrer ces tests dans le processus de développement. En fait, il est recommandé qu’aucun travail ne soit considéré comme “terminé” tant que les tests d’acceptation automatisés n’ont pas été passés avec succès.

L’image ci-dessous montre les types de tests automatisés et manuels à effectuer.

Lorsque vous rencontrez une erreur dans un test d’acceptation ou lors d’un test exploratoire, une approche proactive consiste à compléter vos tests par un test unitaire. Ce test unitaire supplémentaire sert de filet de sécurité critique, garantissant que la même erreur est détectée plus rapidement, à un stade plus précoce, et avec des coûts réduits dans les cycles de test ultérieurs.

Cette approche s’aligne sur le concept de Mike Cohn de la pyramide idéale d’automatisation des tests, comme illustré dans le diagramme ci-dessous.

Vous pourriez être intéressé par :

L’énigme de l’automatisation des tests : Vue Zuci

L’exécution continue des tests dans le cadre d’un pipeline contribue à un retour d’information rapide pour les développeurs, à un délai court entre l’enregistrement et la publication, et à un faible taux d’erreur dans les environnements de production. Les développeurs voient la majeure partie de leur travail validée en quelques minutes, au lieu de jours ou de semaines, ce qui leur permet de corriger les bogues dès que possible.

Le diagramme suivant montre un exemple de pipeline de déploiement linéaire simple. Dans cet exemple, le vert signifie qu’aucun problème n’a été détecté, et le rouge qu’un ou plusieurs problèmes ont été découverts.

L’exécution continue des tests dans le cadre d’un pipeline contribue à un retour d’information rapide pour les développeurs, à un délai court entre l’enregistrement et la publication, et à un faible taux d’erreur dans les environnements de production. Les développeurs voient la majeure partie de leur travail validée en quelques minutes, au lieu de jours ou de semaines, ce qui leur permet de corriger les bogues dès que possible.

Le diagramme suivant montre un exemple de pipeline de déploiement linéaire simple. Dans cet exemple, le vert signifie qu’aucun problème n’a été détecté, et le rouge qu’un ou plusieurs problèmes ont été découverts.

Vous pouvez mesurer les résultats des tests automatisés dans votre environnement en procédant comme suit :

Pratap :

Les tests continus sont largement utilisés et efficaces dans les modèles de développement suivants

1. Agile : les tests continus font partie intégrante de l’Agile, où le produit est construit par petites étapes avec un retour d’information et des tests réguliers. Les tests continus aident l’équipe de développement de produits à construire le produit plus rapidement et mieux, avec moins d’erreurs.

2. DevOps : les tests continus sont effectués automatiquement tout au long du cycle de vie du développement logiciel (SDLC). Les tests continus vont de pair avec l’intégration continue pour valider automatiquement tout nouveau code intégré dans l’application.

3. CTDD : le développement continu piloté par les tests (CTDD) offre les avantages du développement piloté par les tests et permet l’exécution automatique de tests, fournissant aux testeurs un retour d’information continu sur le fonctionnement de leur code.

Le rapport 2020 sur les tests continus indique que

Les environnements de test sont l’un des plus grands obstacles aux tests continus et à la livraison agile : 36 % des personnes interrogées déclarent passer plus de 50 % de leur temps à les gérer.

L’enquête révèle également que la capacité à créer des environnements dynamiques sera essentielle, en changeant et en combinant des composants individuels en fonction des besoins. À cet effet, les infrastructures telles que les pratiques de code (IaC), la conteneurisation, l’approvisionnement en nuage et la virtualisation des services joueront un rôle important.

Saraswathi :

L’évolution de l’utilisation de l’infrastructure en nuage est intéressante.

Au début, c’était simple : une seule machine virtuelle à laquelle on accédait par SSH. Mais la deuxième vague a apporté les conteneurs et les outils de provisionnement comme Dockers. Ensuite, l’infrastructure est devenue plus dynamique.

Aujourd’hui, l’infrastructure moderne en nuage a ajouté des couches de complexité. Il ne s’agit plus seulement de conteneurs, mais d’informatique sans serveur et d’un ensemble de services gérés, tous tissés dans les architectures d’application.

C’est là que l’Infrastructure as Code (IaC) entre en jeu. Avec l’IaC, nous pouvons définir l’état souhaité de notre infrastructure, ce qui la rend plus agile et plus adaptable.

De plus, l’IaC est un catalyseur de la culture DevOps. Il supprime les frontières entre le développement et les opérations, ce qui favorise une meilleure collaboration. Je pense que dans les années à venir, nous assisterons à une montée en puissance de l’adoption de l’IaC, de nombreuses équipes DevOps considérant qu’il s’agit d’une pratique standard.

Un IaC typique se présente comme suit :

• Les développeurs commencent par définir et écrire le code de l’infrastructure.
• Le code est ensuite enregistré dans un système de contrôle de version, souvent à l’aide de plateformes telles que GitHub.
• Il fait l’objet de demandes d’extraction et de révisions par les pairs, pour finalement aboutir à une branche de publication.
• Ensuite, l’outil IaC prend le contrôle et orchestre le déploiement de l’infrastructure dans les environnements en nuage ou sur site.

C’est comme si vous codiez votre infrastructure, en veillant à ce que tout, des serveurs aux réseaux, soit mis en place de manière cohérente et précise. Cela signifie que vous pouvez répliquer vos environnements en quelques minutes et qu’il n’y a plus d’heures perdues en configurations manuelles.

Conteneurisation : les applications sont regroupées avec leurs dépendances, ce qui les rend portables. Les équipes peuvent exécuter le même conteneur sur l’ordinateur portable de développement, sur le serveur d’essai et sur l’environnement de production, ce qui réduit les risques de bogues spécifiques à l’environnement.

Tout comme l’importance d’avoir des données de test facilement disponibles, les services virtuels jouent un rôle crucial dans la gestion efficace de l’environnement de test et l’approche shift-left pour réaliser des tests continus. La virtualisation des services imite le comportement des systèmes externes, même lorsqu’ils ne sont pas disponibles. Ainsi, les tests se poursuivent, même lorsque les dépendances externes sont interrompues pour des raisons de maintenance ou autres. L’avantage de cette approche est que n’importe quelle équipe peut accéder à n’importe quel service sur une base virtualisée et le tester. Il est rapide, précis et réagit comme s’il était réel, ce qui signifie que les équipes peuvent effectuer des tests en parallèle.

La maîtrise de ces pratiques permet de mettre en place et de gérer des environnements de test. Il fait gagner du temps et permet aux équipes de se concentrer sur ce qui compte vraiment : fournir plus rapidement des logiciels de qualité. Il s’agit d’optimiser le processus et d’adopter l’agilité, ce qui est la raison d’être des tests continus.

Recherche et évaluation DevOps (DORA) sur la mise en œuvre d’une infrastructure flexible :

La livraison continue et le contrôle de version amplifient mutuellement leur capacité à promouvoir des niveaux élevés de performance en matière de livraison de logiciels.

En outre, les équipes qui se concentrent sur les pratiques suivantes ont tendance à mettre en place des processus DevOps plus sophistiqués.

Architecture faiblement couplée – dans la mesure où les équipes peuvent apporter des modifications à grande échelle à la conception de leur système sans dépendre d’autres équipes pour modifier leurs systèmes.

Contrôle des versions – gestion des modifications apportées au code de l’application, à la configuration du système, à la configuration de l’application, etc.

Intégration continue – fréquence d’intégration des branches dans le tronc.

Livraison continue – capacités axées sur la mise en production des changements de manière sûre, durable et efficace.

Ces pratiques, ainsi que les tests continus, favorisent la livraison de logiciels dont les performances sont supérieures à la somme de leurs parties.

Pouvez-vous nous faire part brièvement de vos réflexions sur ces pratiques ?

Saraswathi :

Beaucoup d’organisations investissent beaucoup de temps et d’efforts dans l’adoption de technologies, mais peinent à obtenir les résultats souhaités en matière de livraison de logiciels en raison de limitations architecturales.

Dans une architecture étroitement couplée, même des ajustements mineurs peuvent déclencher des défaillances généralisées et interconnectées. Cela nécessite une coordination constante entre les différentes équipes du système, qui doivent souvent naviguer dans des procédures de gestion du changement alambiquées et bureaucratiques.

En revanche, lorsque l’architecture du système est conçue pour permettre aux équipes de tester, de déployer et de modifier les systèmes de manière indépendante, sans dépendre d’autres équipes, la communication devient minimale. Par essence, l’architecture et les équipes sont étroitement liées.

Une intégration continue réussie repose sur les éléments suivants Un processus de construction automatisé qui crée des paquets versionnés et reproductibles pour le déploiement, en exécutant le processus quotidiennement.

Suites de tests automatisés : commencez par des tests unitaires et d’acceptation fiables, élargissez la couverture pour les nouvelles fonctionnalités et assurez un retour d’information quotidien aux développeurs.

CI/CD est à la fois l’intégration continue et la livraison continue. Pour que vos logiciels soient fiables et sûrs, il est essentiel que toutes les personnes impliquées dans le processus, et pas seulement les développeurs, travaillent en étroite collaboration. Et votre équipe doit être ouverte à l’apprentissage de nouvelles façons de faire et à l’acquisition de nouvelles compétences.

Principaux enseignements :

Stratégies pour déployer les tests continus dans DevOps :

• Adoptez l’automatisation : Construisez votre stratégie sur l’automatisation des tests pour des tests plus rapides et plus cohérents.
• Test Shift-Left : Commencez les tests dès le début du développement pour détecter les problèmes plus tôt. De nouvelles méthodologies d’automatisation continueront d’évoluer dans le virage à gauche, notamment les tests basés sur des modèles, le BDD, le TDD et les tests de sécurité in-sprint.
• Gestion des données : Assurez une gestion complète des données d’essai pour des essais efficaces.
• Virtualisation des services : Simulez des composants indisponibles pour des tests plus approfondis.
• Surveillance continue : Gardez un œil sur les résultats des tests et les défauts pour un retour d’information en temps réel.
• Exécution parallèle : Exécutez plusieurs tests simultanément pour gagner du temps.
• Intégration CI/CD : Intégrez les tests dans vos pipelines CI/CD pour une automatisation transparente.
• Gestion de l’environnement de test : Gérer efficacement les environnements de test pour éviter les retards. La capacité à créer des environnements de manière dynamique sera essentielle. À cet effet, les infrastructures telles que les pratiques de codage, la conteneurisation et la virtualisation joueront un rôle important.
• Collaboration et communication : Favorisez le travail d’équipe pour une résolution plus rapide des problèmes.
• Amélioration continue : Affinez régulièrement votre stratégie pour garantir un succès continu.

Question pour vous :

Où en êtes-vous dans votre parcours de tests continus ?

• Débutant
• Intermédiaire
• Expert

Merci de votre lecture ! Nous sommes impatients d’approfondir les conclusions du rapport mondial sur la qualité dans nos prochaines éditions.

Si vous aimez notre contenu, montrez-nous votre soutien en vous abonnant à notre lettre d’information trimestrielle, Sound bytes ici. et en partageant cet article avec votre équipe. Votre soutien nous est précieux !