TESTSTRATEGIEN: CHALLENGE USER-AKZEPTANZ

In die haben wir nach und nach unsere gesamte Produktlandschaft integriert. Gestartet haben wir mit den Tests dort, wo wir neue Themen angegriffen haben, zum Beispiel im Bereich Medienbeobachtung und PR-Dienstleistungen. Zugleich haben wir auch ein UX/UI-Team neu aufgebaut – das lieferte dann die eigentliche Basis für das UA-Testen. Am Anfang haben sich da schon viele gefragt: Was machen die jetzt genau und worüber reden die mit unseren Leuten? Uns ging es nämlich nicht darum, die Leute Funktionalitäten auszuprobieren zu lassen, sondern darum, dass sie uns erklären, wie sie arbeiten.

Dann wurde aber bald klar, wie viel Potenzial da drinnen steckt und wie wertvoll genau dieses Feedback ist. Seitdem wird jede UI-Änderung, die wir auf der Plattform brauchen, strukturiert durchgetestet. In Folge haben dann auch unsere eigene UI-Library geschrieben – mit sämtlichen Bausteinen, die wir brauchen, damit wir nicht zum 20. Mal einen Kalender testen müssen. Damit sind wir mittlerweile sehr erfolgreich unterwegs und konnten auch die Geschäftsführung überzeugen.

Die meisten sehen einfach: Ich muss mich an ein neues System gewöhnen und habe durch das Testen auch noch eine Doppelbelastung. Deshalb braucht es an der Schnittstelle die richtigen Leute wie Projektmanager, die sie begleiten und ihnen erklären, worum es dabei eigentlich geht, warum es wichtig ist, dass sie mitmachen und warum es zum Beispiel wichtig ist, Testfälle zu formulieren, auch wenn sie vielleicht ohnehin wissen, was sie zu testen haben. Weil man die Testfälle braucht, um beim Testmanagement nicht im Blindflug unterwegs zu sein. Und vor allem gilt es auch aufzuzeigen, welche Vorteile die Fachbereiche durch das Testen bekommen, zum Beispiel, dass sie sich auch wirkungsvoller mit ihren Anforderungen einbringen können, wenn sie sich mit dem System jetzt aktiv auseinandersetzen.

Gleichzeitig ist es sehr wichtig, dass die Projektmanager an der Schnittstelle zu den Fachbereichen den Usern dort auch deutlich zeigen, dass man sie beim Testen so weit wie möglich unterstützt und ihnen dabei, zum Beispiel durch den Einsatz von KI beim Erstellen der Testfälle, möglichst viel an repetitiven Tätigkeiten abnimmt.

Bei einer Standard-Software-Einführung in einem kleinen Geschäftsfeld von uns – zum Beispiel in einem CONTAINEX-Werk – mit 50 Usern und fünf Teilprozessen sind kleine Teams von Key Usern, die am Customzing arbeiten, bislang zumeist die wirtschaftlich effizientere Lösung als großangelegte Testautomatisierungsprojekte und -Tools. Mit dem Nachteil, dass es für ein paar Leute nicht allzu spannend ist, zu testen und dass man sie immer wieder daran erinnern muss, dabei auch an Sonderfälle zu denken.

Allerdings geht der Trend hier auch für uns in die Richtung Automatisierung: Zum einen entwickeln sich insbesondere durch den Einsatz von KI laufend neue Möglichkeiten, und zum anderen wird der Spagat zwischen hochindustrialisierten Prozessen und traditionellen Test-Setups zunehmend zu einer Herausforderung.

Klar ist: Sie müssen uns sagen, was sie haben wollen, aber sie können nicht gleich von Beginn weg alles wissen, was sie brauchen. Gerade deshalb gehen wir zunehmend in die Richtung, dass die User uns für ihre Anforderungen vor allem ihre Prozesse erklären und nicht, wo auf dem Bildschirm ein Button sein soll.

