TEST- UND LAUNCH-STRATEGIEN: WIE AGIL IST DAS BUSINESS?

Ein Paradebeispiel für Österreich und gerade für den Banken- und Versicherungssektor ist die Ablöse des Mainframe, der flächendeckend in fast schon tektonischen Geschwindigkeiten abläuft. Gleichzeitig gibt es den Trend in Richtung Microinsurance, auch wenn der sich in Österreich noch nicht allzu stark niederschlägt. Wir haben beispielsweise im Konzern ein Projekt in Südosteuropa, gemeinsam mit einem asiatischen Softwareanbieter, der auf digitalen Vertrieb spezialisiert ist.

Das sind komplett unterschiedliche Welten, die da aufeinanderprallen: Auf der einen Seite braucht es zehn Jahre oder mehr, um ein Backend zu erneuern, auf der anderen Seite haben wir es mit Einführungszeiten von drei bis sechs Monaten zu tun. Das bedeutet natürlich auch ganz unterschiedliche Herangehensweisen an das Testen. Die Backend-Ablöse ist ein Marathon, bei dem man sich sehr gut überlegen muss, wann man sich den Fachbereich für das Testen an Bord holt. Wenn ein Microinsurance-Produkt dagegen in ein paar Monaten marktreif sein muss, muss es gemeinsam mit dem Business entwickelt werden und muss jede Änderung im User Interface vom Fachbereich sofort getestet werden.

Vor allem kann ich mit Unterstützung von KI die Durchführung des Testens für das Business viel schneller, effizienter und komfortabler gestalten. Dinge wie Large Language Models bieten hochinteressante Möglichkeiten, um erstklassige Testfälle zu erstellen, indem ich sie mit allen möglichen Dokumenten wie User Stories, Requirements, User-Dokumentationen und Pflichtenheften füttere. Ich kann mit KI Testdaten erzeugen und brauche niemanden mehr, der oder die sie dazu reinklopft, und ich brauche keine komplexe Dokumentation mehr, um eine Applikation zu verstehen.

Das heißt, ich kann den Fachbereich genau von jenen repetitiven Tätigkeiten entlasten, die zu Fragen führen wie: Warum muss ich zehnmal die gleichen Daten neu anlegen? Warum muss ich wieder Automationsfälle schreiben, wenn jemand anderer schon Requirements, Pflichtenhefte und User Stories erstellt hat, wenn also aus dem Fachbereich ohnehin schon alles gesagt ist? Das kann man den Usern ja kaum wirklich verständlich machen.

Ich habe mich schon vor zehn Jahren mit neuen Standards beim Testen beschäftigt, tatsächlich hat sich seit damals meiner Erfahrung nach aber nicht wirklich grundsätzlich viel verändert. Viele praktizieren heute nach wie vor so eine Art exploratives Testen nach dem Motto: Dann klick ich einmal dahin.

Ich habe das selbst einmal in einem Eye Tracking Labor der FH Burgenland erlebt. Es war sehr spannend, dort zu sehen, wohin die User beim Testen schauen, was sie tatsächlich nutzen und was dabei alles nicht kongruent läuft.

Bei unserem Mitgliederverwaltungssystem haben wir etwa gesehen, dass es nicht viel Sinn macht, die Kolleg:innen im Backoffice testen zu lassen, sobald man zum Beispiel 80 Prozent der Standardaufgaben fertiggestellt hat, auch wenn sie extrem viel an Wissen einbringen können. Ihre Tätigkeit findet nämlich erst ganz am Ende der Prozesskette statt und besteht zu einem Großteil aus unterschiedlichsten Sonderfällen, die vorne am Frontend nicht erledigt worden sind.

Deshalb ist es sinnvoller, diese Kolleg:innen erst dann in das Testen einzubinden, wenn es um all diese Ausnahmen geht, und wenn man sie dort abholen kann, wo sie mit ihrer Arbeit einsetzen.

Wir haben bei LKW WALTER vor sieben oder acht Jahren begonnen, auf agile Entwicklung umzustellen und leben sie mittlerweile wirklich durchgängig. Wir lösen dabei auch viele Legacy-Themen ab und bauen sie als Greenfield komplett neu, um sie End2End zu digitalisieren und zu automatisieren. Wir haben heute 60 bis 70 Entwickler:innen, die Code produzieren und deployen problemlos bis zu 20 Mal in der Woche. Und wir haben für jedes Thema Product Owner aus dem Business und Business Analysts, die bei der Produktentwicklung mitarbeiten und auch als Requirement Engineers agieren und dabei helfen, User Stories zu schreiben und Abnahmekriterien zu definieren.

