Améliorez la qualité logicielle et gagnez du temps avec les tests d’infrastructure

Les choses les plus banales—codes d’accès ou cartes magnétiques pour entrer dans les bâtiments—peuvent devenir critiques si elles ne sont pas en place.

L’infrastructure, dans toute sa diversité, existe pour soutenir le développement, le test, le déploiement et l’exploitation de vos systèmes. Elle est soit essentielle aux tests, soit nécessite d’être testée.

Nous passerons en revue les outils de développement, de test et de collaboration dans le prochain article. Dans celui-ci, nous allons considérer ce que la plupart des gens appellent environnements de test et jeter un bref regard sur ce qu’on appelle souvent les tests d’infrastructure. J’aborderai :

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

C’est parti.

Environnements de test

Toute activité de test repose sur une hypothèse implicite, essentielle 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 ait du sens, 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 des scénarios de test qui repoussent les capacités des systèmes en termes de fonctionnalités, de performance ou de sécurité, par exemple, mais ce sont là des propriétés des tests, non de l’environnement.

Un environnement réaliste répliquerait tous les contextes métier, techniques et organisationnels. Une grande partie comprend les données utilisées pour piloter les processus métiers, configurer le système et fournir des données de référence.

Mais des environnements parfaitement réalistes sont généralement impraticables ou bien trop coûteux (même les testeurs de systèmes à très haute criticité comme les avions, les réacteurs nucléaires ou les scanners cérébraux doivent faire des compromis à un moment ou à un autre). Presque tous les tests sont donc réalisés dans des environnements qui simulent le monde réel avec un degré de compromis acceptable.

Les voitures sont testées sur des bancs à rouleaux, dans des tunnels aérodynamiques, sur des plateformes de vibration et sur des pistes d’essai privées avant d’être testées sur route ouverte. Les systèmes informatiques sont testés dans des laboratoires logiciels par des programmeurs et testeurs avant que les utilisateurs finaux ne les expérimentent dans un environnement proche de la production.

Pour garantir que vos environnements de test soient conformes aux standards du secteur, pensez à intégrer l’une de ces solutions de gestion de test les mieux notées.

JOIN THE COMMUNITY

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Sign up with LinkedIn

Or sign up with email:

Instagram

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

Tester dans des environnements réalistes

Les environnements simulés sont faillibles, comme nos exigences et nos modèles de test, mais il faut composer avec cela.

Nous devons planifier des tests représentatifs dans les environnements dont nous disposons, et la signification des résultats de test dépend de notre interprétation.

La fiabilité des résultats de test dépend de l’environnement dans lequel les tests sont exécutés. Si un test est effectué 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.

Bien entendu, ces deux situations sont hautement indésirables.

Mise en place et livraison des environnements à temps

Même avec l’essor de l’infrastructure cloud, il peut être difficile et coûteux de mettre en place et de maintenir les environnements de test.

Lorsque les équipes de support travaillent sur le nouvel environnement de production, les testeurs réclament des environnements de test (et parfois plusieurs d’entre eux). Plus tard lors des tests, les équipes de support sont souvent confrontées à des demandes concurrentes.

Les environnements pour les développeurs ou toute activité de test ultérieure peuvent être livrés en retard ou pas du tout, ou ne pas être configurés ni contrôlés comme requis. Inévitablement, cela retardera les tests et/ou sapera la confiance dans tout résultat de test.

Une tâche critique consiste à établir le besoin et les exigences d’un environnement destiné aux tests, en incluant un mécanisme de gestion des changements dans cet environnement—dès que possible.

L’infrastructure sous forme de code est une évolution récente dans la manière dont des environnements peuvent être construits, avec des outils suivant des procédures et utilisant du code déclaratif pour définir la mise en place de l’environnement. 

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

Lors de la mise en place de votre infrastructure de test, il est crucial d'intégrer un logiciel de gestion de base de données fiable pour des performances optimales