Unsere Szenarien sind zum Teil auch für das Testen sehr herausfordernd, weil da unterschiedlichste Komponenten zusammenspielen. Von Software bis zur Hardware inklusive Router im Auto, Drucker und Bankomatkassa umfasst das sozusagen den ganzen Bauchladen, den unsere Pannenfahrer:innen dabeihaben müssen, um von der Pannenhilfe bis zum Abschluss einer neuen Mitgliedschaft sämtliche Services vor Ort abdecken zu können. Wir betreiben auch viel Aufklärungsarbeit, um zu vermitteln, dass wir uns bemühen, diese Komplexität hinter der Anwendung möglichst userfreundlich zur Verfügung zu stellen. Trotzdem lässt sich nicht verhindern, dass die erste Frage beim Testen noch immer manchmal lautet: „Warum ist dieser Button nicht mehr an der Stelle, an der er immer war?“ Der Wunsch, Gewohntes zu behalten, ist nach wie vor stark ausgeprägt – das merkt man auch beim Testen deutlich

Deshalb möchte ich die User aus den Fachbereichen beim Testen nicht aus der Verantwortung entlassen, obwohl auch wir dabei zunehmend KI einsetzen. Einen der härtesten Tests beim Entwickeln stellen vermutlich die Leute aus der Buchhaltung dar. Die haben so viel implizites Wissen in ihren Köpfen, dass sie auf den ersten Blick erkennen, dass irgendwo etwas nicht stimmt und zum Beispiel ein Konto falsch abgeleitet wurde, auch wenn die Developer und Business Analysts auch noch so gewissenhaft getestet haben. Deshalb ist es so wichtig, dass man die Kolleg:innen an Bord holt und dass sie ihre Tests auch aufzeichnen und replizieren und so ihr Wissen weitergeben.

Das heißt, Testen bedeutet für alle Beteiligten – auch für Anwender:innen aus den Fachbereichen – nicht nur eine lästige Pflicht, sondern verschafft auch Erkenntnisgewinn und Nutzen. Das klarzumachen, ist sehr wichtig, weil das Business natürlich zunächst einmal vorrangig den Aufwand sieht, der durch das Testen entsteht. Diesen Nutzen muss man allerdings auch mit dem entsprechenden organisatorischen Setup transportieren. Wenn ich beispielsweise als IT mitten im Jahresabschluss einen Release machen will, dann werde ich mir schwertun, den Nutzen klarzumachen.

Die IT neigt ja noch immer teilweise dazu, den Anwender:innen und den Fachbereichen eher technokratisch erklären zu wollen, wie ihre Systeme und Abläufe am besten auszuschauen hätten. Für eine echte End2End-Betrachtung ist es aber notwendig, sich in die Business-Perspektive hineinzuversetzen. Das ist natürlich eine Herausforderung und die ist umso größer, je unterschiedlicher die verschiedenen Fachbereiche und damit auch die User selbst agieren und ticken – so wie das zum Beispiel bei uns der Fall ist.

Ein gut bewährtes Modell der Zusammenarbeit konnten wir mit übergreifenden Produktteams erreichen, also Teams, die über Abteilungsgrenzen hinweg gebildet werden und ein Produkt, eine IT-Lösung für das Business gemeinsam betreuen. Der TestmanagerIn im Team ist hier unmitttelbar mit dem Business abgestimmt. Das Team arbeitet dabei genauso an der Automatisierung von Testfällen, wie an manuellen Tests.

Natürlich lässt sich argumentieren, dass es im Eigeninteresse der User in den Fachbereichen liegt, eine Anwendung, mit der sie arbeiten, auch selbst zu testen, weil sie ja etwaige Fehler selbst ausbaden müssen. Das alleine reicht aber nicht. Wenn man dem Fachbereich und den Anwender:innen die Sinnhaftigkeit der Qualitätssicherung beim Testen nicht nahebringen kann, dann schafft das von Beginn weg Frustration. Und dann wird das fertige Produkt auch nur sehr schwer die nötige User Akzeptanz erreichen.

Es ist auch wichtig, möglichst alle User auf einem bestimmten Qualitätslevel einzubinden. Wenn einige akribisch testen und viele andere gar kein Feedback liefern, geht das auf Kosten der Messbarkeit und Aussagekraft.

