Testing für BI/DWH – wo stehen wir? (Teil 1)

Testing gehört seit jeher in jeden IT-Projektplan – so auch für BI/DWH Projekte. Die praktische Umsetzung von Testing im BI/DWH Umfeld stellte mich in der Vergangenheit immer wieder vor grosse Probleme. Nicht selten ereilt einen der Eindruck, dass sich die BI/DWH Welt im Hinblick auf den Reifegrad der Entwicklungsprozesse und -umgebungen noch in der Steinzeit befindet, zumindest substantiell hinter dem Reifegrad im Bereich Software Engineering. Die nachstehende Graphik illustriert diesen Gap:

rbra_testing1 (1)
Kulturelle Unterschiede zwischen der Softwareentwickler- und BI Community (Quelle: http://agiledata.org/essays/culturalImpedanceMismatch.html)

 

Wenn überhaupt etwas getestet wird, so wir im BI-Frontend-Bereich typischerweise noch vieles von Hand getestet. Im DWH-Backend kommen neben manuellen Tests allenfalls noch selbstgeschriebene Testroutinen, z.B. in Form von Stored Procedures oder dedizierte ETL-Jobs zum Einsatz. Jedoch fehlt dabei häufig die Integration in ein Testfall-Management und eine systematische Überwachung der Testresultate findet nicht statt. Dies steht in einem starken Kontrast zum Software Engineering Umfeld, wo automatisches Regression-Testing kombiniert mit modernen Entwicklungsansätzen wie Test Driven Design angewendet wird. Immerhin gibt es seit geraumer Zeit auch erste konzeptionelle Inputs bezüglich BI-spezifischem Testing (vgl. dazu u.a. das TDWI-Buch hier: http://www.tdwi.eu/publikationen/tdwi-buecher/testen-von-data-warehouse-und-business-intelligence-systemen/) Konzepte und Papier jedoch sind geduldig. Wie steht es um einen möglichen Toolsupport, insbesondere für den Bereich der Regression-Tests?

Seit letztem Sommer suchen wir bei IT-Logix zusammen mit der Firma Tricentis (http://www.tricentis.com/) aus Österreich aktiv nach Lösungsansätzen für BI-spezifisches Testing. Tricentis entwickelt die Tosca Produktesuite, eine der weltweit führenden Test Automation Lösungen. In einem ersten Schritt führten wir einen POC durch, um Regression-Tests für BI-Frontends durchzuführen. Als Basis entschieden wir uns für die Verwendung von Excel- und PDF-Exporten. Durch die Wahl dieser generischen Datei-Schnittstelle entfiel der Aufwand, BI-produktspezifische Tests zu entwickeln – dadurch minimierten wir den Umsetzungsaufwand auf rund zwei Tage im POC. Ziel war es, batch-mässig „Vorher-Nachher“ Tests durchzuführen, dies für exemplarisch 20 Reports / Berichte im POC. Dabei wird der aktuelle PDF- oder Exceloutput eines Berichts mit einer Referenzdatei verglichen.

rbra_testing1 (3)
Beispielhafte Konfiguration eines Testfall-Templates in der graphischen Oberfläche von Tosca (Quelle: IT-Logix POC)

Tosca sucht dabei nach Unterschieden. Bei Excel geschieht dies auf Zellenbasis, bei PDF Dateien implementierten wir einen Text-basierten Test sowie einen Bildvergleich.

rbra_testing1 (2)
Je nach gewähltem Testmodus können die Differenzen unterschiedlich visualisiert werden. (Quelle: IT-Logix POC)

Mit Hilfe der im POC implementierten Lösung konnten wir sehr schnell sehen, bei welchen Berichten sich im Ist-Zustand Dinge gegenüber dem Referenz-Zustand verändert hatten.

Ein weiterer wichtiger Aspekt im POC für mich war die Skalierbarkeit des Lösungsansatzes, da wir primär mit (Large) Enterprise Customers arbeiten. Wenn ich nicht 20 sondern hunderte wenn nicht tausende Berichte (und damit Testfälle) vorliegen habe, muss ich die Erstellung, Ausführung und Fehleranalyse dieser Testfälle irgendwie priorisieren und verwalten können. Tosca hilft an dieser Stelle mit der Möglichkeit, Business Requirements abzubilden und mit Testfällen zu verbinden. Daraus lassen sich in der Folge klassische Testmetriken wie z.B. Testfall-Abdeckung oder Test Execution Rate abbilden und reporten.

rbra_testing1 (1)
Requirements und Testfälle stehen in einem engen Zusammenhang. (Quelle: IT-Logix POC)

Eine Infrastruktur wie sie z.B. Tosca bietet, ist aus meiner Sicht die Grundvoraussetzung, um die Qualität in BI/DWH-Projekten systematisch zu erhöhen bzw. zu erhalten. Weitergehende Methoden wie Test Driven Development sind zudem erst sinnvoll für BI/DWH-Vorhaben adaptierbar, wenn auch die dafür nötige Infrastruktur bereitsteht. Im Rahmen dieses Blogs habe ich erste, rudimentäre Möglichkeiten im Bereich Regression-Tests für BI-Frontends aufgezeigt. In einem nächsten Beitrag werde ich auf die Möglichkeiten eingehen, Regression-Tests für DWH-Backend-Komponenten umzusetzen.

Möchten auch Sie erfahren, wie Sie die Qualität Ihrer BI/DWH-Lösung erhöhen können? Kontaktieren Sie uns, gerne besprechen wir mit Ihnen mögliche Konzepte und Lösungen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *