Améliorez la qualité logicielle et gagnez du temps grâce aux tests d’infrastructure

Les éléments les plus banals, comme les codes d’accès ou les cartes à puce utilisés pour accéder aux bâtiments, peuvent devenir critiques s’ils ne sont pas disponibles.

L’infrastructure, sous toutes ses formes, existe pour soutenir le développement, les tests, le déploiement et l’exploitation de vos systèmes. Elle est soit essentielle aux tests, soit doit elle-même être testée.

Nous examinerons les outils de développement, de test et de collaboration dans le prochain article. Dans celui-ci, nous nous intéresserons à ce que la plupart des gens considèrent comme des environnements de test et nous examinerons brièvement ce que l’on appelle souvent les tests d’infrastructure. Je traiterai les sujets suivants :

• Environnements de test
• Environnements de développement
• Environnements de test au niveau du système
• Environnements de données
• Tests d’infrastructure

C’est parti.

Environnements de test

Tout test repose sur une hypothèse implicite, critique et simplificatrice : nos tests seront exécutés dans un environnement connu.

Qu’est-ce qu’un environnement ?

Tous les systèmes doivent être testés dans leur contexte. Pour qu’un test soit pertinent, le système doit être installé, configuré, déployé ou construit dans un environnement réaliste qui simule le monde réel dans lequel il sera utilisé. 

Nous pouvons utiliser, par exemple, des scénarios de test qui poussent les capacités des systèmes en matière de fonctionnalités, de performance ou de sécurité, mais il s’agit de propriétés des tests, et non de l’environnement.

Un environnement réaliste reproduirait l’ensemble des environnements métier, techniques et organisationnels. Une grande partie de cet environnement est constituée des données utilisées pour piloter les processus métier, configurer le système et fournir des données de référence.

Mais les environnements parfaitement réalistes sont généralement irréalisables ou beaucoup trop coûteux (même les testeurs de systèmes à criticité élevée, comme les avions, les réacteurs nucléaires ou les scanners cérébraux, doivent faire des compromis à un moment donné). La quasi-totalité des tests se déroule dans des environnements qui simulent le monde réel avec un niveau de compromis acceptable.

Les voitures sont testées sur des bancs à rouleaux, dans des souffleries, sur des bancs de vibration et sur des pistes d’essai privées avant de l’être sur la voie publique. Les systèmes informatiques sont testés dans des laboratoires logiciels par des programmeurs et des testeurs de logiciels avant que les utilisateurs finaux ne soient invités à les essayer dans un environnement proche de la production.

Pour vous assurer que vos environnements de test respectent les normes du secteur, envisagez d’intégrer l’une de ces plateformes de gestion des tests les mieux notées.

REJOIGNEZ LA COMMUNAUTÉ

Améliorez votre boîte de réception avec plus de conseils en leadership technologique pour livrer de meilleurs logiciels et systèmes.

Create Free Account

Have an account? Log In

Tester dans des environnements réalistes

Les environnements simulés sont faillibles, tout comme nos exigences et nos modèles de test, mais nous devons composer avec cette réalité.

Nous devons planifier des tests pertinents dans les environnements dont nous disposons, et les résultats des tests signifient ce que nous leur faisons dire.

La fiabilité des résultats des tests dépend de l’environnement dans lequel les tests sont exécutés. Si un test est exécuté dans un environnement mal configuré :

• Un test qui échoue peut laisser penser que le système est défectueux alors qu'en réalité, il est correct.
• Un test qui réussit peut laisser penser que le système est correct alors qu'en réalité, il est défectueux.

Les deux situations sont bien sûr hautement indésirables.

Configurer et fournir les environnements à temps

Même avec l'émergence de l'infrastructure en nuage, les environnements de test peuvent être difficiles et coûteux à configurer et à maintenir.

Lorsque les équipes de support travaillent sur le nouvel environnement de production, les testeurs demandent des environnements de test (et peut-être plusieurs). Plus tard au cours des tests, les équipes de support ont souvent des demandes concurrentes.

Les environnements de développement ou toute activité de test ultérieure peuvent être fournis tardivement ou pas du tout, ou ne pas être configurés ou contrôlés comme requis. Inévitablement, cela retardera les tests et/ou sapera la confiance dans tout résultat issu des tests.

