Ein agiles Tool zur automatisierten Beschaffung von Testdaten tangiert verschiedene Fachbereiche im Unternehmen. Daher müssen im Vorfeld der Implementierung alle Beteiligten vom Nutzen der Maßnahme überzeugt sein. Dies stellt sich zuweilen als komplexe Aufgabe dar. Je eher es den Initiatoren gelingt, die angrenzenden Bereiche ins Boot zu holen, desto schneller können alle von der neuen Lösung profitieren. UBS Hainer unterstützt bei der Koordinierung und Beschleunigung dieses Prozesses.

Klassischer Weg – Treiber der Idee

In vielen Unternehmen stellt das Testdatenmanagement einen Engpassfaktor dar. Die Beschaffung von Testfalldaten erfolgt mit erheblichem Aufwand, bindet Ressourcen und führt oft genug zu Kompromissen auf Kosten von Entwicklungsgeschwindigkeit oder Software-Qualität.

Meist gibt es dann eine Abteilung, die die Initiative ergreift und eine zeitgemäße Testdaten-Automation vorantreiben will. Sie hat den praktischen Nutzen im agilen Kontext erkannt und wird zum Treiber der Idee. In der Praxis wird ihr Enthusiasmus jedoch oft genug durch die praktischen Anforderungen gebremst. Schnell wird klar, dass hier zunächst einmal eine Art interne Werbungsphase gestartet werden muss, um andere Abteilungen ins Boot zu holen.

„Die Implementierung eines Automatisierungstools, wie es z.B. XDM ist, erfordert die interdisziplinäre Zusammenarbeit verschiedener Fachbereiche“, weiß Christoph Stock, Manager für Produktentwicklung bei UBS Hainer. „Dazu muss man zunächst einmal alle Beteiligten für die Idee begeistern und zur Mitarbeit bewegen.“

Das fängt bei der Systemtechnik bzw. Infrastruktur an und zieht sich durch den gesamten IT-Bereich und darüber hinaus, denn letztlich muss auch die Finanzierung des Projektes an entsprechender Stelle beschlossen werden.

„Ich brauche die Leute, die für Netzwerk, Speicherplatz, virtuelle Maschinen, Firewalls etc. zuständig sind“, führt Christoph Stock weiter aus. „Dann müssen die Datenbank-Experten und Administratoren mitmachen und natürlich die Software-Entwickler und Architekten. Denn die wissen, wie und wo die Daten gespeichert sind und wie sie zusammenhängen. Schließlich sollten die Anwender – sprich die Tester – an Bord sein und last but not least die Beauftragten für Compliance und Datenschutz. Diese haben nämlich klare Vorstellungen zum Thema Maskierung und Verfremdung von Daten.“

Business-Cases, Sachzwänge und Erfahrungswerte

Der Königsweg, um die Beteiligung aller benötigten Player zu erreichen, liegt in der Ausführung eines Business-Cases für jeden einzelnen Bereich. Hier wird plausibel dargelegt, wie sich die Implementierung der neuen Lösung auswirkt und welcher Nutzen dadurch entsteht, bzw. welche Stressfaktoren in Zukunft vermieden werden können.

Manchmal gibt es auch juristische Notwendigkeiten, um eine neue Applikation auf den Weg zu bringen. In den letzten Jahren waren die Themen Compliance, Maskierung und Datenschutz immer wieder treibende Kraft für Veränderungen. Die damit verbundenen Anforderungen haben gegenüber den technischen Bereichen des Unternehmens eine gewisse Priorität.

Am Ende braucht es aber immer jemanden im Unternehmen, der das Heft in die Hand nimmt und – über die Abteilungs- oder Zuständigkeitsgrenzen hinweg – die betroffenen Personen an einen Tisch holt. „Gemeinsam mit den Kunden von UBS Hainer haben wir diesen Prozess schon unzählige Male mit begleitet“, erläutert Christoph Stock. „Die meisten Konzerne ticken hier ähnlich. Wir wissen, wer üblicherweise mit welchem Thema betraut ist und was bei anderen Kunden bereits funktioniert hat. Damit können wir den Prozess in einem gewissen Maße mit unseren Erfahrungswerten unterstützen.“

