Aujourd’hui, toute solution de données de test doit être capable de répondre à des demandes de données d’un volume, d’une variété et d’une complexité plus importants, plus rapidement que jamais. Ce besoin souvent pressant n’est pas toujours pleinement apprécié par les organisations, mais se traduit par des conséquences négatives qui incluent :
- Des goulots d’étranglement croissants pour les tests.
- Une augmentation des échecs de tests erronés.
- Perte de productivité sur le SDLC.
- Monter les coûts d’infrastructure.
- Risques de conformité permanents.
De nombreux facteurs ont conduit à cette augmentation de la pression sur les services de données de test déjà sollicités. Cet article examine les tendances connexes qui ont accru la fréquence, le volume et la complexité des demandes de données de test effectuées aujourd’hui. Ces tendances nouvelles et en cours se répartissent en cinq grands groupes, qui doivent être pris en compte lors de la conception d’une solution de données de test robuste :
- La complexité des types de données interdépendants.
- Le rythme et l’ampleur des changements dans les systèmes, les environnements et les données de production.
- Un plus grand degré de parallélisation entre les tests et le développement.
- L’adoption de l’automatisation dans les tests et la nature changeante d’un « demandeur de données ».
- Évolution des exigences de conformité.
Le risque potentiel posé à la vitesse et à la qualité de livraison des logiciels par ces tendances connexes appelle à aller au-delà des pratiques obsolètes de « provisionnement » des données de test. Cela nécessite une solution automatisée, capable de répondre à la volée aux demandes de données de test nouvelles et évolutives. Cette capacité pour les équipes parallèles, les tests et les frameworks à s’auto-fournir des données à la demande est une différence clé entre les données de test La gestion (TDM) et automatisation des données de test (TDA).
Pour découvrir comment vous pouvez passer du TDM à la satisfaction des demandes de données à partir des pipelines DevOps à la demande, lisez le dernier chapitre de Curiosity dans le nouveau rapport Sogeti, État de l’IA appliqué à l’ingénierie de la qualité 2021-22. Mais d’abord, comprenons certains des facteurs qui ajoutent de la pression aux services de provisionnement des données de test déjà sollicités.
1. La complexité des sources de données interdépendantes
Aujourd’hui, une solution de données de test ne peut pas remplir de données isolées dans un nombre limité de bases de données et de types de fichiers. Les tests et le développement nécessitent plutôt des données riches et conformes qui couvrent systématiquement de nombreuses technologies héritées et de pointe.
Ces données intégrées et interdépendantes sont nécessaires pour l’intégration et les tests de bout en bout, mais ajoutent considérablement à la complexité des données nécessaires aux tests. Une série de tendances dans les logiciels d’entreprise et l’informatique ont conduit à une prolifération des types de données utilisés dans les organisations d’aujourd’hui. Ils comprennent:
- Le passage en cours d’une infrastructure héritée à une infrastructure Web et cloud.
- L’émergence du Big Data et de l’IA, ainsi que des technologies associées pour le stockage, l’analyse et le traitement des données. Cela inclut souvent des technologies open source comme Apache Hadoop, Spark, Kafka et Solr.
- L’adoption de nouveaux types de bases de données et de fichiers. Cela inclut les bases de données de graphes comme Neo4j, ainsi que l’adoption de bases de données qui ont émergé au 21st Century, comme MariaDB et Firebird.
- L’importance cruciale des API et des couches de messages aujourd’hui. Cela a conduit à la nécessité de créer des données de message telles que des fichiers XML, ainsi que des formats et des normes spécifiques à l’industrie.
- L’évolution continue de la technologie de Business Intelligence.
- L’adoption des microservices.
Alors que les organisations adoptent continuellement de nouvelles technologies, ces types de données émergents ne remplacent pas en gros les composants existants. Les migrations prennent du temps et peu d’entreprises ont le luxe de remplacer des éléments entiers de leur pile technologique en une seule fois.
Il est donc courant de trouver un mélange de types de données nouveaux et anciens utilisés dans différentes parties d’une entreprise. Par exemple, différentes parties d’une organisation peuvent utiliser des technologies modernes basées sur le cloud, tandis que d’autres utilisent des types de données propriétaires stockés sur des systèmes mainframe et milieu de gamme. L’ancien et le nouveau doivent généralement interagir et s’intégrer, en utilisant la gamme d’interfaces disponibles aujourd’hui :
Les tests actuels nécessitent des combinaisons intégrées de données couvrant un large éventail de technologies.
Toute solution de données de test doit donc généralement être capable d’analyser, de manipuler et de créer des données intégrées pour une gamme de technologies plus diversifiée que jamais. Il doit être équipé de connecteurs étendus et extensibles et doit être capable de créer des données intégrées sur différents fichiers, bases de données et applications en tandem.
La pluralité et la complexité des types de données ajoutent à la complexité des demandes de données effectuées aujourd’hui, car les testeurs et les développeurs ont besoin de données intégrées qui se connectent de manière transparente à un large éventail de technologies. Dans le même temps, le rythme et l’évolution des demandes de données augmentent, augmentant la vitesse et la diversité des demandes de données effectuées aujourd’hui.
2. Livraison itérative, développement logiciel agile et CI/CD
Plusieurs tendances à travers la livraison de logiciels ont augmenté le taux de changement dans les données nécessaires pour les tests et le développement, ajoutant une pression pour le provisionnement des données de test. Ces tendances ont accéléré le rythme et l’ampleur des changements dans les systèmes, les environnements et le comportement de production, exigeant des données de test nouvelles et de plus en plus diversifiées. Ils comprennent:
- La montée en puissance de la livraison itérative, dans laquelle les nouvelles versions et mises à jour arrivent en jours ou en semaines, plutôt qu’en mois ou en années.
- L’adoption de pratiques de développement logiciel agiles, en mettant l’accent sur les changements incrémentiels et la parallélisation.
- Automatisation accrue et nouvelles technologies dans les pipelines DevOps et CI/CD, permettant de développer en continu des changements rapides et de les intégrer dans les systèmes existants.
Chaque changement rapide rend les données existantes obsolètes et souvent obsolètes. Les données existantes peuvent ne pas correspondre à la dernière logique du système et aux structures de données. Pendant ce temps, des lacunes surviennent dans la couverture car les données historiques ne disposent pas des combinaisons de données nécessaires pour tester une logique nouvelle ou mise à jour. Alors que les lacunes dans la couverture des tests risquent d’engendrer des bogues, des combinaisons incohérentes ou invalides risquent d’entraîner des échecs de test et des goulots d’étranglement erronés.
Les trois tendances énumérées ci-dessus ont également augmenté le rythme et le volume des demandes de données, car chacune met l’accent sur des méthodes de travail parallèles. Une solution de données de test ne peut plus fournir des ensembles de données relativement statiques à un nombre limité d’équipes. Des données à jour doivent au contraire être mises à disposition de nombreuses équipes transverses et frameworks automatisés :
Aujourd’hui, les données de test doivent généralement être mises à la disposition de nombreuses équipes et frameworks en parallèle.
Toute solution de données de test aujourd’hui doit généralement être capable de rendre disponibles des données à jour et complètes au rythme auquel les équipes de développement parallélisées font évoluer des systèmes complexes. Les tests et le développement nécessitent des ensembles de données en constante évolution, disponibles en parallèle et à la volée. Les données à la demande doivent en outre être entièrement versionnées, capables de tester différentes combinaisons de composants système versionnés.
3. Conteneurisation, contrôle de source et code facilement réutilisable
Non seulement le rythme du changement du système s’accélère ; l’ampleur des changements apportés aux systèmes complexes aujourd’hui peut être plus grande que jamais. Cela présente un défi pour le provisionnement des données lent et trop manuel, car une partie importante des données peut nécessiter une mise à jour ou un remplacement en fonction des changements rapides du système.
Une gamme de pratiques de développement ont augmenté le taux et l’ampleur du changement du système. L’adoption de la conteneurisation, du contrôle des sources et des bibliothèques de code facilement réutilisables permet aux développeurs parallélisés d’extraire et de remplacer le code à la vitesse de l’éclair. Ils peuvent facilement déployer de nouveaux outils et technologies, en développant des systèmes qui sont désormais des toiles tissées de manière complexe de composants à évolution rapide.
Aujourd’hui, une solution de données de test doit être capable de fournir des « parcours » de données de test cohérents en fonction de l’impact considérable de ces changements sur les composants du système interdépendants. L’allocation des données doit se produire au rythme auquel les développeurs découpent et modifient les composants réutilisables et conteneurisés.
Cela nécessitera généralement un couplage plus étroit des exigences système, des tests et du code, identifiant rapidement les données nécessaires en fonction des modifications apportées à l’ensemble du SDLC. Sinon, des goulots d’étranglement et des erreurs de test surviendront car les testeurs et les développeurs ne disposent pas des données à jour dont ils ont besoin pour fournir des logiciels rigoureusement testés en de courtes itérations.
4. Automatisation des tests
L’automatisation des tests est un autre développement clé qui a augmenté le besoin continu de données à jour dans les tests et le développement.
L’automatisation de l’exécution des tests et CI/CD ont considérablement augmenté la vitesse et le volume des demandes de données. Les frameworks gourmands en données déchirent les données plus rapidement que les testeurs manuels ne le pourraient jamais, exécutant souvent de grandes suites de tests la nuit et le week-end. Les mêmes tests sont en outre généralement parallélisés, ce qui augmente la demande de données.
En plus d’augmenter la vitesse à laquelle les données sont requises, les tests automatisés aggravent encore les défis associés à un approvisionnement de données inexact. Les tests scriptés sont moins tolérants que les testeurs manuels, qui peuvent ajuster leurs tests si les données sont incomplètes, invalides ou épuisées. Un test automatisé échouera simplement si les données sont invalides, obsolètes ou manquantes. Cela ajoute aux goulots d’étranglement dans les tests et le développement, car les bogues mal identifiés lors des tests automatisés nécessitent une enquête.
L’automatisation des tests a changé la nature d’un demandeur de données de test aujourd’hui. Les solutions de données de test efficaces aujourd’hui devraient généralement fournir un accès à la demande aux testeurs et développeurs manuels, ainsi qu’à des technologies telles que les cadres d’automatisation des tests et les pipelines CI/CD. Les humains et les programmes doivent être capables de paramétrer et de déclencher des tâches de données de test à la volée. Il s’agit d’une autre différence clé entre la gestion des données de test traditionnelle et l’automatisation des données de test.
5. Évolution des exigences de confidentialité des données
La dernière série de développements qui ont compliqué et appelé à une révision des « meilleures pratiques » des données de test résident dans les exigences et les réglementations en matière de confidentialité des données.
Curiosity a beaucoup écrit sur les répercussions potentielles du règlement général de l’UE sur la protection des données (RGPD) pour les tests et le développement. Le RGPD de l’UE a déjà conduit les organisations à interdire l’utilisation de données de production brutes dans les tests, car elles s’efforcent de se conformer à des règles plus strictes régissant le traitement des données. Ces règles limitent souvent comment et quand les données peuvent être utilisées, par qui et pendant combien de temps.
Une législation telle que le RGPD de l’UE présente également des défis logistiques particuliers pour les meilleures pratiques traditionnelles en matière de données de test. Aujourd’hui, les organisations peuvent avoir besoin de localiser, copier et supprimer chaque copie des données d’une personne « sans délai ». Cela nécessite généralement un contrôle et une surveillance accrus de la manière dont les données sont utilisées dans les tests et le développement, ainsi que des mécanismes rapides et fiables pour localiser les données dans des environnements hors production. Souvent, une approche plus sûre et plus simple consiste à éviter de copier des informations sensibles vers des environnements de test et de développement moins sécurisés et moins contrôlés.
Bien que le RGPD de l’UE ait été un tournant pour la confidentialité des données à bien des égards, il ne s’agissait pas d’un développement isolé. Il reflète une orientation plus large des voyages à l’échelle mondiale, dans laquelle de nombreux pays ont adopté une législation comparable à celle du RGPD de l’UE.[i] Ces mesures législatives mondiales pourraient avoir des répercussions similaires sur l’utilisation des données dans les tests. Ils comprennent des lois telles que le RGPD britannique, le CCPA du Canada, le PDPB de l’Inde et le LGPD du Brésil.
L’évolution des exigences de confidentialité des données peut augmenter la complexité de la gestion des données de test, ainsi que le degré de contrôle global nécessaire sur les données dans les environnements de non-production. Les organisations qui ont déjà du mal à fournir des données suffisamment variées et volumineuses aux testeurs et…