Une tâche essentielle consiste à établir le besoin et les exigences relatives à un environnement destiné aux tests, y compris un mécanisme de gestion des modifications apportées à cet environnement—dès que possible.

L'infrastructure en tant que code est une évolution récente de la manière dont les environnements peuvent être construits, avec des outils qui suivent des procédures et utilisent du code déclaratif pour définir la configuration de l'environnement. 

Bien que les plateformes de systèmes d'exploitation de base (serveurs) puissent être créées facilement dans le nuage ou sous forme de machines virtuelles dans votre propre environnement, les serveurs entièrement spécifiés et à usage spécial, dotés de tous les logiciels, données, configurations et interfaces requis, nécessitent davantage d'efforts.

Lors de la configuration de votre infrastructure de test, il est essentiel d'intégrer un logiciel fiable de gestion de bases de données pour des performances optimales

Cependant, une fois configurés, ils constituent un moyen très efficace de créer des environnements. Le code d'infrastructure peut être géré dans un système de contrôle de version, comme n'importe quel code d'application, et administré au moyen de modifications.

Un principe majeur de la livraison continue est que, dès que possible, certains logiciels—même s'ils ne sont pas utiles—doivent être envoyés dans le pipeline de livraison afin de prouver que les processus fonctionnent. 

Bien entendu, cela nécessite des environnements adaptés aux compilations, aux outils d'intégration continue, aux tests au niveau du système et au déploiement. L'objectif est de déployer les environnements de test et de production sans contrainte. Une fois les définitions des environnements et les processus de déploiement en place, la génération des environnements devient une tâche automatisée et routinière.

Quelles que soient les circonstances, les définitions de ces environnements constituent un livrable précoce du projet.

Environnements de développement

Les tests réalisés par les développeurs se concentrent sur la construction de composants logiciels qui fournissent des fonctionnalités en interne à l'application ou au niveau de l'utilisateur ou de la présentation. 

Les tests sont généralement guidés par la connaissance de la structure interne du code et peuvent ne pas utiliser de données « réalistes » pour s'exécuter, ou ne pas en nécessiter. Les tests des composants ou services de bas niveau sont généralement exécutés via une API à l'aide de pilotes ou d'outils développés sur mesure ou propriétaires.

La gamme d'outils et de plateformes de développement, ainsi que les environnements de développement intégrés (IDEs), est immense. Dans cet article, nous ne pouvons aborder que certaines des principales exigences et fonctionnalités liées aux tests dans les environnements.

Pour prendre en charge le développement et les tests relevant des développeurs, les environnements doivent prendre en charge les activités suivantes. Il ne s'agit que d'une sélection—il peut y avoir des activités supplémentaires ou des variantes de celles-ci dans votre situation :

• Un environnement « bac à sable » pour expérimenter de nouveaux logiciels. Les bacs à sable sont souvent utilisés pour tester de nouvelles bibliothèques, développer du code prototype temporaire ou s'exercer aux techniques de programmation. Tous les langages de programmation courants disposent de centaines ou de milliers de bibliothèques logicielles. Les bacs à sable servent à installer et à tester des logiciels qui ne font pas encore partie du fil principal du développement, afin de les évaluer et de s'entraîner à les utiliser. Ces environnements peuvent être considérés comme jetables.
• Environnement de développement local. C'est là que les développeurs gèrent une copie locale d'une partie ou de la totalité du code source de leur application, provenant d'un dépôt de code partagé, et peuvent créer des compilations du système pour des tests locaux. Cet environnement permet aux développeurs d'apporter des modifications au code de leur copie locale et de tester ces modifications. Certains tests sont réalisés de manière ponctuelle et ne sont peut-être jamais répétés. D'autres tests sont automatisés. Les tests automatisés sont généralement conservés indéfiniment, en particulier lorsqu'ils suivent une approche pilotée par les tests.
• Environnement d'intégration (continue) partagé. Lorsque les développeurs estiment que leur code est prêt, ils transmettent leurs modifications au dépôt de code partagé et contrôlé. L'environnement CI effectue des compilations automatisées et exécute des tests automatisés à l'aide du dépôt. À ce stade, le code nouveau ou modifié est intégré et testé. Le système CI exécute des tests automatisés à la demande, toutes les heures ou quotidiennement, et toute l'équipe reçoit des notifications et peut consulter l'état des tests de la dernière compilation intégrée. Les échecs sont rapidement mis en évidence et traités en urgence.

