Comment gérer les données de test pour des tests plus intelligents et plus rapides ?

Chaque organisation informatique effectue des tests, qu’il s’agisse de tests unitaires effectués par les développeurs, de tests d’Assurance Qualité (AQ) effectués par le personnel AQ ou de tests de régression entièrement automatisés. Dans chacune de ces techniques, un aspect largement sous-estimé est le rôle des données de test. Pourtant, l’efficacité avec laquelle ces données sont gérées a un impact direct sur le temps consacré aux tests et sur la qualité des résultats. Nous allons voir pourquoi les données de test peuvent être difficiles à gérer, quelles sont les meilleures pratiques basées sur notre expérience et quels avantages tangibles vous pouvez tirer d’un ensemble cohérent de données de test.

1. Pourquoi les données de test sont-elles importantes ?

Parlons d’abord de la fondation des tests, l’ensemble des données de test. Tout le monde comprend qu’il est indispensable de disposer de données à tester, mais comment gérer ces données ? Trop souvent, je vois des employés tester des données qui deviennent de plus en plus altérées au fur et à mesure que les tests progressent, ce qui entraîne des frictions dans le processus de test. Lorsqu’un test échoue ou ne produit pas les résultats escomptés, les utilisateurs doivent déterminer si ces résultats erronés ont été causés par les modifications du programme qu’ils testent ou au contraire par des données qui sont mauvaises ou qui se modifient pendant le test. Le plus souvent, ils signalent un défaut à un développeur, qui doit ensuite essayer de reproduire l’erreur, ce qui est impossible s’il utilise un “meilleur” ensemble de données. Vous pouvez facilement voir comment de mauvaises données peuvent avoir un effet boule de neige et faire perdre du temps aux tests. Alors comment gérer les données pour que les tests restent efficaces ?

Avant de nous pencher sur les données, examinons de plus près les tests eux-mêmes. Il convient de distinguer deux grands types de tests, les tests unitaires et les tests fonctionnels (couramment utilisés pour les tests de régression). ARCAD a de l’expérience avec les deux types (puisque nous avons des outils pour les deux) mais nous ne sommes pas ici pour parler de nos outils mais de l’un des aspects les plus critiques d’un bon test : de bonnes données. Nos outils ont la même dépendance que tout autre test : mauvaises données = mauvais tests.

2. Les données de test sont importantes, même pour les tests unitaires !

Les tests unitaires sont normalement très granulaires et consistent à appeler un programme ou une procédure avec un ensemble de valeurs de paramètres et à vérifier les valeurs correctes des paramètres de retour. Cependant, certains programmes peuvent enchaîner sur des fichiers pour valider ou lire des données supplémentaires avant de renvoyer des valeurs. Ainsi, alors que les tests unitaires ne sont normalement pas considérés comme dépendant des données, dans certain cas (et notamment avec les applications legacy développées sur la plateforme IBM i), nous rencontrons des programmes monolithiques qui ont de nombreuses fonctions business derrière les paramètres d’entrée et de sortie. Si vos programmes ne disposent pas de données cohérentes à consommer pendant les tests unitaires, vous risquez de ne pas obtenir de résultats cohérents. Les outils de test unitaire ont souvent une disposition pour que les données qui seront consommées par le programme puissent être mises à jour avant l’exécution du test unitaire. Si ce n’est pas le cas, ils peuvent être scriptés pour prendre en charge ces données. Cependant, la mise en place d’une telle disposition prend du temps et peut nécessiter des compétences techniques pour la mise à jour d’un fichier pour le test unitaire.

3. La cohérence des données est la base des tests de régression fonctionnels

Les tests fonctionnels sont basés sur l’exécution de fonctions business au niveau de l’utilisateur, tout comme les cas de test qui sont développés pour tester et vérifier qu’une fonction spécifique fonctionne correctement. Les tests fonctionnels sont souvent scriptés ou exécutés et enregistrés dans un outil (comme Arcad Verifier) et les résultats sont vérifiés pour s’assurer de la cohérence des valeurs. Une fois ces tests fonctionnels développés, ils peuvent être réutilisés à l’infini pour les tests de non-régression, dans lesquels un ou plusieurs tests fonctionnels sont exécutés afin de valider le fonctionnement normal de l’application après une mise à jour dans l’environnement de test. Cette technique est très dépendante de la cohérence des données afin que les tests fonctionnels renvoient des résultats cohérents et réussissent.

Si les données changent en raison de l’exécution d’autres processus pendant l’exécution des tests scriptés, un faux positif peut se produire et être interprété comme un échec. Donc, ici encore, des données cohérentes = des résultats cohérents et permettent un niveau d’automatisation beaucoup plus élevé. L’importance de disposer d’un ensemble dédié de données de test devient encore plus évidente.

4. Comment garantir la confidentialité des données de test – et les actualiser en cas de besoin ?

La raison la plus courante pour laquelle les entreprises ne disposent pas de plusieurs ensembles de données de test est que le point de départ est constitué par les données de production qui peuvent contenir des millions d’enregistrements et/ou des données sensibles. ARCAD dispose d’un outil permettant de gérer ce cas de figure (DOT Anonymizer), mais il s’agit là d’un autre sujet et nous sommes ici pour parler de la gestion de ces données à votre avantage. Si vous construisez un bon ensemble de données de test suffisamment volumineux pour prendre en charge tous vos cas de test, mais pas plus, il peut contenir des données sensibles qui ont une grande valeur pour votre organisation et qui nécessitent d’être masquées ou traitées avec précaution. Il est recommandé de disposer d’une copie de ces données pour actualiser les environnements d’AQ, idéalement dans un SAVF, afin qu’elles ne puissent pas être mises à jour par inadvertance. Il est également possible de créer une fonction pour actualiser ces données à partir de la production (ou d’utiliser un outil ARCAD), ce qui permettra également d’actualiser les données de test avec des données de production plus récentes. Quelle que soit la méthode utilisée, lorsqu’un ensemble de données de test est corrompu, il est facile de l’actualiser avec de bonnes données et, dans le cas de l’automatisation, avec des valeurs cohérentes.

Cette capacité à actualiser automatiquement les données est précieuse pour tous les tests que vous effectuez, même les tests unitaires pilotés par les développeurs qui peuvent dépendre de données lues dans des fichiers. Il est certain que les tests fonctionnels effectués par le service d’AQ doivent pouvoir actualiser facilement leurs données, car ils essaient de découvrir des bugs qui pourraient corrompre leurs données de test pendant la phase de test. Même l’utilisation d’outils de test qui gèrent les mises à jour de données par le biais d’un processus de retour en arrière peut laisser des données erronées si le personnel d’AQ rencontre une erreur importante et que le processus de script de test est interrompu.

5. Pour conclure : le test continu (CT) a besoin de données cohérentes !

Nous avons vu que de bonnes données cohérentes sont essentielles à toutes les formes de tests et nous devrions pouvoir les restaurer facilement lorsqu’elles sont corrompues. C’est un bonus si ce processus peut également être utilisé pour actualiser les données existantes avec des valeurs plus actuelles ou plus réalistes. Nous avons besoin de plusieurs ensembles de données pour soutenir des efforts de test simultanés sans conflit. Ces ensembles de données doivent donc être un sous-ensemble des données de production complètes. Ceci constitue le fondement de notre méthodologie de test et la base même de l’automatisation des tests.

Des données cohérentes fournissant des résultats cohérents signifient que non seulement les cas de test peuvent être scriptés, mais aussi que les défauts peuvent être détectés automatiquement lors d’une exécution de test automatisée. Cela se traduit par une réduction considérable des actions manuelles, des résultats plus rapides et un coût global moindre. Il s’agit d’une condition préalable souvent ignorée pour un véritable test continu et un cycle DevTestOps optimisé.