In Bereichen, in denen agil gearbeitet wird, findet der Kontakt mit dem Fachbereich einfach viel häufiger statt als bei einem Releasewechsel eines Systems, den man nur alle paar Jahre durchführt. Je kürzer die Zyklen sind, desto kleiner wird der Gap natürlich auch beim Testen, weil die Test Cases und damit auch der Aufwand für das Business viel kleiner werden.

Wir setzen dabei auf eine Kombination aus Product Owner, die in der IT sitzen, und Business Owner. Die Business Owner sind dafür zuständig, die Requirements aus den Märkten einzuholen und zu priorisieren und an die Product Owner weiterzugeben. Dieses Duo funktioniert bei uns in den meisten Teilen ziemlich gut.

Beim unserem Geschäft in Österreich liegt der Schwerpunkt auf langen Vertragslaufzeiten – im Schadenunfallsgeschäft sind das regulär zumindest 10 Jahre, bei Lebensversicherungsverträgen sind das sogar 40 oder 50 Jahre – und es ist unüblich während dieser Laufzeit die Bedingungen zu ändern. Bei Microinsurance-Produkten sehen wir aktuell dagegen noch kein signifikantes Geschäftswachstum. Auf dieser Basis richten wir auch unsere Strategie beim Testen auf.

Gerade bei der Mainframe-Ablöse in der Finanzbranche wurden in der Vergangenheit oft unrealistisch hohe Erwartungen geweckt. Eine Backend-Migration ist nicht in drei Jahren erledigt – dafür muss eine Vielzahl an verschiedensten Kernprozessen umgestellt werden. Deshalb liefern wir die Releases iterativ aus und holen die Fachbereiche beim Testen bewusst erst dann an Bord, wenn wir glauben, die nötige Qualität bieten zu können. Damit schlagen wir nicht einen komplett agilen Weg ein, der es ermöglicht, den Fachbereichen stabile Prototypen weiterzugeben und nicht zu schnell jeden kleinen technischen Erfolg zu verkaufen … um dann vielleicht das Feedback zu bekommen: Das geht so nicht.

Hier nach wie vor mit Lasten- und Pflichtenheft zu arbeiten, ist zum Scheitern verurteilt, weil beim einen die Leute oft irgendetwas hineinschreiben, und weil sie das andere häufig nicht wirklich verstehen. Ein Konzept, das bei uns beim Testen sehr gut funktioniert, ist das der User Stories.

Wir haben das Testen auch in Quality Gates integriert – das nimmt den reinen Schulungscharakter weg und macht klar, dass sie sich selbst aktiv einbringen müssen, damit die Anwendungen und Werkzeuge, mit denen sie arbeiten, auch funktionieren – und dazu gehört es eben auch, wenn nötig beim Testen beispielweise immer wieder die gleichen Daten anlegen. Das funktioniert vor allem bei kleineren Projekten sehr gut. Man braucht allerdings auch immer gute Master Projektmanager, die die Leute in ihren konkreten Arbeitsszenarien abholen.

Wenn ich eine ganz neue Applikation bekomme, ist das Testen für die User generell einmal ein spannenderes Thema als eine Migration auf eine neue Version eines bestehenden Systems. Durch eine Migration ändert sich für den Fachbereich häufig nicht so wahnsinnig viel – man hat danach fast die gleiche Funktionalität zur Verfügung. Umso wichtiger ist es durch entsprechendes Testen sicherzustellen, dass genau das reibungslos klappt, und darüber hinaus vor allem den konkreten Mehrwert, der durch die Migration für die User bei ihrer Arbeit entsteht, zu vermitteln – und dazu sind User Stories auch aus unserer Erfahrung heraus ein sehr gutes Mittel.

Ähnliche Unterschiede gibt es zwischen den einzelnen Fachbereichen: Es gibt Abteilungen, die sagen, dass sie wissen, wie ihre Abläufe, beispielsweise im Fall einer Verrechnungsabteilung ihre Billing-Prozesse, funktionieren, und dass sie auch genau wissen, was sie diesbezüglich testen müssen. Und es gibt andere Fachabteilungen, die gar nicht wissen, wie sie einen Testfall formulieren sollen. Deshalb gilt es sehr individuell ans Testen heranzugehen, um die Leute wirklich bei ihrer Arbeit und beim Nutzen, der daraus für sie entsteht, abzuholen.