AnalyticsOps und automatisierte Dashboard-Tests

Marc Polizzi
Marc Polizzi
July 30, 2024

Unternehmen erleben eine ständige Zunahme der Komplexität, was die entscheidende Notwendigkeit unterstreicht, ihre aktuelle Betriebslandschaft sorgfältig zu analysieren und zu verstehen. In diesem Umfeld hängen betriebliche Entscheidungen nicht mehr ausschließlich von Rohdatensätzen ab. Stattdessen basieren sie auf den Erkenntnissen, die aus Dashboards, Analysen, Leistungskennzahlen (KPIs) und Diagrammen gewonnen werden. Daher ist es für Entscheidungsträger unerlässlich, unerschütterliches Vertrauen in die Genauigkeit und Zuverlässigkeit dieser Analysen und Dashboards zu setzen.

INHALTSVERZEICHNIS
Eine Gruppe von Robotern, die Dashboards testen
Technologie
Alle

Unternehmen erleben eine ständige Zunahme der Komplexität, was die entscheidende Notwendigkeit unterstreicht, ihre aktuelle Betriebslandschaft sorgfältig zu analysieren und zu verstehen. In diesem Umfeld hängen betriebliche Entscheidungen nicht mehr ausschließlich von Rohdatensätzen ab. Stattdessen basieren sie auf den Erkenntnissen, die aus Dashboards, Analysen, Leistungskennzahlen (KPIs) und Diagrammen gewonnen werden. Folglich ist es für Entscheidungsträger unerlässlich, unerschütterliches Vertrauen in die Genauigkeit und Zuverlässigkeit dieser Analysen zu setzen und Dashboards.

Dieses Vertrauen kann durch Analytics Governance, auch bekannt als AnalyticsOps, hergestellt werden, das eine Reihe von betrieblichen und administrativen Verfahren, Tools und Aufgaben umfasst, darunter automatisierte Tests, Content Lifecycle Management und kontinuierliche Überwachung.

AnalyticsOps im Jahr 2024

2021 schrieb David Menninger von Ventana Research in seiner Arbeit“Analytics Ops: Die letzte Meile der Datenoperationen“ hat vorausgesagt, dass:

Bis 2024 wird ein Drittel der Unternehmen einen analytischen Betriebsansatz verfolgen, der ihren Datenbetriebsprozessen ähnelt und in diese integriert ist, um die Reaktionsfähigkeit und Agilität zu verbessern.

Entgegen den Prognosen scheint AnalyticsOps noch nicht das gleiche Niveau an robuster Entwicklung und breiter Akzeptanz erreicht zu haben wie DevOps und DataOps. Möglicherweise liegt das daran, dass AnalyticsOps im Vergleich zu DevOps und DataOps einen breiteren Ansatz erfordert. Dennoch gibt es keine Rechtfertigung dafür, die Implementierung automatisierter Tests für Analysen zu verzögern.

Natürlich steht das Testen im Mittelpunkt von AnalyticsOps und ist von entscheidender Bedeutung für das Erreichen Agilität. Nach der Implementierung ermöglicht es die automatische Validierung von Dashboards, Berichten und anderen Business Intelligence (BI) -Inhalten auf Genauigkeit, Benutzererfahrung, Sicherheit/Autorisierung, Leistung und Regressionen. Dies führt zu weniger Fehlern und fördert das Vertrauen in die Analyseinfrastruktur.

Analytik und Dashboard-Tests

Testen ist entscheidend für den Erfolg jedes Softwareentwicklungsprojekts, einschließlich Analytics- und Dashboard-Projekten. Es bestätigt die Genauigkeit und Zuverlässigkeit der Dashboards und Analysetools, die für Entscheidungsträger, die sich bei ihrer täglichen Arbeit auf sie verlassen, unerlässlich sind.

Eine schematische Ansicht, wie das Testen funktioniert

Probleme so früh wie möglich zu erkennen und anzugehen, ist deutlich effizienter als Probleme zuzulassen

um die Produktion zu erreichen und Kunden zu erreichen.

Herausforderungen beim Testen

Das Testen eines Dashboards ist von Natur aus komplex, da verschiedene Visualisierungen wie Diagramme, Tabellen, Grafiken und Bilder validiert werden müssen. Heutzutage werden durch die umfangreiche Einbettung von Analysen und Dashboards in bestehende Anwendungen zusätzliche Ebenen zur Behebung potenzieller Probleme eingeführt. Und da sich diese Probleme sowohl auf technischer als auch auf geschäftlicher Ebene manifestieren können, wird es immer schwieriger, Personen zu finden, die beide Aspekte beherrschen.