Un environnement de développement ou d’intégration continue prend en charge les tests des développeurs, mais d’autres serveurs d’applications, services web, serveurs de messagerie ou serveurs de bases de données qui complètent le système peuvent ne pas être disponibles. 

Si ces systèmes interfacés n’existent pas parce qu’ils n’ont pas encore été créés, ou parce qu’ils appartiennent à une entreprise partenaire qui ne dispose que d’un système en production et d’aucune version de test, les développeurs doivent créer des bouchons ou simuler ces interfaces afin de pouvoir au moins tester leur propre code.

Les outils de simulation peuvent être sophistiqués, mais les interfaces simulées ne permettent généralement pas de prendre en charge les tests qui nécessitent des données intégrées provenant de plusieurs systèmes.

Si une interface vers un serveur de bases de données de test est disponible pour les développeurs, leurs données de test peuvent être minimales, non intégrées ou incohérentes, et ne pas être représentatives des données de production. 

Les bases de données de développement partagées par une équipe sont généralement insatisfaisantes. S’il n’existe pas de bonne méthode de gestion de cette ressource partagée, les développeurs peuvent réutiliser, corrompre ou supprimer les données des autres.

Environnements de test au niveau du système

Les tests au niveau du système se concentrent sur l’intégration collaborative des composants et des sous-systèmes. 

Ces environnements fournissent une plateforme pour soutenir les objectifs d’intégration à grande échelle, de validation des fonctionnalités et d’exploitation du système dans le contexte des processus utilisateur ou métier. 

Les environnements peuvent également être dédiés aux aspects non fonctionnels du système, tels que les performances, la sécurité ou la gestion des services.

L’un des pièges les plus courants des tests survient lorsqu’un testeur système rencontre un problème dans son environnement, mais que, quels que soient ses efforts, le développeur ou le testeur ne parvient pas à reproduire l’échec dans l’environnement de développement.

Cette situation est presque certainement due à un manque de cohérence entre les deux environnements. La différence de comportement peut être causée par la configuration, par des différences entre certaines versions logicielles ou par une différence dans les données de la base de données.

Les différences de données à l’origine des problèmes sont la première chose à vérifier. Elles sont généralement faciles à identifier et peuvent souvent être résolues rapidement.

Lorsqu’il existe une divergence de version logicielle ou de configuration, les testeurs et les développeurs peuvent perdre beaucoup de temps à rechercher la cause de la différence de comportement. 

Lorsque ces problèmes surviennent, cela signifie souvent qu’il y a eu une défaillance de la communication entre le développeur et l’équipe de test. Cela peut également indiquer une perte de contrôle de la configuration lors de la mise en place de l’environnement de développement ou de test, ou au cours du processus de déploiement.

L’infrastructure en tant que code et le provisionnement automatisé des environnements rendront les problèmes de cohérence des environnements obsolètes.

Types d’environnements de test dédiés

Pour prendre en charge les tests système, les tests d’acceptation et les tests non fonctionnels, les environnements doivent prendre en charge les activités suivantes (il peut y en avoir davantage dans votre organisation) :

• Environnement de test du système (fonctionnel). Dans cet environnement, le système est validé par rapport aux exigences documentées pour le système dans son ensemble. Les exigences peuvent être de volumineux documents texte contenant des cas de test présentés sous forme de tableaux et définis pour un test système. Dans les projets agiles, cet environnement peut être nécessaire pour permettre aux testeurs d’explorer le système intégré sans se limiter à des fonctionnalités spécifiques.
• Environnement de test de bout en bout. Alors que l’environnement d’intégration continue permet d’intégrer des composants à des sous-systèmes, les processus métier peuvent nécessiter la disponibilité d’autres systèmes interfacés (qui ne sont pas sous le contrôle des développeurs). Des environnements à périmètre complet sont nécessaires pour effectuer des tests d’intégration, de processus métier ou d’acceptation à grande échelle. Habituellement, les données sont une copie des données de production, ou du moins présentent une échelle appropriée. Lorsqu’il est nécessaire de vérifier une intégration à grande échelle, les flux de données et de contrôle sont exercés au moyen de parcours utilisateurs plus longs et de rapprochements indépendants des données entre les systèmes intégrés. La gestion des données dans les environnements de test est cruciale. Si vous utilisez déjà Jira, envisagez d’améliorer vos capacités de gestion des données avec des outils avancés de gestion des tests conçus pour Jira.
• Environnement de performance. Ces environnements doivent fournir une plateforme pertinente pour évaluer les performances d’un système (ou de certains sous-systèmes). Des compromis dans l’architecture peuvent être possibles en cas de redondance ou de clonage des serveurs. Toutefois, les volumes de données doivent être à l’échelle de la production, même si les données sont synthétiques. L’environnement doit certainement être d’une taille suffisante pour prendre en charge les volumes de transactions de production afin de permettre une prédiction utile des performances des systèmes en production.
• Environnements de disponibilité, de résilience et de facilité de gestion (ARM). À certains égards, ces environnements sont similaires aux environnements de performance, mais des variations peuvent être inévitables selon l’objectif du test. Les tests de disponibilité visent à vérifier que le système peut fonctionner pendant de longues périodes sans tomber en panne. Les tests de résilience (souvent appelés tests de basculement) vérifient que, lorsque des composants du système tombent en panne, ils n’entraînent pas d’interruption inacceptable du service fourni. Les tests de facilité de gestion ou d’exploitation visent à démontrer que les procédures d’administration, de gestion, de sauvegarde et de restauration du système fonctionnent efficacement.

More Articles

• 18 avantages des outils d’observabilité des données pour des opérations fiables
• Qu’est-il arrivé à CrossTalk ? + Les 10 meilleurs articles
• Stockage cloud hybride : guide complet pour 2026

Les données dans les environnements

Dans certains projets de très grande envergure, il peut y avoir jusqu’à 20, voire 30, environnements à grande échelle dédiés à différents aspects des tests, de la formation, de la migration des données et des basculements d’essai. Dans les projets plus modestes, les environnements sont moins nombreux : il peut n’y avoir qu’un seul environnement partagé ou un régime de livraison continue, et tous les tests peuvent être exécutés automatiquement dans des environnements instanciés pour une seule utilisation, puis supprimés.

Tous les environnements ont besoin de données, mais l’échelle et le degré de réalisme de ces données peuvent varier. Voici quelques modèles courants concernant l’acquisition et la gestion des données de test. Ces modèles portent sur la propriété (locale ou partagée), le mode de création (manuel, automatisé ou copié depuis la production) et l’échelle :

• Données locales, créées manuellement et à petite échelle — adaptées aux tests ponctuels réalisés par les développeurs ou les testeurs.
• Données locales, automatisées et synthétiques. Adaptées aux tests automatisés des développeurs ou aux environnements dans lesquels les fonctionnalités de modules ou de fonctions spécifiques peuvent être couvertes.
• Données partagées, créées manuellement. Utilisées dans les environnements de test d’intégration et de test système, souvent lorsque les données de test ont évolué en parallèle des tests exécutés manuellement. Sauvegardées et restaurées lorsque cela est nécessaire.
• Données partagées, créées automatiquement. Utilisées dans les environnements de test d’intégration et de test système lorsque les données de test ont évolué en parallèle des tests automatisés ou exécutés manuellement. Générées et/ou restaurées à partir de sauvegardes lorsque cela est nécessaire.
• Données synthétiques/aléatoires partagées à grande échelle. Les tests de performance et les tests ARM nécessitent des données cohérentes en grande quantité. Ces données n’ont généralement pas besoin d’être significatives : des données aléatoires conviennent parfaitement et sont générées lorsque cela est nécessaire, ou générées initialement puis restaurées à partir de sauvegardes.
• Données pertinentes partagées à grande échelle. Les tests de bout en bout, d’acceptation ou utilisateurs nécessitent généralement des données pertinentes à grande échelle. Des copies ou des extraits de données en production sont parfois utilisés. Veillez toutefois à ne pas enfreindre la réglementation relative aux données si vous ne les brouillez/ne les anonymisez pas.
• Nouveaux tests et tests de régression. Vous aurez besoin d’un jeu de données connu et contrôlé, dans un état connu ; il est donc généralement restauré à partir de sauvegardes. Cela s’applique à tous les environnements ci-dessus, car ces tests doivent être réexécutés avec des données dans un état connu afin de reproduire les défaillances de manière fiable.

