Qualitätssicherung im Data Warehouse beginnt nicht beim Testen, sondern beim Verstehen der Anforderungen. Ein Business Analyst mit Testing-Hintergrund erkennt Grenzfälle früh, hinterfragt halbfertige Lösungen aus dem Fachbereich und gibt Testern das fachliche Verständnis mit, das sie brauchen, um auch die Spezifikation selbst zu challengen, nicht nur den Code.
Das Wichtigste in Kürze
- Business-Analysten, die aus dem Testing kommen, erkennen Grenzfälle und Lücken in Anforderungen früher, weil sie gewohnt sind, Spezifikationen aktiv zu hinterfragen statt sie als Wahrheit zu akzeptieren.
- Tester sollten Spezifikationen vom Business-Analysten aktiv challengen, denn auch Business-Analysten machen Fehler, und wer das Fachdomänen-Verständnis fehlt, kann nur technisch testen.
- Synthetische, fachlich spezifizierte Testdatensätze decken neue Strukturen und Konstellationen zuverlässiger ab als Produktionsdaten, die nicht auf die zu testenden Changes vorbereitet sind.
- Job-Rotation, also für zwei bis drei Monate in die Rolle einer anderen Disziplin zu wechseln, verbessert das gegenseitige Verständnis und wirkt sich direkt auf die Qualität der täglichen Arbeit aus.
Tester prüfen, ob etwas richtig ist. Business Analysten legen fest, was richtig sein soll
Der Unterschied zwischen Test und Analyse lässt sich auf einen Satz bringen: Ein Tester schaut, ob etwas richtig ist. Ein Business Analyst sagt, was richtig sein soll. Das ist eine grobe Vereinfachung, trifft aber den Kern beider Rollen.
Wer aus dem Testing in die Analyse wechselt, nimmt eine Denkweise mit, die der reinen Anforderungsarbeit oft fehlt. Tester denken in Grenzfällen. Sie schauen genau auf die Stellen, an denen Spezifikationen brechen. Diese Sicht hilft beim Formulieren von Anforderungen, weil sie Lücken sichtbar macht, bevor Code geschrieben wird.
Philipp Huber, der vom Software-Tester zum Business Analyst in einem Data-Warehouse-Projekt einer großen Bankengruppe gewechselt ist, beschreibt Test und Analyse als zwei Seiten derselben Medaille. In agilen Teams, in denen Aufgaben nach Bedarf verteilt werden und T-Shaping zählt, hilft es, beide Seiten zu kennen: Methodik, Werkzeuge und das Produkt aus Test- wie aus Analyse-Perspektive.
Warum Tester die Spezifikation hinterfragen müssen
Tester sollten die Vorgaben der Business Analysten nicht als Wahrheit behandeln. Genau das passiert aber häufig: Eine Datenabbildung ist so spezifiziert, also gelten die Mappings als gesetzt. Kommt hinten etwas anderes heraus, suchen Tester den Fehler im Code oder im eigenen Testfall, nicht in der Spezifikation.
Auch Business Analysten machen Fehler. Deshalb ist es wichtig, dass Tester die Spezifikation challengen, statt sie blind durchzutesten. Tut ein Tester das nicht, bleibt nur ein rein technischer Test übrig, und der reicht nicht.
Damit Tester überhaupt hinterfragen können, brauchen sie fachlichen Hintergrund. In einem Banken-Warehouse wirken viele Felder wie ein Datengrab: Es gibt sie, aber wofür sie gut sind, bleibt unklar. Ohne Wissen über die Bedeutung der Felder und die Beziehungen zwischen den Entitäten kann niemand sinnvoll prüfen, ob ein Ergebnis stimmt.
Mir ist sehr wichtig, dass die Tester die Spezifikation in Frage stellen. Dazu müssen sie aber den Hintergrund kennen. Wenn das für mich ein Datenfriedhof ist und ich keine Ahnung habe, wozu die Felder dienen, dann kann ich das auch nicht challengen. Philipp Huber
Anforderungen früh challengen spart späteren Ballast
Die größte Hebelwirkung auf Qualität liegt vor der ersten Zeile Code. Fachbereiche kommen oft nicht mit einem Anforderung, sondern mit einer halbfertigen Lösung, die sie sich schon ausgedacht haben. Diese Lösung ist häufig nicht das, was wirklich gebraucht wird.
Hier setzt die Arbeit des Business Analysten an. Statt die mitgebrachte Lösung zu übernehmen, fragt er zurück: Was brauchst du genau? Denk nicht daran, wie die Lösung aussehen soll, sondern sag, was du erreichen willst. In einem Umfeld mit zwei Warehäusern mit unterschiedlichem Fokus zeigt sich dabei oft, dass aufwändig gedachte Datenflüsse über beide Systeme gar nicht nötig sind und vieles einfacher geht.
Wer diese Klärung überspringt, baut Lösungen auf Lösungen. Die Anforderung ist bereits die fertige Lösung, sie wird so umgesetzt, und die nächste wird obendrauf gepfropft. Die Architektur wird unübersichtlich und entspricht keinem klaren Prinzip mehr.
Im Warehouse wiegt das besonders schwer. Was einmal mitgeschleppt wird, lässt sich später kaum noch entfernen. Deshalb gilt: lieber am Anfang Mühe geben, als den Ballast über Jahre mitzuziehen.
Dieselbe Sache, zwanzig Sichten: Vereinheitlichung ist Analyse-Arbeit
Verschiedene Fachbereiche haben für dasselbe Konzept unterschiedliche Sichten, doch das Warehouse braucht eine. Ein typisches Beispiel ist die Klassifikation von Kunden. In einem einzigen Projekt können zwanzig verschiedene Arten zusammenkommen, einen Kunden zu klassifizieren, vom Retail-Kunden bis zum großen Geschäftskunden.
Zwanzig parallele Kundentyp-Attribute im Warehouse bringen niemandem etwas. Die Aufgabe des Business Analysten ist es, mit den Fachbereichen zu sprechen und diese Sichten so weit wie möglich zu vereinheitlichen, bevor sie als dauerhafte Struktur ins Warehouse wandern.
Wie strukturiert läuft Anforderungsarbeit in der Praxis
Ein einheitlicher, zentraler Prozess für Anforderungen existiert in großen Organisationen oft nicht. Die Erfassung läuft je nach Bereich unterschiedlich, mal besser, mal schlechter. In der Praxis dominieren Excel-Listen mit den gewünschten Feldern, intern ergänzt durch eigene Tools zum Tracken.
Ein gruppenweites Business Data Model kann Orientierung geben, wirkt aber nur, wenn sich die Abteilungen daran halten. Für die einen ist es die Beschreibung ihres Geschäfts, für die anderen ein Anhängsel, das sich irgendwer im Warehouse ausgedacht hat. In einer großen Firma bleibt das Ergebnis uneinheitlich.
Der Wandel von klassischen Wasserfallprojekten zu agilem Arbeiten verändert auch das Mindset, löst die Uneinheitlichkeit aber nicht automatisch auf. Wer Agilität mit fehlender Struktur verwechselt, verfehlt den Punkt. Agilität ist kein Freibrief für einen Sauhaufen.
Testdaten für neue Strukturen sind das eigentliche Problem
Für neue Felder und neue Entitäten gibt es keine brauchbaren Testdaten, weil die Strukturen erst entwickelt werden. Mit Produktivdaten lassen sich solche Changes kaum testen, da diese Daten nie auf die geplanten Änderungen vorbereitet wurden.
Die manuelle Lösung, einzelne Records hinzuzufügen oder zu verändern, kostet jedes Mal Aufwand und ist schwer zu pflegen. Will man dieselben Testfälle ein halbes Jahr später auf einem anderen, produktionsnäheren Datenset ausführen, funktioniert das nicht mehr sauber.
Hinzu kommt ein Sichtbarkeitsproblem. Eine Tabelle mit zehn Millionen Datensätzen sagt nichts darüber aus, ob alle benötigten Konstellationen darin abgedeckt sind. Bei neuen Daten ist das besonders schwer herauszufinden.
Business-basierte Testfälle, die überall laufen
Der wirksamste Ansatz sind isolierte Testfälle, die einzelne Datenkonstellationen abbilden und sich jederzeit deployen lassen. Statt im Wald von Millionen Produktivrecords zu suchen, beschreibt man gezielt die Szenarien, die man prüfen will.
In einem konkreten Fall wurde dieser Ansatz mit Excel-Makros und Quality Center umgesetzt. Die Technik war rustikal, das Ergebnis funktionierte. So lief der Workflow:
| Schritt | Was passiert |
|---|---|
| Konstellation eingeben | Datenkonstellationen werden in einem Excel-Sheet erfasst, zusammenhängende Entitäten als Test-Set kopierbar |
| Expected Result definieren | Im selben Sheet wird festgehalten, wie eine Consuming-Applikation die Daten erwartet |
| Daten laden | Ein Excel-Makro schreibt die Eingaben direkt in die Staging-Area, von dort werden sie durch das Warehouse bis in den Core geladen |
| Automatisch vergleichen | Quality-Center-Testfälle prüfen das Expected Result gegen den tatsächlichen Output der letzten Strecke |
Der Ansatz automatisiert zwei Dinge gleichzeitig: die Generierung der Testdaten aus den manuell spezifizierten Testfällen und die Prüfung des Outputs. Im Kern geht es darum, ob die Transformation stimmt, also ob Daten, die in einer Struktur ankommen, im Consumer-System korrekt in einer anderen Struktur erscheinen.
Excel als Basis hat klare Grenzen. Verschiedene Versionen einer Datei schwirren über File-Shares und E-Mails, das ist keine dauerhafte Lösung. Der Workflow selbst trägt aber und lässt sich mit besseren Werkzeugen genauso umsetzen.
Akzeptanz schlägt Eleganz beim Werkzeug
Ein Testdaten-Ansatz nützt nichts, wenn die Fachbereiche ihn nicht annehmen. Genau das war die Stärke der Excel-Lösung: Der Fachbereich konnte direkt Testdaten erstellen, weil Excel sein gewohntes Werkzeug ist.
Für jemanden, der mit Excel arbeitet, sind Formeln und das Kopieren von Test-Sets selbstverständlich. Sich in ein fremdes Spezial-Tool einzuarbeiten wäre eine Hürde. Excel ist die Wohlfühlzone und erhöht die Akzeptanz.
Das beste Tool bringt nichts, wenn die Leute es nicht verstehen und nicht akzeptieren. Diese Lösung entstand aus der Not, weil die bestehenden Werkzeuge bei zu vielen neuen Strukturen nicht weiterkamen und keine Zeit für eine große Tool-Recherche blieb.
Produktivdaten und synthetische Daten gehören kombiniert
Kein einziger Ansatz deckt alles ab. In der Praxis bewährt sich eine Kombination: spezifische Testfälle für die wichtigste Funktionalität, ergänzt durch Regression auf produktionsnahen Daten.
Ein großer Teil läuft über Regression mit anonymisierten Produktivdaten. Eine Baseline aus produktionsnahen Daten wird gegen das vorige Release verglichen, um unerwartete Abweichungen zu finden. Der Haken steckt im Detail: Wenn eine Abweichung auftritt, muss man wissen, ob sie so erwartet war.
Genau hier scheitert reiner Produktivdaten-Test. Diese Daten sind nicht auf die geplanten Changes vorbereitet. Deshalb braucht es zusätzlich gezielte, auch synthetische Datensätze, die die zentrale Funktionalität abdecken, während die Regression sicherstellt, dass am Ende alles zusammenpasst.
KI als Inspirationsquelle für Testszenarien
Generative KI kann Testszenarien vorschlagen, aber nicht eins zu eins liefern. Wer Strukturen beschreibt und ein Sprachmodell nach möglichen Testfällen fragt, bekommt brauchbare Anregungen, die als Ausgangspunkt taugen.
Ein Business Analyst kann den Testern dabei konkrete Szenarien mitgeben, ohne jeden Edge Case bis ins letzte Detail mit Expected Results auszuformulieren. Diese Feinarbeit bleibt Aufgabe des Testers. Der Input setzt die Richtung, die Ausarbeitung übernimmt die Test-Seite.
Zieh die Schuhe des anderen an
Der wirksamste Tipp für mehr Qualitätssicht ist ein Rollenwechsel auf Zeit. Wer zwei bis drei Monate die Arbeit eines anderen macht, sieht danach die Welt mit anderen Augen.
Niemand wird in drei Monaten zum perfekten Tester oder Business Analyst. Aber man sieht, worauf es ankommt. Das gilt in beide Richtungen und lässt sich weiterdenken: Ein Business Analyst, der sich für einige Monate zu dem Fachbereich setzt, der vom Warehouse abhängt, versteht danach besser, warum die Dinge so sind, wie sie sind.
Dieses Verständnis wirkt direkt auf die Qualität der Arbeit. Wer neugierig bleibt und aus dem eigenen Kastl heraustritt, nimmt aus fremden Aufgaben mehr mit als jemand, der nur die eigene Rolle nach bestem Gewissen erfüllt. Genau dieser Perspektivwechsel steckt im Kern agilen Arbeitens.