Um diese Herausforderungen zu veranschaulichen, finden Sie hier eine nicht erschöpfende Liste mehrerer Ursachen potenzieller Probleme, die uns dabei helfen, die erforderlichen Tests zu identifizieren, um sie zu erkennen:

  • Fehler beim Rendern : Visuelle Abweichungen beeinträchtigen zwar nicht die funktionale Benutzerfreundlichkeit, können aber störend sein und die wahrgenommene Qualität von Dashboards beeinträchtigen. Diese können sich in falsch ausgerichteten Beschriftungen, überfüllten Diagrammen, falschen Farbschemata und ähnlichen Anomalien äußern.
  • Renderfehler beim Drucken : Beim Drucken nimmt ein Dashboard ein Layout an, das nicht exakt mit seinem Gegenstück zum Desktop-Rendern identisch ist, was zu bestimmten Rendering-Störungen führt, die nur für das Druckformat gelten.
  • Funktionelle Panne : Solche Fehler beeinträchtigen die funktionale Nutzbarkeit der Dashboards erheblich. Beispiele hierfür sind unter anderem eine Datumsauswahl, die falsche Werte anzeigt, ein Mehrfachauswahlfilter, der als Einzelauswahl fungiert, ein Diagramm, in dem die erforderliche Auswahl fehlt, oder eine aufgeschlüsselte Drilldown-Funktion innerhalb einer Tabelle.
  • Datenregression : Bei den Dashboards können Probleme auftreten, wenn sie nicht die richtigen Daten verwenden. Dies ist häufig auf unvorhergesehene Änderungen in der Datenquelle (z. B. Datenbankaktualisierungen oder Änderungen an den APIs von IoT-Anbietern), Störungen im ETL-Prozess (Extract, Transform, Load) oder ähnliche Faktoren zurückzuführen.
  • Abfrage//Benutzerdefinierte Berechnungsregression : Vergleichbar mit Datenregression und herkömmlichen Codierungsfehlern können Abfragen und benutzerdefinierte Berechnungen unerwartet ein fehlerhaftes Verhalten aufweisen.
  • Fehlende Dashboards : Auf den ersten Blick mögen solche Fehler merkwürdig erscheinen. Bei der Verwaltung einer beträchtlichen Anzahl vordefinierter (und möglicherweise automatisch generierter) Dashboards ist es jedoch möglicherweise nicht sofort ersichtlich, ob alle wie erwartet verfügbar sind.
  • Sicherheit//Autorisierung : Das Vorhandensein verschiedener Benutzersicherheitsprofile und Autorisierungsstufen kann, wie bereits erwähnt, zu einer Vielzahl von Fehlern führen (z. B. unzugängliche Dashboards aufgrund von Zugriffsberechtigungen, Regression bei Abfragen oder Berechnungen, die sich aus der Unfähigkeit ergeben, auf bestimmte Daten zuzugreifen, usw.).
  • Leistungsregression : Ein unvorhergesehener Anstieg des Datenvolumens und/oder der Zustrom von Benutzern, die auf die Analysen zugreifen, führt zu einer Verlangsamung der Abfragen, wodurch das Öffnen und Rendern von Dashboards inakzeptabel langsam wird.
  • Regression der Systemlast : Ähnlich wie bei der Leistungsregression wird bei dieser Form der Regression vernachlässigt, die Fähigkeit des Systems zu ermitteln, einer Eskalation des Datenvolumens, der Benutzerzahlen und ähnlichen Faktoren standzuhalten.

Diese Komplexität unterstreicht die Bedeutung gründlicher Testverfahren, um die Genauigkeit und Zuverlässigkeit des Dashboards sicherzustellen, und trägt wahrscheinlich dazu bei, dass weiterhin manuelle Testmethoden für Dashboards verwendet werden. Dieses Gefühl spiegelt sich in den Rückmeldungen von Kunden bei ICCube wider, die um Ratschläge zu automatisierten Tests zur Verbesserung der Qualität ihrer Dashboards baten.

Automatisiertes und manuelles Testen

Bevor wir uns mit den Besonderheiten verschiedener Testtypen befassen, sollten mehrere Gründe in Erinnerung gerufen werden, warum automatisiertes Testen so weit wie möglich dem manuellen Testen vorgezogen werden sollte.

  • Langsam : Manuelles Testen ist von Natur aus langsam: Es gibt eine feste Grenze dafür, wie schnell ein Benutzer mit Dashboards interagieren und die verschiedenen Verfahrensschritte der Tests ausführen kann. Dies ist sehr relevant, da in der Regel mehrere Testzyklen erforderlich sind, wenn ein Problem erkannt wird. Dies ist ein limitierender Faktor für eine schnelle Markteinführung der Lösung.
  • Eintönig : Manuelles Testen kann mühsam und eintönig sein, was zu mangelnder Motivation der Tester führen kann. Dieser nachlassende Enthusiasmus wirkt sich negativ auf die Gesamtqualität des Testzyklus aus.
  • Dokumentation : Manuelles Testen erfordert eine umfangreiche Dokumentation, in der die verschiedenen Testschritte sowohl auf technischer als auch auf geschäftlicher Ebene beschrieben werden. Die Pflege dieser Dokumentation stellt eine Herausforderung dar, insbesondere in einer dynamischen Umgebung, in der sich das Produkt schnell weiterentwickelt.
  • Schwer zu erkennender Datenfehler : Bestimmte Fehler lassen sich durch manuelles Testen nur schwer erkennen. So kann es beispielsweise besonders schwierig sein, ungültige Daten in einem Tabellendiagramm zu identifizieren, insbesondere wenn die Tester nicht über die erforderlichen Geschäftskenntnisse verfügen, um Inkonsistenzen in den Daten zu erkennen.
  • Hochqualifizierte Arbeitskräfte : Wie bereits erwähnt, erfordert manuelles Testen Kenntnisse sowohl im technischen als auch im geschäftlichen Bereich. Mitarbeiter, die über solch hochspezialisierte Fähigkeiten verfügen, sind rar und werden oft anderen Bereichen innerhalb des Unternehmens zugewiesen, wo ihre Talente für kreativere und innovativere Vorhaben eingesetzt werden können.
  • Hohe Kosten : Die oben genannten Faktoren tragen zusammen zu erhöhten Kosten bei, da für die effiziente Prüfung des Produkts erhebliche Arbeitskräfte erforderlich sind.
  • Fehleranfällig : Manuelle Tester sind nun mal... Menschen und machen daher Fehler. Es ist also offensichtlich, dass manuelle Tests anfällig für Fehler sind, die sich negativ auf die Gesamtqualität der Tests auswirken.
  • Skalierbarkeitsproblem : Manuelle Tester sind nicht in der Lage, sich selbst zu replizieren, um eine bestimmte Anzahl von Benutzern für Leistungs- und Stresstests zu simulieren. Sie können auch nicht rund um die Uhr kontinuierlich arbeiten, es sei denn, Sie haben zufällig eine Armee von ChatGPT-Agenten zur Verfügung ;-)
  • CI/CD-Pipeline-Integration : Letztlich stellt die Integration manueller Tests in bestehende DevOps- und DataOps-Pipelines, die innerhalb des Unternehmens verfügbar sind, eine Herausforderung dar. Dadurch wird die Umsetzung des Dashboards- und Analytics-Projekts behindert, was sich auf die Markteinführungszeit auswirkt.

Automatisierte Tests

In diesem Abschnitt werden wir verschiedene Arten automatisierter Tests untersuchen, mit denen jedes zuvor identifizierte Problem effektiv angegangen werden kann. Diese Liste erhebt zwar keinen Anspruch auf Vollständigkeit, bietet aber wertvolle Einblicke in Maßnahmen, die zur Verbesserung der Projektqualität ergriffen werden können.

Öffentliches Github-Projekt

In Anerkennung der Notwendigkeit und Komplexität von Tests hat ICCube die veröffentlicht ic3-analytics-ops Projekt auf GitHub mit folgenden Zielen vor Augen:

- zulässige Lizenz zur Wiederverwendung und Erweiterung nach Belieben,

- flexibel genug, um in die bestehende CI/CD-Pipeline integriert zu werden,

- automatisierte Servertests,

- automatisierte Datenmodelltests,

- automatisierte Datenautorisierungstests,

- automatisierte Dashboard-Tests.

Dieses Framework bietet die Bausteine zum Erstellen verschiedener Arten von Tests.

Funktionstests

Der Testläufer bedient die Dashboards wie ein Benutzer und überprüft, ob die Anwendung wie vorgesehen funktioniert. Zypresse ist das gewählte Tool für die Durchführung dieser Art von Tests innerhalb des Projekts. Die Tests werden in JavaScript geschrieben und nutzen eine Reihe vordefinierter Hilfsfunktionen, die speziell auf das Testen der von ICCube generierten Dashboards zugeschnitten sind. Diese Funktionen werden bereits intern von iCube verwendet, um die Dashboard-Anwendung selbst zu testen.

Regressionstests