Tests de l’infrastructure

Au début de cet article, nous avons examiné ce que comprend l’infrastructure et, depuis, nous nous sommes principalement concentrés sur les composants techniques, à savoir les systèmes logiciels, en supposant que le matériel — réel ou virtuel — était disponible.

Lorsque nous construisons des systèmes au départ, nous supposons que l’infrastructure existe, qu’elle fonctionne correctement, qu’elle est performante, sécurisée et résiliente, etc.

Nous pouvons tester tous ces aspects lorsque nous avons intégré notre application et, sans aucun doute, mettre au jour des lacunes dans l’infrastructure à un stade relativement avancé de nos projets. Mais découvrir des problèmes d’infrastructure aussi tard dans un projet est généralement extrêmement perturbant.

• Les changements nécessaires pour remédier aux défaillances de l’infrastructure peuvent exiger une refonte importante et des modifications de notre application.
• Les résultats des tests de notre application ou de l’ensemble du système devront être reproduits.
• Si des composants tiers tels que des services de base de données, web, réseau ou de messagerie échouent, nous sommes à la merci des fournisseurs (ou de la communauté open source) qui les prennent en charge.

Pour nous assurer que notre confiance dans les composants d’infrastructure est bien fondée, nous pouvons nous appuyer sur notre expérience (ou celle d’autres personnes) de leur utilisation passée. Nous devons également évaluer—par des tests—leur fiabilité avant de nous engager à les utiliser dans la conception et la construction de notre système.

Selon l’infrastructure étudiée, l’environnement que nous utilisons peut varier, d’un serveur unique à une plateforme d’infrastructure presque complète. 

Bien que certains tests soient effectués manuellement, nous utiliserons principalement des outils, des pilotes ou des robots pour simuler la charge transactionnelle que notre application générerait. Nous devrons simuler ou remplacer temporairement ces interfaces :

• Les interfaces qui ne sont actuellement pas disponibles
• Les interfaces des composants auxquels nous faisons confiance et qui sont faciles à simuler
• Les interfaces qui ne sont pas concernées et qui n’ont aucune incidence sur l’infrastructure testée.

L’infrastructure, inutile de le préciser, ne fonctionne généralement pas par l’intermédiaire d’une interface utilisateur ou graphique.

L’intégration de notre application à l’infrastructure prendra principalement la forme de messages ou d’appels de services distants. Souvent, le trafic à simuler nécessite des appels d’API vers des serveurs web ou d’application, des serveurs de messagerie ou de base de données, ou des services fournis dans le cloud ou depuis des sites distants.

Les objectifs de performance et d’ARM peuvent être connus, auquel cas des tests peuvent être effectués pour vérifier qu’ils sont atteints.

Cependant, l’infrastructure est souvent partagée avec d’autres applications que la nôtre. Connaître sa capacité maximale permet donc d’évaluer quelle capacité restera disponible lorsque notre application sera déployée.

Dans ce cas, les tests d’infrastructure visent à gérer le risque auquel sont exposées nos propres applications et, éventuellement, d’autres applications qui pourraient à l’avenir s’appuyer sur cette infrastructure. 

Inscrivez-vous à la newsletter de The QA Lead pour être informé de la publication des nouvelles parties de la série. Ces articles sont extraits de la formation Leadership In Test de Paul, que nous recommandons vivement pour approfondir ce sujet et bien d’autres. Si vous vous inscrivez, utilisez notre code promotionnel exclusif QALEADOFFER pour bénéficier de 60 $ de réduction sur le prix total de la formation !

À lire également : 10 MEILLEURS OUTILS OPEN SOURCE DE GESTION DES TESTS