Die Leute in den Fachbereichen zum Beispiel dazu zu bringen, wirklich zu priorisieren und zwar nicht nur alles mit Prio 1, war allerdings nicht einfach und ging nicht von heute auf morgen. Die User mussten auch lernen, damit umzugehen, dass sie nicht mehr einfach auf die Schnelle in der Entwicklung anrufen und ihre Vorstellungen einwerfen konnten.

Häufig gibt es bei einem Projekt einzelne Personen, die komplett auf Widerstand schalten und diesen Widerstand löst man nicht allein mit Testkonzepten und mit Automatisierung auf – dafür braucht es genauso Soft Skills und Kommunikation.

Ein wichtiger Schlüssel ist dabei eben die Rolle der Projektmanager – unabhängig davon, ob sich diese Rolle im jeweiligen Unternehmen genauso bezeichnet und ob die von jemandem intern eingenommen wird, oder ob sie ein externer Partner übernimmt, so wie wir das zum Beispiel oft machen. Entscheidend ist, dass diese Funktion die Schnittstelle zwischen dem Business, also den Fachbereichen, und der IT bildet und dazu die Sprache beider Seiten versteht und spricht und die Leute aus diesen beiden Bereichen wirklich mitnimmt. Und das geht am besten in Kleingruppen. Wir stellen das bei unseren Kundenprojekten immer wieder fest: Man kann das beste Testkonzept und noch so sauber aufgesetzte Prozesse und Handbücher haben – wenn der Fachbereich nicht mit an Bord ist und mitspielt, wird es nicht wirklich funktionieren.

Niemand in einem Fachbereich hat wirklich darauf gewartet, dass die IT agiles Arbeiten, Entwickeln oder Testen ausruft – im Gegenteil. Viele haben gedacht, das bedeutet, dass sie sich jetzt nicht mehr auf Planungen verlassen können, und der größte Schmerz der Kolleg:innen war, als sie realisiert haben, dass sie plötzlich intensiv als Teil des Projekts eingefordert waren, damit die IT die entsprechenden Applikationen bauen kann. Da war die Reaktion zunächst einmal: „Das ist für uns extrem mühsam, wenn wir da so tief mit drinnen sind – die Anwendungen zu bauen und zu testen, ob sie funktionieren, ist Eure Sache.“

Hier das neue Setup zu etablieren, in dem alle verstehen, dass sie ein Teil davon sein müssen, war schon harte Arbeit. Letztendlich sehen und erleben jedoch heute alle diese neue Stufe der Qualität und des Nutzens, die mit diesem Ansatz möglich sind.

Da ist es notwendig, dass die Herausforderungen des Business zur gemeinsamen Aufgabe werden und dass die Entwickler und der jeweilige Fachbereich – am besten koordiniert durch Product Owner und eventuell agil in Sprints – gemeinsam an Lösungen arbeiten. Und dass sie dabei die jeweils wichtigsten Produkt-Features zuerst umsetzen und gleichzeitig die Testautomatisierung ausbauen. Alle zwei Jahre ein Pflichtenheft zu schreiben und dann zu versuchen, es umzusetzen und großangelegt zu testen, ist da nicht machbar.

Gleichzeitig gibt es insbesondere für einen Energieversorger Bereiche und Themen, in denen auch und gerade beim Testen Null-Fehler-Toleranz herrscht. Wenn daran hängt, ob es auch nur den kleinsten Stromausfall gibt, kann man sich einfach nicht leisten, mit einem Produkt rauszugehen, das nicht absolut fehlerfrei funktioniert.

Das beginnt damit, dass ein paar Leute quick und dirty einen Code schreiben, ohne zu testen, um mit einem Click Dummy überhaupt einmal auszuprobieren: Ist die Idee es wert, sie weiter auszubauen? Und wenn das der Fall ist und das Ganze die nötige Reife erreicht hat, geht es auf die normale Software-Entwicklungsebene, wo wir dann beispielsweise auch die User Stories schreiben. Wenn wir einen ersten Prototyp bauen, haben wir allerdings manchmal das Problem, dass dann ein Bereich diesen Prototyp gleich weiter ausbauen möchte. Dann muss man allerdings klar Stopp sagen – weil ein Prototyp dazu da ist, weggeschmissen zu werden – so wie es zum Beispiel in der Automotive-Industrie selbstverständlich ist.