Der Testrunner simuliert Benutzeraktionen auf interaktiven Dashboards und führt Abfragen aus, um die erwarteten Ergebnisse zu bestätigen. Tests werden deklarativ mit dem Skript geschrieben JSON 5 Dateiformat. Das Projekt erleichtert die Generierung erwarteter Ergebnisse, die anschließend wiederverwendet werden, um sicherzustellen, dass keine Regression stattfindet. Die Regressionstests für das visuelle Rendern sind nach wie vor ein fortlaufender Entwicklungsbereich. Weitere Einzelheiten werden im Zuge der Fortschritte bekannt gegeben.

Leistungstests

Bei Datentests ohne Regression kann der Testläufer zeitbasierte Ergebnisse validieren, um sicherzustellen, dass die Leistung des Systems den Erwartungen entspricht. Dies kann die Bewertung von Kennzahlen wie den Öffnungs- und Druckzeiten des Dashboards, der Dauer des Drilldown-Roundtrips zum Server und ähnlicher Leistungsindikatoren beinhalten.

Stresstests

Die vom Testläufer ausgeführten Tests beschreiben einen oder mehrere Akteure, wobei jedem Akteur eine Reihe von Aufgaben zugewiesen wird, die er ausführen muss. Diese Akteure agieren autonom in ihren eigenen Kontrollsträngen und eignen sich daher gut für die Replikation entweder auf einem einzelnen Testcomputer oder auf mehreren Testcomputern. Dies ermöglicht die Simulation einer erheblichen Benutzerlast, was die Erkundung der Kapazitätsgrenzen des Systems erleichtert. Darüber hinaus können solche Tests kontinuierlich rund um die Uhr durchgeführt werden, um die Systemstabilität als zusätzlichen Vorteil sicherzustellen.

Sicherheits-/Autorisierungstests

Der Testrunner ist in der Lage, Benutzer mit verschiedenen Anmeldeinformationen zu authentifizieren und so sicherzustellen, dass die erwarteten Ergebnisse mit jedem Autorisierungsprofil übereinstimmen. In der heutigen Situation haben solche Tests eine erhöhte Bedeutung, insbesondere angesichts der umfassenden Integration eingebetteter Analytik, die zur Komplexität des untersuchten Gesamtsystems beiträgt.

Dev. gegen QA. gegen Prod. Testen der Umgebung

Der Test Runner ist nicht nur auf die Entwicklungsumgebung beschränkt. Es ist unerlässlich, Tests in allen Umgebungen durchzuführen, einschließlich Entwicklung, Qualitätssicherung und idealerweise sogar in der Produktionsumgebung. Einschränkungen beim Zugriff auf vertrauliche Produktionsdaten können zwar bestimmte Arten von Tests einschränken, doch die Durchführung zumindest einer Art von Rauchtests ist unerlässlich, um die grundlegende Funktionalität des Systems sicherzustellen. Darüber hinaus können Anstrengungen unternommen werden, um Ihre Endbenutzer bei der Erstellung ihrer eigenen Testszenarien zu unterstützen.

Upgrade/ Migrationstest

Nachdem umfassende Tests implementiert wurden und das Vertrauen in die Qualität der Anwendung gestiegen ist, werden Sie eher geneigt sein, die Anwendung zu aktualisieren, um den Endbenutzern neue Funktionen bereitzustellen. Dies geht mit dem bemerkenswerten Vorteil einher, dass die Markteinführungszeit erheblich verkürzt wird. Dieser Wandel kann in unserer sich schnell entwickelnden und wettbewerbsintensiven Landschaft wegweisend sein.

Fazit

Hoffentlich sind Sie jetzt davon überzeugt, dass automatisiertes (im Gegensatz zu manuellem) Testen der Schlüssel zum Erfolg Ihres Dashboards- und Analyseprojekts ist und dass Sie es sofort mit vorhandenen Tools implementieren können.

Wir bei ICCube wissen, dass komplexe Tests entmutigend sein können. Deshalb Boutique-Dienstleistungen für Datenanalysen sind hier um dir zu helfen, also zögere nicht kontaktiere uns, wir helfen Ihnen gerne weiter.

Medium Beiträge

Die folgenden Medium-Geschichten bieten eine ausführliche Berichterstattung und aufschlussreiche Perspektiven auf diesen Blogbeitrag.

bietet zusätzlichen Kontext für Leser, die sich weiter mit dem Thema befassen möchten:

- AnalyticsOps und automatisierte Dashboard-Tests

- Testen Sie Ihre Analysen und Dashboards

- Belastungstests für Ihre Analysen und Dashboards

- Analytics/Dashboards: Überprüfung der Versionsupdates

_