Business Application Research Center

Experten für Business Intelligence, Analytics, Big Data, CRM und ECM

BARC-Newsletter

Testen von BI- und DWH-Systemen [Teil 1]: Testmethodik und Schwerpunkte

Testen von BI- und DWH-Systemen [Teil 1]: Testmethodik und Schwerpunkte

RssRss

13.02.2019

Testen von BI- und DWH-Systemen [Teil 1]: Testmethodik und Schwerpunkte

"Wir haben so viele Incidents in der Produktion, dass wir keine Zeit für ein effektives Testen unseres Data Warehouses finden". So schilderte mir eine Teamleiterin ihre aktuelle Situation, ohne den Zusammenhang zwischen ungenügendem Testen und den Produktionsstörungen, die durch die unentdeckten Fehler verursacht wurden, wahrzunehmen. Ähnliche Situationen gibt es leider häufig. Da die besonderen Herausforderungen für das Testen von BI-Systemen und das mögliche Spektrum von Lösungen meist zu wenig bekannt sind, findet ein zielgerichtetes, effektives Testen oft nicht statt.

Besondere Herausforderungen beim Testen von analytischen Systemen

Durch die speziellen Eigenheiten von BI- und DWH-Systemen, ergeben sich einige Herausforderungen beim Testen dieser Systeme. Dazu nachfolgend einige Beispiele, wobei es sich hier jedoch nicht um eine vollständige Liste handelt:

  • Datengetriebenes Testen anstelle von Usecases
    In operativen Systemen ist das Testen nach Usecases üblich. Das bedeutet, ein Geschäftsvorfall wird durchgeführt und das Ergebnis einer einzelnen Transaktion als Abbildung in den Daten geprüft. Bei analytischen Systemen sind Usecases nicht vorhanden oder nur von untergeordneter Bedeutung. Im Vordergrund stehen datengetriebene Tests mit der Prüfung gesamter Datasets, was eine grundlegend andere Herangehensweise an die Erstellung von Testfällen nötig macht und teilweise identische Verfahren der Datenqualitätsprüfung verwendet.
  • Dynamische Code-Generierung durch Tools
    In transaktionalen Systemen bleibt der Code unveränderlich, wie beispielsweise bei einem einmal geschriebenem SQL-Statement, eingebettet in den Code einer weiteren Programmiersprache. In analytischen Systemen wird der Code hingegen durch Frontend- oder ETL-Tools im Hintergrund generiert (vgl. Abbildung 1). Schon das Verändern einer Spaltenreihenfolge erzeugt eine neue SQL-Abfrage. Somit ist codebasiertes Testen nicht zweckmässig. Häufig ist der generierte Code zudem nicht ersichtlich, sodass hier Greybox-Tests erstellt und ausgeführt werden müssen.
     
    Transaktionale Systeme Analytische Systeme
    Testen nach Usecases Datengetriebene Tests
    Prüfen einzelner Datensätze Prüfen gesamter Datasets
    Statischer Code Dynamisch generierter Code
    Abbildung 1. Unterschiedliche Voraussetzungen zum Testen von transaktionalen Systemen im Vergleich zu analytischen Systemen
     
  • Offizielle Normen und Standards berücksichtigen keine Eigenheiten von analytischen Systemen
    Die üblichen Standards und Normen, wie etwa das V-Modell, sind für transaktionale Systeme angelegt. Ein Adaptieren auf BI- und DWH-Systeme ist nur mit dem notwendigen Transferaufwand und einigen Kompromissen möglich.
  • Herausforderungen durch agile Projektmethoden
    Durch den Wechsel zu agilen Projektmethoden müssen Testvorbereitung und -durchführung in kürzeren Zeitfenstern erfolgen. Dadurch überfordert, wird häufig nur ungenügend getestet und die Softwarequalität verschlechtert sich. Dies müsste nicht sein, haben doch alle agilen Projektmethoden den Selbstanspruch, bessere Software in kürzerer Zeit bereitzustellen.

Lösungsoptionen