Mit dem Thema MVP beschäftigen wir uns heute ganz gezielt in einem kleinen Team und haben dabei das Glück, dass viele unserer 190 Abteilungen sehr ähnliche Abläufe haben. Vor diesem Hintergrund tut man sich leichter, einen Product Owner zu finden, der mit ein oder zwei kleinen Abteilungen die Pionierrolle übernimmt und zunächst einmal ein MVP mit erarbeitet, bevor wir das für alle User freischalten. Dadurch haben wir auch keinen echten Bedarf an großangelegten User Accepting Tests.

Bei MVPs gibt es allerdings manchmal die Problematik, dass die Fachbereiche da möglichst viel hineinpacken möchten und sich damit vieles verzögert. Ein Grund dafür ist die Befürchtung, dass sie nach Abschluss eines Projekts vielleicht zu lange warten müssen, bis all ihre anderen Anforderungen integriert werden.

Wir steuern dem entgegen, indem wir ein fixes Team für das jeweilige Produkt etablieren, das für das Business dauerhaft Ansprechpartner bleibt – und damit auch sozusagen personifizierter Garant dafür ist, dass auch um nach dem Go Live des MVP die zusätzlichen Features integriert werden.

Bei genauerer Nachfrage stellt sich allerdings heraus, dass man sich darunter ein vollumfängliches Produkt mit sämtlichen Features vorstellt, weil das, was die APA an Ihre Kunden rausgibt, absolut Feature-komplett sein und fehlerfrei funktionieren muss. Das ist Anspruch und Kulturmerkmal der APA – aber nicht die Idee des MVPs.

Diese Lücke macht das Ganze sehr schwierig, weil es eine Phase nach dem Prototyp gibt, in der man das Feedback der Kunden braucht.

Viele junge Mitarbeiter:innen im Business zeigen ein viel größeres Commitment für die Bedeutung der IT und bringen sich dementsprechend auch viel aktiver bei den Demands und beim Testen ein.

Für die ist es ganz selbstverständlich, wenn beim Testen ein Software-Produkt nicht vom ersten Tag an völlig fehlerfrei funktioniert.

Wir haben zum Beispiel eine Gruppe von 15.000 Mitgliedern, die zunächst quasi intern einen Click Dummy erhalten – insbesondere, wenn es um Web-Services geht, die wir dann sehr breit zur Verfügung stellen. Dabei muss man noch keine Schnittstellen anbinden, muss noch nicht austesten, ob die die APIs alle sauber laufen und erspart man sich sehr viel an Kosten.

Die User verstehen das auch und liefern uns valide Rückmeldungen, ob der Prozess für sie passt oder nicht. Um dann aber tatsächlich in der Breite an Kund:innen rauszugehen, braucht es mehr als einen Prototyp – dazu muss man schon ein echtes Produkt schnitzen.

Wir haben zum Beispiel eine Business-Einheit, die sich selbst praktisch als Software-Firma definiert und auch die entsprechende Agilität einbringt – mehr kann man als IT und als Digitalisierungsverantwortlicher kaum erreichen.

In anderen Bereichen gibt es extreme Langläufer-Themen und Projekte, die über Jahre oder auch Jahrzehnte laufen. Das ist für die Digitalisierung oft eine ziemliche Herausforderung und zwar nicht nur technologisch, weil wir ja in einem extrem technologiegetriebenen Umfeld agieren, sondern vor allem, weil man hier auf ein komplett anderes Verständnis trifft. Da gibt es dann mitunter großen Diskussionsbedarf zwischen Business und IT, und da muss man als IT auch sehr sorgfältig überlegen, welche Schritte man wann setzt.

Wenn man die IT-Systemlandschaft entsprechend der Technologiestrategie entwickeln möchte und wenn sich Governance zur gewinnbringenden Technologiestrategie wandeln soll, ist das gegenseitige Vertrauen zwischen Business und den IT-Architects erforderlich. Und um das zu schaffen, braucht es auf der IT-Seite reichlich Hands-On-Mentalität.