How-to: Wer sollte ETL-Anwendungen prüfen?

Nach jahrelanger Arbeit an der Entwicklung von ETL-Anwendungen kann ich sagen, dass sie üblicherweise schlechter als Transaktionssysteme geprüft werden. Hierzu tragen eine Menge technischer Faktoren bei, wie z. B.:

Schwierigkeit der Vorbereitung adäquater Testdaten
Verfügbarkeit von Testumgebungen
lange Laufzeiten

Neben den oben genannten Faktoren besteht eine erhebliche organisatorische Schwierigkeit: Die klassische Verteilung von Entwicklern und Prüfern funktioniert für ETL-Projekte nicht gerade gut. Dies wird durch die ungewöhnlich hohe Qualifikation verursacht, die für Prüfer erforderlich ist. Der betreffende Prüfer muss:

komplizierte SQL-Abfragen schreiben können
die Besonderheiten der Arbeit mit großen Datenvolumina verstehen
der geschäftlichen Bedeutung von Daten gewahr sein

In der Tat handelt es sich hierbei um Anforderungen eines Entwicklers mittleren Niveaus. Allerdings ist es fast unmöglich, solch qualifizierte Prüfer zu finden. Denn oftmals mangelt es an deren Bereitschaft, „nur“ als Prüfer zu arbeiten.

Daher können Peer-Review-Techniken in Betracht gezogen werden, wenn sowohl vom Entwickler als auch vom Prüfer vergleichbare Qualifikationen erwartet werden. Laut meiner Erfahrung funktionieren Peer-Reviews allerdings auch nicht. Dies liegt insbesondere an folgenden Gründen:

Entwickler sind nicht motiviert, sich eingehend mit den Aufgaben von Kollegen zu befassen, da sie sich zunächst und vor allem auf ihre eigenen Aufgaben konzentrieren.
Manager tendieren dazu, „Ressourcen einzusparen“, indem sie nicht ausreichend Zeit für Reviews einräumen.
Der Gutachter erhält zwar Input vom Entwickler, allerdings nicht von der Geschäftsabteilung. Deshalb kann er nicht herausbekommen, ob die Aufgabe richtig verstanden wurde.

Aufgrund dieser Kritik schlage ich eine andere Methode vor. Ziel ist es, die Prüfqualität durch die Abtrennung von Entwicklungs- und Prüfpflichten zu verbessern. Die Methode verlangt zwei Funktionen: Nennen wir sie einmal Analyst und Entwickler. Der Entwickler ist für die tatsächliche Entwicklung von Gegenständen, die Integration, Leistungsabstimmung usw. zuständig. Der Analyst liefert Input für den Entwickler und – hier besteht der grundlegende Unterschied – prüft die Ergebnisse der Tätigkeit des Entwicklers. Somit besteht die Hauptidee darin, dem Analysten die Verantwortung für die Datentests zuzuweisen. Dies funktioniert gut, da:

Analysten hochmotiviert sind, die Datenqualität angemessen zu prüfen, weil sie dem Kunden anschließend die Lösung präsentieren müssen
sie diejenigen im Projektteam sind, die am besten wissen, wie die Daten ausfallen sollten
sie ausreichend dafür qualifiziert sind, gute Tests durchzuführen

Die beschriebene Methode beinhaltet keine zusätzliche Hierarchieebene im Projekt: Analysten und Entwickler weisen für gewöhnlich dasselbe Positionsniveau auf. Meiner Erfahrung nach ist ein Verhältnis von einem Analysten je 2 bis 3 Entwickler angemessen.

Zudem bietet dies weitere Vorteile:

Entwickler können sich auf die Technologie konzentrieren; sie müssen über weniger geschäftliches Wissen verfügen und benötigen weniger Kommunikationskompetenzen, so dass Sie nicht nach Mitarbeitern suchen müssen, die in beiden Bereichen gut sind.
Von Entwicklern wird zunehmend weniger geschäftliches Wissen erwartet. Daher können Entwicklungsaufgaben leichter ausgelagert werden.

Der Hauptgrundsatz beim Durchführen von Tests besteht darin, dass unter keinen Umständen eine Einzelperson sowohl für die Umsetzung als auch die Tests verantwortlich sein darf. Um dies zu erreichen, wird bei DWH-Projekten den Analysten die Verantwortung für das Prüfen der Daten zugewiesen.