Innovation aufgrund agiler Erkenntnis

Es kann aber auch ganz anders kommen: Christoph Stock berichtet von einem Fall, in dem der Handlungsbedarf über ein Scrum-Master-Board erkannt wurde. Im Austausch dieser interdisziplinären Stabsstelle kamen immer wieder dieselben Engpässe zur Sprache.

„Da berichten dann die Entwicklerteams, dass es beim Thema Testdaten regelmäßig Verzögerungen gibt“, so Stock. „Und die technischen Teams bemängeln, dass sie mit den Testdaten so viel Nebenarbeit haben. Wieder andere haben die Sorge, dass die Testdaten nicht anonymisiert sind etc. Eigentlich kommt aus jeder Richtung dieses Problem auf“, so Stock weiter. „Und dann reift die Erkenntnis, dass man ein übergeordnetes Projekt bräuchte, das sich der Sache einmal konkret annimmt.“

Hier wurde die Problematik also über ein interdisziplinäres Board sichtbar und führte so zum Start des Projekts, denn alle Beteiligten hatten bereits den Handlungsbedarf erkannt. Trotz alledem gilt hier wie überall, dass dieses Projekt möglichst nahe an der IT-Leitung angesiedelt werden sollte, um auch während des Verlaufs alle notwendigen Stellen mitzunehmen und zu bewegen.

Inkrementelle Einführung

Die Einführung eines solchen Tools kann aber auch über ein Pilotprojekt erfolgen. Dabei würden sich ein oder zwei Teams dafür entscheiden, die Automation – begrenzt auf ihren Bereich – einzusetzen. Voraussetzung dafür ist natürlich die Freiheit, solche technologischen Entscheidungen treffen zu dürfen.

Durch das Pilotprojet wird bereits alles angeschlossen und ausprobiert, was für den betroffenen Bereich notwendig ist. Man kann praktische Erfahrungen sammeln und lernen, wie das im Zusammenspiel mit der eigenen Technologie funktioniert.

„Auch diese Option haben wir schon mehrfach erlebt und begleitet“, berichtet Christoph Stock. „Und wenn es dann im gegebenen Bereich mit der kleinen Installation für alle Beteiligten funktioniert und die Vorteile sichtbar werden, dann stellt man die Frage: Ist das nicht eine Plattform, die wir generell im Gesamtunternehmen etablieren wollen?“

Wenn dies erfolgt, kann in hohem Maße von den Erfahrungen aus dem Pilotprojekt profitiert werden.

PoC als optimaler Einstieg

Wie auch immer die Ausgangslage ist, der beste Weg, um die Praxistauglichkeit von XDM live zu erleben, ist über einen PoC (proof of concept). Hier wird zunächst einmal die Komplexität reduziert, um als potenzieller Kunde schnellstmöglich ein realistisches Bild über die wesentlichen Anwendungsmerkmale zu bekommen.

Ohne auf die sicherheitsrelevanten Features zu verzichten, lässt sich über einen PoC die eine oder andere Abkürzung nehmen, indem man z.B. verschiedene Anforderungen weglässt, die zum gegenwärtigen Zeitpunkt nicht relevant sind.

Das Wichtigste für die Etablierung des Automatisierungs-Prozesses sieht Christoph Stock darin, das gesamte Konzept einmal „von Ende zu Ende“ zu denken: „Und wenn ich dabei die eine oder andere Tabelle nicht mitnehme und eine Anforderung erst einmal zurückstelle, dann bringt mir das im Gesamtprojekt mehr als wenn ich jeden einzelnen Schritt bereits perfekt und im Endausbau umsetzen will.“ Ein PoC ist optimal geeignet, um den gesamten Prozess „von vorne nach hinten zu verstehen“. Danach lassen sich die zurückgestellten Punkte umso schneller integrieren.

„Das ist eine sehr inkrementelle Vorgehensweise und am Anfang ist es erst einmal Pionierarbeit“, so Stock. „Aber es ist erfahrungsgemäß der schnellste Weg zum Ziel.“