La complexité des entreprises ne cesse de croître, ce qui souligne la nécessité cruciale d'analyser et de comprendre méticuleusement leur environnement opérationnel actuel. Dans ce contexte, les décisions opérationnelles ne reposent plus uniquement sur des ensembles de données brutes ; elles sont plutôt guidées par les informations recueillies à partir de tableaux de bord, d'analyses, d'indicateurs clés de performance (KPI) et de graphiques. Par conséquent, l'impératif pour les décideurs consiste à placer une confiance inébranlable dans l'exactitude et la fiabilité de ces analyses et tableaux de bord.
Cette confiance peut être établie grâce à la gouvernance d'Analytics, également connue sous le nom d'AnalyticSops, qui englobe une suite de procédures, d'outils et de tâches opérationnels et administratifs, notamment des tests automatisés, la gestion du cycle de vie du contenu et une surveillance continue.
AnalyticsOps en 2024
En 2021, David Menninger de Ventana Research, dans son article Analytics Ops : le dernier kilomètre des opérations liées aux données a prédit que :
D'ici 2024, un tiers des organisations adopteront une approche des opérations analytiques similaire à leurs processus d'exploitation des données et intégrée à ceux-ci afin d'améliorer la réactivité et l'agilité.
Contrairement aux prévisions, AnalyticSops ne semble pas avoir atteint le même niveau de développement robuste et d'adoption généralisée que DevOps et DataOps. C'est peut-être parce qu'AnalyticSops nécessite une approche plus large que DevOps et DataOps. Néanmoins, rien ne justifie de retarder la mise en œuvre des tests automatisés pour les analyses.
Les tests sont certainement au cœur d'AnalyticSOPS et sont essentiels pour atteindre agilité. Une fois implémenté, il permet la validation automatique des tableaux de bord, des rapports et d'autres contenus de Business Intelligence (BI) en termes de précision, d'expérience utilisateur, de sécurité/d'autorisation, de performances et de régressions. Cela permet de réduire le nombre d'erreurs et de renforcer la confiance dans l'infrastructure analytique.
Analyses et tests de tableaux de bord
Les tests sont essentiels à la réussite de tout projet de développement logiciel, y compris les projets Analytics et Dashboard. Il valide la précision et la fiabilité des tableaux de bord et des outils d'analyse, essentiels pour les décideurs qui comptent sur eux pour leurs opérations quotidiennes.
Identifier et résoudre les problèmes le plus tôt possible est nettement plus efficace que de les autoriser
pour atteindre la production et avoir un impact sur les clients.
Défis liés aux Tests
Tester un tableau de bord est intrinsèquement complexe en raison de la nécessité de valider diverses visualisations telles que des graphiques, des tableaux, des graphiques et des images. De nos jours, l'utilisation intensive de l'intégration d'analyses et de tableaux de bord dans les applications existantes introduit des couches supplémentaires pour les problèmes potentiels. Et étant donné que ces problèmes peuvent se manifester à la fois au niveau technique et commercial, il devient de plus en plus difficile de trouver des personnes compétentes dans ces deux domaines.
Pour illustrer ces défis, voici une liste non exhaustive de plusieurs sources de problèmes potentiels qui nous aidera à identifier les tests requis pour les détecter :
- Problème de rendu : Les différences visuelles, bien qu'elles ne nuisent pas à la convivialité fonctionnelle, peuvent être gênantes et nuire à la qualité perçue des tableaux de bord. Ceux-ci peuvent se manifester par des étiquettes mal alignées, des graphiques surchargés, des combinaisons de couleurs incorrectes et d'autres anomalies de ce type.
- Problème de rendu lors de l'impression : Lors de l'impression, un tableau de bord adopte une mise en page qui n'est pas exactement identique à celle de son homologue de bureau, ce qui entraîne certains problèmes de rendu propres au format d'impression.
- Glitch fonctionnel : De telles erreurs entravent de manière significative l'utilisabilité fonctionnelle des tableaux de bord. Les exemples incluent un sélecteur de dates affichant des valeurs incorrectes, un filtre à sélection multiple fonctionnant comme une sélection unique, un graphique ne comportant pas la sélection nécessaire ou une fonction d'exploration détaillée dans un tableau, entre autres.
- Régression des données : les tableaux de bord peuvent rencontrer des problèmes lorsqu'ils n'utilisent pas les données correctes, souvent en raison de modifications imprévues de la source de données (telles que des mises à jour de la base de données ou des modifications des API des fournisseurs IoT), de problèmes dans le processus d'extraction, de transformation, de chargement (ETL) ou de facteurs similaires.
- Requête/Régression de calculs personnalisés : À l'instar de la régression des données et des erreurs de codage traditionnelles, les requêtes et les calculs personnalisés peuvent présenter un comportement erroné de manière inattendue.
- Tableaux de bord manquants : Au début, de telles erreurs peuvent sembler étranges ; toutefois, lors de la gestion d'une quantité considérable de tableaux de bord prédéfinis (et potentiellement générés automatiquement), il peut ne pas être immédiatement évident de garantir la disponibilité de tous comme prévu.
- Sécurité/Autorisation : La présence de différents profils de sécurité et niveaux d'autorisation des utilisateurs peut entraîner diverses erreurs, comme indiqué précédemment (par exemple, des tableaux de bord inaccessibles en raison de restrictions de droits d'accès, une régression des requêtes ou des calculs résultant de l'impossibilité d'accéder à certaines données, etc.).
- Régression des performances : Une augmentation imprévue du volume de données et/ou l'afflux d'utilisateurs accédant aux analyses ralentissent les requêtes, ce qui entraîne une lenteur inacceptable de l'ouverture et de l'affichage des tableaux de bord.
- Régression de la charge du système : Tout comme la régression des performances, cette forme de régression néglige de déterminer la capacité du système à résister à une augmentation du volume de données, du nombre d'utilisateurs et de facteurs similaires.
Cette complexité souligne l'importance de procédures de test approfondies pour garantir la précision et la fiabilité du tableau de bord et contribue probablement à la dépendance continue à l'égard des méthodes de test manuelles pour les tableaux de bord. Ce sentiment se retrouve dans les commentaires reçus des clients d'icCube demandant des conseils sur les tests automatisés pour améliorer la qualité de leurs tableaux de bord.
Tests Automatisés et Tests Manuels
Avant d'entrer dans les détails des différents types de tests, il convient de rappeler plusieurs raisons pour lesquelles les tests automatisés devraient être utilisés au profit des tests manuels autant que possible.
- Lent : Les tests manuels sont lents par nature : la rapidité avec laquelle un utilisateur peut interagir avec les tableaux de bord et exécuter les différentes étapes procédurales des tests est strictement limitée. Ceci est tout à fait pertinent car plusieurs cycles de test sont généralement nécessaires lorsqu'un problème est détecté. Il s'agit d'un facteur limitant la rapidité de mise sur le marché de la solution.
- Monotone : Les tests manuels peuvent être fastidieux et monotones, ce qui peut entraîner un manque de motivation chez les testeurs. Cette baisse d'enthousiasme nuit à la qualité globale du cycle de tests.
- Documentation : Les tests manuels nécessitent une documentation complète décrivant les différentes étapes des tests au niveau technique et commercial. La mise à jour de cette documentation constitue un défi, en particulier dans un environnement dynamique où le produit évolue rapidement.
- Erreur de données difficile à détecter : Certaines erreurs s'avèrent difficiles à détecter lors de tests manuels. Par exemple, l'identification de données non valides dans un graphique tabulaire peut s'avérer particulièrement ardue, en particulier lorsque les testeurs ne disposent pas des connaissances commerciales nécessaires pour détecter les incohérences dans les données.
- Travailleurs hautement qualifiés : Comme indiqué précédemment, les tests manuels nécessitent des compétences dans les domaines techniques et commerciaux. Les personnes possédant de telles compétences hautement spécialisées sont rares et sont souvent affectées à d'autres domaines de l'organisation, où leurs talents peuvent être appliqués à des projets plus créatifs et innovants.
- Coût élevé : Les facteurs susmentionnés contribuent collectivement à l'augmentation des coûts, car une main-d'œuvre importante est requise pour tester efficacement le produit.
- Sujette aux erreurs : Les testeurs manuels sont... humains et commettent donc des erreurs. Il est donc évident que les tests manuels sont sujets à des erreurs qui nuisent à la qualité globale des tests.
- Problème d'évolutivité : Les testeurs manuels n'ont pas la capacité de se répliquer eux-mêmes afin de simuler un nombre spécifique d'utilisateurs à des fins de tests de performance et de résistance. Ils ne peuvent pas non plus fonctionner en continu 24 heures sur 24, 7 jours sur 7, à moins que vous ne disposiez d'une armée d'agents ChatGPT à votre disposition ;-)
- Intégration du pipeline CI/CD : En fin de compte, l'intégration des tests manuels dans les pipelines DevOps et DataOps existants disponibles au sein de l'organisation représente un défi, entravant ainsi la réalisation du projet Dashboards and Analytics et affectant ses délais de mise sur le marché.
Tests Automatisés
Dans cette section, nous examinerons différents types de tests automatisés qui peuvent être utilisés pour résoudre efficacement chaque problème précédemment identifié. Bien que cette liste ne soit pas exhaustive, elle fournit des informations précieuses sur les mesures qui peuvent être prises pour améliorer la qualité du projet.
Projet Public Github
Reconnaissant la nécessité et la complexité des tests, iCCube a publié le IC3-Analytics-Ops projet sur GitHub avec les objectifs suivants en tête :
- licence permissive permettant de réutiliser et d'étendre à volonté,
- suffisamment flexible pour s'intégrer au pipeline CI/CD existant,
- tests de serveurs automatisés,
- tests automatisés de modèles de données,
- tests automatisés d'autorisation des données,
- tests de tableaux de bord automatisés.
Ce framework fournit les éléments de base nécessaires à la création de différents types de tests.
Tests Fonctionnels
Le testeur utilise les tableaux de bord comme le ferait un utilisateur, en vérifiant que l'application fonctionne comme prévu. Cyprès est l'outil choisi pour réaliser ce type de tests dans le cadre du projet. Les tests sont scénarisés en JavaScript, tirant parti d'un ensemble de fonctions d'assistance prédéfinies spécialement conçues pour tester les tableaux de bord générés par icCube. Ces fonctions sont déjà utilisées en interne par iCube pour tester l'application de tableau de bord elle-même.
Tests de Régression
Le testeur simule les actions des utilisateurs sur des tableaux de bord interactifs, en exécutant des requêtes pour confirmer les résultats attendus. Les tests sont scriptés de manière déclarative à l'aide du JSON 5 format de fichier. Le projet facilite la génération des résultats attendus, qui sont ensuite réutilisés pour garantir la non-régression. Les tests de non-régression pour le rendu visuel restent un domaine de développement continu. De plus amples détails seront fournis au fur et à mesure des progrès.
Tests de Performance
Lors des tests de données sans régression, le testeur peut valider les résultats basés sur le chronométrage afin de vérifier que les performances du système correspondent aux attentes. Cela peut inclure l'évaluation de mesures telles que les heures d'ouverture et d'impression des tableaux de bord, les durées d'aller-retour vers le serveur et des indicateurs de performance similaires.
Tests de Charges
Les tests, tels qu'ils sont exécutés par le testeur, désignent un ou plusieurs acteurs, chaque acteur étant assigné à un ensemble de tâches à exécuter. Ces acteurs fonctionnent de manière autonome dans leurs propres fils de contrôle, ce qui les rend parfaitement adaptés à la réplication sur une seule machine de test ou sur plusieurs machines de test. Cela permet de simuler une charge utilisateur importante, ce qui facilite l'exploration des limites de capacité du système. De plus, ces tests peuvent être effectués en continu, 24 heures sur 24, 7 jours sur 7, pour vérifier la stabilité du système, ce qui constitue un avantage supplémentaire.
Tests de Sécurité/Autorisation
Le testeur possède la capacité d'authentifier les utilisateurs à l'aide de diverses informations d'identification, garantissant ainsi que les résultats attendus correspondent à chaque profil d'autorisation. Dans le contexte actuel, ces tests revêtent une importance accrue, en particulier compte tenu de l'intégration poussée de l'analytique embarquée, qui contribue à la complexité de l'ensemble du système examiné.
Dev. contre QA. contre Prod. Tests Environnementaux
Le testeur ne se limite pas uniquement à l'environnement de développement ; il est impératif d'exécuter des tests dans tous les environnements, y compris le développement, l'assurance qualité et, idéalement, même dans l'environnement de production. Bien que les contraintes liées à l'accès aux données de production confidentielles puissent limiter certains types de tests, la réalisation d'au moins une forme de test de fumée est essentielle pour garantir une fonctionnalité de base du système. En outre, des efforts peuvent être déployés pour aider vos utilisateurs finaux à établir leurs propres scénarios de test.
Tests de Mise à Niveau/Migration
Grâce à des tests complets mis en œuvre et à une confiance accrue dans la qualité de l'application, vous serez plus enclin à mettre à niveau l'application pour proposer de nouvelles fonctionnalités aux utilisateurs finaux. Cela s'accompagne de l'avantage notable d'une réduction significative des délais de mise sur le marché. Ce changement peut changer la donne dans notre paysage concurrentiel en évolution rapide.
Conclusion
J'espère que vous êtes désormais convaincu que les tests automatisés (par opposition aux tests manuels) sont la clé du succès de votre projet de tableaux de bord et d'analyse et que vous pouvez les implémenter dès maintenant avec les outils existants.
Chez icCube, nous comprenons que la complexité des tests peut être intimidante. C'est pourquoi le Services de boutique d'analyse de données sont là pour vous aider, alors n'hésitez pas à nous contacter, nous serions ravis de vous aider.
Articles Medium
Les articles suivants de Medium fournissent une couverture détaillée et des points de vue intéressants sur cet article de blog,
Ils offrent un contexte supplémentaire aux lecteurs qui souhaitent approfondir le sujet :
- AnalyticsOps et tests automatisés sur les tableaux de bord
- Tester vos analyses et vos tableaux de bord
- Tester la charge de vos analyses et de vos tableaux de bord
- Analytiques/tableaux de bord : validation des mises à jour des versions