Lors d’une formation sur les fondamentaux des tests, un participant me demande ce que veut dire faire les tests de logiciels pour la « Data ».
Pour répondre, je pars d’un cas d’école simple : l’investigation d’un dataset (jeux de données) sur des films. Il me permet de mettre en évidence quelques types[1] et niveaux de tests[2] qu’on pourrait avoir pour la « Data » sur un cas concret.
En effet, le terme « Data » est générique et peut avoir plusieurs significations. De plus, nous testons en général pour réduire le risque de défaillance d’un logiciel en fonctionnement dans un contexte donné et pour des cas d’utilisation précis. Il est donc nécessaire de prendre un cas bien défini.
Investiguer le dataset
J’explore donc un dataset qui contient des informations sur dix mille films extraits de la base de données TMDb (The Movie Database). Mon objectif est de répondre à des questions métiers comme : quelles sont les particularités des films à hauts revenus ? quelles sont les propriétés communes des films impopulaires ?
En réalité, ce dataset est un fichier csv de données. Je décide d’en faire l’acquisition, la transformation, le chargement et le reporting via Jupyter notebook dans lequel j’écris et exécute des scripts Python. Cet ensemble représenterait le système à tester. Il faut noter que Jupyter notebook – en tant que logiciel – constitue de fait un sous-système existant que je ne teste pas en particulier. Ainsi, mon approche pour répondre aux questions, est de faire via le notebook, une analyse exploratoire qui vient après une phase plus importante de traitement et de transformation des données.
Pour appréhender le sens des tests, je propose de voir ce système sous l’angle de différents domaines d’intervention :
- Les données à la source,
- Le chargement et la transformation,
- La visualisation de données.
Les données à la source
Le dataset sous forme de fichier csv est une partie importante du système à tester. En effet, la pertinence des résultats de l’analyse dépend de sa qualité. Celle-ci est souvent précisée dans les exigences clients. C’est ainsi que vérifier sa qualité, fait en réalité partie des tests fonctionnels. C’est ce que je fais, par exemple, dans la partie « Data Assessing and Inspection » du notebook.
Le chargement et la transformation des données
Une perspective du système permettrait de voir :
- Un système source : c’est celui présenté plus haut mais sans les scripts Python et les résultats de transformation et visualisations qui en résulteraient.
- Un système cible : le même que précédemment, mais cette fois-ci avec tous les scripts et les résultats – y compris les visualisations.
Pour la « Data », les tests d’intégration s’appliquent en général au flux de données qui vont du système source vers le système cible. Or ici, nous créons le système cible en exécutant les blocs de scripts Python écrits dans le notebook. Par conséquent, les tests d’intégration ne peuvent s’appliquer dans ce cas particulier. Parfois, des scripts Python du notebook font appel (via un services web par exemple) à d’autres composants logiciels externes créés dans le cadre du projet. Il peut s’agir de traitements de données spécifiques ou d’accès à des sources de données externes. Dans ce cas nous faisons des tests d’intégration entre deux composants, de façon classique. Ces tests concernent par exemple le service web qui sert d’interface.
D’un autre point de vue, la transformation des données pourrait faire partie des tests de composants (ou tests unitaires). En effet, des composants individuels – ici des blocs de scripts Python – sont développés et exécutés dans un notebook pour la transformation des données. C’est l’équipe de développement qui écrit les tests de composants individuels développés pour la transformation des données. C’est par exemple ce que je fais systématiquement avec des blocs « assert » dans ce notebook « Identify Customer Segments » (Utilisation de techniques d’apprentissage non supervisées pour identifier des segments dans une population).
Lorsque j’exécute le notebook tout entier[3], je fais un test système. En effet, le système part des données brutes pour – à travers différentes transformations – présenter les réponses aux questions métiers initiales.
Pour le traitement de données d’envergure, on peut avoir une équipe de test distincte qui validera les règles fonctionnelles de transformation des données au niveau des tests du système.
Imaginons que en tant que développeur et/ou testeur, je fais une ou plusieurs exécutions successives du notebook tout entier avec un client. Il s’agit de celui qui attend les résultats de l’exploration de données. Nous serions alors dans une situation de tests d’acceptation. Le client validerait les résultats et réponses obtenues – en général via des visualisations – sur la base d’exigences entendues au préalable.
La visualisation
Pour la visualisation des données, les tests reviennent à observer ou interagir avec les éléments visuels créés (graphes, « dashboard » par abus de langage) tel que l’utilisateur final le ferait. Ces tests de « reporting » peuvent être faits selon des spécifications d’exigences de visualisation. Nous serions alors dans une situation de tests fonctionnels qui sont faits comme tests système puis tests d’acceptation. Dans le cas particulier de diagrammes ou graphes qui ne sont pas interactifs, et dont il faut vérifier la conformité par rapport à des exigences, on peut parler de revue comme dans le cas de tests statiques.
A tout cela, je rajouterais quelques idées de tests non fonctionnels qu’on voit souvent quand il s’agit de « Data »:
- Les tests de performance : utiliser un outil pour simuler plusieurs utilisateurs qui génèrent en simultané et à intervalles réguliers plusieurs rapports et visualisations. Ces tests peuvent permettre de vérifier le délai (ou « lead time ») de génération des visualisations, ou encore la consommation mémoire du système.
- Les tests de sécurité : dans certaines situations, les transformations et visualisations ne peuvent se faire qu’après un traitement spécifique pour protéger les données sources : c’est l’anonymisation[4]. Le testeur est celui qui vérifie – sur la base ou non de spécifications – que les données sont anonymisées de la bonne manière.
Tester pour la « Data » diffère d’un projet de test ordinaire à plusieurs égards : la maîtrise du vocabulaire spécifique à la « Data », une bonne perspective de l’objet à tester, la connaissance de domaines d’intervention comme la visualisation et la transformation de données.
La hiérarchisation grandissante des données de la « Data » aujourd’hui exige des techniques de pointe pour des données toujours fiables. C’est pour cette raison que de plus en plus de professionnels se forment sur la qualité logicielle pour la « Data ».
Découvrir comment maîtriser la qualité des projets Data et Analytics[1] Les types de test sont : les tests fonctionnels, non-fonctionnels, boîte-blanche et les tests liés aux changements.
[2] Il existe quatre niveaux de test : test de composants, test d’intégration, test système et test d’acceptation.
[3] Exécuter un notebook revients à exécuter l’ensemble des cellules de ce notebook, comme expliqué à la Figure 5 ici : https://python.sdv.univ-paris-diderot.fr/18_jupyter/
[4] Il existe des outils spécifiques pour anonymiser les données, comme par exemple : http://www.ihsn.org/software/disclosure-control-toolbox
Laisser un commentaire