Cependant, une fois mis en place, ils offrent un moyen très efficace de création d’environnements. Le code d’infrastructure peut être géré dans un système de gestion de source exactement comme tout code applicatif et être géré lors des changements.

Un principe fondamental de la livraison continue est que, le plus tôt possible, un logiciel—même s’il n’a aucune utilité—doit être envoyé dans le pipeline de livraison pour prouver que les processus fonctionnent. 

Bien sûr, cela nécessite des environnements viables pour les builds, des outils d’intégration continue, les tests au niveau système et le déploiement. L’objectif est de pouvoir déployer des environnements de test et de production sans contrainte. Une fois que la définition des environnements et les processus de déploiement sont en place, la génération d’environnements devient une tâche automatisée et routinière.

Dans tous les cas, les définitions de ces environnements constituent un livrable initial du projet.

Environnements de développement

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

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

La gamme des outils de développement, des plateformes et des soi-disant Environnements de Développement Intégrés (IDE) est immense. Dans cet article, nous n’aborderons que quelques-unes des principales exigences et fonctionnalités en matière de test des environnements.

Pour soutenir le développement et les tests relevant des développeurs, les environnements doivent permettre les activités suivantes. Ce n’est qu’une sélection—il peut y avoir d’autres activités ou des variantes selon votre situation :

• Un environnement de « bac à sable » pour expérimenter avec de nouveaux logiciels. Les bacs à sable servent souvent à tester de nouvelles bibliothèques, à développer du code prototype jetable ou à s’exercer à des techniques de programmation. Tous les langages de programmation courants disposent de centaines, voire de milliers de bibliothèques logicielles. Les bacs à sable servent à installer et tester des logiciels ne faisant pas encore partie du fil principal de 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 maintiennent une copie locale d’un sous-ensemble ou de la totalité du code source de leur application à partir d’un référentiel partagé, et peuvent générer des versions système pour des tests locaux. Cet environnement permet aux développeurs d’apporter des modifications au code sur leur copie locale et de tester leurs changements. Certains tests sont ad hoc et ne sont peut-être jamais reproduits. D’autres tests sont automatisés. Les tests automatisés sont généralement conservés définitivement, en particulier s'ils suivent une approche de développement pilotée par les tests.
• Environnement d’intégration partagée (continue). Lorsque les développeurs estiment que leur code est prêt, ils poussent leurs modifications dans le référentiel partagé et contrôlé. L’environnement CI effectue des builds automatisés et exécute des tests automatisés en utilisant le référentiel. À ce stade, le nouveau code ou le code modifié est intégré et testé. Le système CI lance les tests automatisés à la demande, toutes les heures ou tous les jours, et toute l’équipe reçoit des notifications et peut voir le statut des tests du dernier build intégré. Les échecs sont rapidement exposés et traités en priorité.

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

Si ces systèmes d’interface n’existent pas parce qu’ils n’ont pas été construits, ou parce qu’ils appartiennent à une entreprise partenaire et qu’il n’existe qu’un système en production sans version de test, alors les développeurs doivent étayer 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 peuvent généralement pas prendre en charge les tests nécessitant des données intégrées entre plusieurs systèmes.

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

Les bases de données de développement partagées au sein d’une équipe sont généralement peu satisfaisantes. S’il n’existe pas un bon système de gestion de cette ressource partagée, les développeurs risquent de 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 des composants et des sous-systèmes en collaboration. 

Ces environnements offrent une plateforme permettant de soutenir les objectifs d’intégration à grande échelle, de validation fonctionnelle et d’exploitation du système dans le contexte des processus utilisateurs ou métier.

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

L’un des pièges les plus courants des tests est lorsqu’un testeur de système rencontre dans son environnement un type d’échec que, malgré tous leurs efforts, le développeur ou testeur ne parvient pas à reproduire dans l’environnement de développement.

Cela est presque toujours causé par un manque de cohérence entre les deux environnements. La différence de comportement peut provenir de la configuration, d’une différence de version logicielle ou bien de la différence des données de la base de données.

Les différences de données causant des problèmes sont la première chose à vérifier. Elles sont généralement faciles à identifier et se résolvent souvent rapidement.

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

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

L’infrastructure as code et le provisionnement automatisé des environnements rendront les problèmes d’incohérence des environnements obsolètes.

Types d’environnements de test dédiés

Pour soutenir les tests système, d’acceptation et non fonctionnels, les environnements doivent permettre les activités suivantes (il peut y en avoir d’autres selon votre organisation) :

• (Fonctionnelle) Environnement de test système. Dans cet environnement, le système est validé par rapport aux exigences documentées pour l’ensemble du système. Les exigences peuvent être de longs documents textuels avec des cas de test tabulés 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. Lorsque l’environnement d’intégration continue permet l’intégration des composants avec des sous-systèmes, les processus métiers peuvent nécessiter la disponibilité d’autres systèmes interfacés (non contrôlés par les développeurs). Des environnements à grande échelle sont nécessaires pour réaliser des tests d’intégration à grande échelle, de processus métier ou d’acceptation globale. Habituellement, les données sont une copie de la production, ou du moins à une échelle appropriée. Lorsque l’intégration à grande échelle doit être prouvée, les flux de données et de contrôle sont exercés à travers des parcours utilisateurs étendus et des 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, pensez à optimiser vos capacités de gestion de données avec des outils avancés de gestion de tests conçus pour Jira.
• Environnement de performance. Ces environnements doivent offrir une plateforme pertinente pour évaluer les performances d’un système (ou des sous-systèmes sélectionnés). Des compromis dans l’architecture peuvent être possibles en cas de redondance ou de clonage de serveurs. Cependant, les volumes de données doivent être à l’échelle de la production même si les données sont synthétiques. Bien entendu, l’environnement doit être dimensionné pour supporter les volumes de transactions en production afin de permettre une prédiction fiable des performances des systèmes en production.
• Environnements de Disponibilité, Résilience et Gestion (DRG). À certains égards, ces environnements sont similaires aux environnements de performance, mais selon l’objectif du test, des variations peuvent être inévitables. Les tests de disponibilité visent à vérifier que le système peut fonctionner pendant de longues périodes sans défaillance. Les tests de résilience (souvent appelés tests de basculement) vérifient que lorsqu’un composant du système échoue, cela ne provoque pas de perturbation inacceptable du service fourni. Les tests de gestion ou d’opération visent à démontrer que les procédures administratives, de gestion, de sauvegarde et de restauration du système fonctionnent efficacement.

Données dans les environnements

Dans certains très grands projets, il peut y avoir jusqu’à 20 ou même 30 environnements à grande échelle dédiés à différents aspects – tests, formation, migration de données, et essais de bascule. Dans les projets plus petits, il y en aura moins, parfois seulement un environnement partagé ou un régime de livraison continue—et tous les tests pourraient être automatisés dans des environnements créés pour une seule utilisation, puis détruits.

Tous les environnements ont besoin de données, mais l’échelle et le réalisme de ces données peuvent varier. Voici quelques schémas courants sur la façon dont les données de test sont acquises et gérées. Ces schémas se concentrent sur la propriété (locale ou partagée), le mode de création (manuelle, automatisée ou copiée de la production) et l’échelle :