Durch eine angepasste Methodik ist ein effektives Testen von BI- und DWH-Systemen möglich. Auch dazu einige Beispiele:

  • Vielseitigkeit der Testfälle
    Leider wird vielfach nur auf funktionale Korrektheit getestet. Funktionale Vollständigkeit, wie das adäquate Reagieren auf alle attributbezogenen Wertebereiche in einem Ladeprozess, wird dagegen nur teilweise geprüft. Werden noch Kombinationen von unterschiedlichen Werten in mehreren Attributen geprüft, ist die Erstellung von Testfällen mittels Entscheidungstabellen sinnvoll.
    Die Akzeptanzkriterien und -klassen nach ISO 25010 (vgl. Abbildung 2, Download als pdf-Datei) bieten eine gute Orientierung, wenn nicht nur reine funktionale Tests erstellt und ausgeführt werden sollen. Daraus können deutlich vielseitigere Testfälle, wie etwa das Laufzeitverhalten von ETL-Prozessen (effiziente Performance: Zeitverhalten), Verhalten von ETL-Prozessen bei ungenügender Datenqualität in den Sourcedaten (Fehlertoleranz aus verlässlicher Software) oder Restart-Fähigkeit (Wiederherstellbarkeit), abgeleitet werden.


    Abbildung 2. Akzeptanzkriterien und -klassen nach ISO 25010 (Download als pdf-Datei)
     
  • Datengetriebene Tests
    Auswertungen zeigen, dass mehr als die Hälfte der gefundenen Fehler in Data-Warehouse- und BI-Systemen auf die Daten zurückzuführen sind. Einerseits werden bei der Analyse oft nicht alle Wertebereiche und Kombinationen von Wertebereichen ermittelt, was zu unvollständigen Implementierungen führt. Andererseits kommt es durch Datenqualitätsprobleme aus den Quellsystemen immer wieder zu Störungen, beispielsweise zu Abbrüchen in den Ladeprozessen.
  • Testabdeckung
    Da ein vollständiges Testen eines Systems nicht möglich ist und wirtschaftlich auch nicht sinnvoll wäre, bleibt die Frage, wann genügend getestet wurde. Ergänzend zur vorher beschriebenen Vielseitigkeit von Testfällen, ist dies nun eine quantitative Frage. Die notwendige Anzahl an Testfällen kann einfach Bottom-Up berechnet werden. Dabei wird zuerst die Komplexität und die Kritikalität der einzelnen Systemkomponenten ermittelt. Gerade die Business-Kritikalität, also die Bedeutung von analytischen Systemen, wird leider häufig unterschätzt, wodurch eine Systemarchitektur abgeleitet wird, die nicht der benötigten Verfügbarkeit entspricht.
    In einem zweiten Schritt kann auf Basis der Komplexität eine Fehleranzahl angenommen werden (Verfahren «error guessing») und mit den entsprechenden Faktoren für die Testabdeckung zu Kritikalität und dem Verhältnis notwendiger Testfälle zum Entdecken eines Fehlers multipliziert werden.
    Dieses Berechnungsverfahren ergibt häufig einen Testaufwand, der von denselben Personen als zu hoch kritisiert wird, die meistens auch den Vorwurf äußern, dass zu wenig getestet wurde. Der Testaufwand für Systeme lässt sich nur mittelfristig durch das Automatisieren von Regressionstests reduzieren. Bis dahin ist es Überzeugungsarbeit (schaffen von Awareness) oder das Eingehen von Kompromissen.
  • Kombination von agilen und traditionellen Testmethoden
    Eine Effizienzsteigerung wird erreicht, indem die formalen Testfälle durch Review-Verfahren (statisches Testen) und agile Testmethoden ergänzt werden, beispielsweise nach dem Framework von Lisa Crispin und Janet Gregory. Zudem lohnt sich der Aufbau einer bewirtschafteten Regressionstestlibrary.

Summary

Grundvoraussetzung für ein effektives und genügendes methodisches Testen ist das Verständnis und die Kultur innerhalb des Unternehmens. Dies beginnt nicht zuletzt beim Management. Wird das Testen in erster Linie als Kostenfaktor wahrgenommen, wird vermutlich versucht werden, den Testaufwand möglichst gering zu halten. Eine echte Testkultur wird so jedoch nie entstehen. 

Vielseitige und umfangreiche Testdaten sind eine elementare Voraussetzung für das Durchführen der Testfälle. Der Aspekt der zweckmässigen Testdaten wird im kommenden Teil 2 dieser Reihe beschrieben.

BARC bietet zur Unterstützung verschiedene Angebote an:

  • Zweitägige Classroom-Seminare an verschiedenen Standorten
  • Individuelle Inhouse-Seminare nach Ihren inhaltlichen und terminlichen Vorstellungen
  • Individuelle Workshops 
  • Generelle Unterstützung als abgestimmtes Beratungsangebot, wie Assessments oder spezifische Vertiefung ausgewählter Themen (zum Beispiel agiles Testen, Aufbau von Regressionstests, Bestimmen der notwendigen Testabdeckung, Automatisierung mittels geeigneter Tools, etc.)