• Données locales, créées manuellement, à petite échelle—adaptées aux tests ad hoc réalisés par les développeurs ou les testeurs.
• Données locales, automatisées, synthétiques. Adaptées aux tests automatisés des développeurs ou environnements où la fonctionnalité de modules ou fonctionnalités spécifiques peut être couverte.
• Données partagées, créées manuellement. Utilisées dans les environnements d’intégration et de test système, souvent lorsque les données de test ont évolué en parallèle avec des tests manuels. Sauvegardées et restaurées si besoin.
• Données partagées, créées automatiquement. Utilisées dans les environnements d’intégration et de test système où les données de test ont évolué en parallèle avec des tests automatisés ou manuels. Générées et/ou restaurées à partir des sauvegardes, si besoin.
• Données partagées, synthétiques/aléatoires à grande échelle. Les tests de performance et de DRG nécessitent des données cohérentes en grand volume. Ces données n’ont généralement pas besoin d’être significatives—des données aléatoires suffisent et sont générées à la demande, ou créées initialement puis restaurées depuis une sauvegarde.
• Données partagées, significatives à grande échelle. Les tests de bout en bout, d’acceptation ou utilisateurs nécessitent généralement des données significatives à l’échelle. Parfois, des copies ou des extractions des données réelles sont utilisées. Attention à ne pas enfreindre la réglementation sur les données si vous ne les brouillez ou anonymisez pas.
• Re-testing et tests de régression. Vous aurez besoin d’un jeu de données connu, contrôlé, dans un état connu, il est donc généralement restauré depuis une sauvegarde. Cela vaut pour tous les environnements précédents puisque ces tests doivent être rejoués avec des données dans un état connu afin de reproduire les échecs de façon fiable.

Tests d’infrastructure

Au début de cet article, nous avons évoqué ce que recouvre l’infrastructure et, depuis lors, nous nous sommes principalement concentrés sur les composants techniques, c’est-à-dire les systèmes logiciels, en supposant que le matériel—réel ou virtuel—est disponible.

Lorsque nous créons des systèmes initialement, nous partons du principe que l’infrastructure existe, qu’elle fonctionne correctement, est performante, sécurisée, résiliente, etc.

Nous pouvons tester tous ces aspects lorsque l’application est intégrée, et il ne fait aucun doute que nous découvrirons des lacunes dans l’infrastructure à un stade relativement tardif de nos projets. Mais découvrir des problèmes d’infrastructure aussi tard dans un projet est généralement extrêmement perturbant.

• Des modifications pour pallier des défaillances de l'infrastructure peuvent nécessiter une refonte significative et des changements importants dans notre application.
• Les résultats provenant de nos tests d'application ou de système complet devront être répétés.
• Si des composants tiers tels que les services de bases de données, web, réseau ou messagerie échouent, nous sommes dépendants des fournisseurs (ou de la communauté open source) qui les prennent en charge.

Pour garantir que notre confiance dans les composants d'infrastructure soit fondée, nous pouvons nous appuyer sur notre expérience (ou celle d'autres) de leur utilisation passée. Sinon, nous devons évaluer—via des tests—leur fiabilité avant de nous engager à les utiliser dans la conception et la réalisation de notre système.

Selon l'infrastructure examinée, l'environnement utilisé peut varier—d'un serveur unique à une plateforme d'infrastructure quasi-complète. 

Bien que certains tests soient manuels, la plupart du temps nous utiliserons des outils, pilotes ou robots pour simuler la charge transactionnelle que notre application générerait. Il sera nécessaire de simuler ou de remplacer ces interfaces :

• Interfaces actuellement non disponibles
• Interfaces de composants auxquels nous faisons confiance et qui sont simples à simuler
• Interfaces hors du périmètre qui n’ont pas d’impact sur l’infrastructure testée.

L'infrastructure, inutile de le préciser, ne fonctionne généralement pas via une interface utilisateur ou graphique.

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

Les objectifs de performance et ARM peuvent être connus, auquel cas des tests peuvent être menés afin de s’assurer que ces objectifs sont atteints.

Cependant, l’infrastructure est souvent partagée avec d’autres applications que la nôtre, il est donc important de connaître sa capacité maximale afin d’estimer la capacité restante lors du déploiement de notre application.

Dans ce cas, les tests d’infrastructure répondent au risque encouru par notre application, voire d'autres, susceptibles de s’appuyer sur elle à l’avenir. 

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

Lecture suggérée : 10 MEILLEURS OUTILS OPEN SOURCE DE GESTION DES TESTS