Testing

Welche Organisation der UI-Testautomatisierung eignet sich für das agile Umfeld?

Die grafische Oberfläche ist eine wesentliche und kritische Schnittstelle in der Interaktion mit Endkunden und soll in agilen Projekten in kurzer Zeit gründlich getestet werden. Nicht selten arbeiten ganze Teams von manuellen Testern daran, Endkunden nach jedem Release eine möglichst hohe Qualität des Produkts zur Verfügung zu stellen. Bei großen Projekten ist es oft eine mühsame Aufgabe, alle wichtigen Funktionen manuell regressiv zu testen.

23.04.2021
Lesezeit: 12 Minuten
99 Views

Ein Prozess kann die Testautomatisierung enorm beschleunigen und damit manuelle Tester entlasten. Es bleibt nur die Frage offen: „Wie soll die Testautomatisierung teamübergreifend mit maximalem Profit organisiert werden?“ Im Folgenden möchten wir die häufigsten Organisationsmodelle der Testautomatisierung im Bereich Frontend vorstellen und deren Anwendbarkeit im agilen Umfeld evaluieren.

Die passende methodologische und konzeptionelle Vorgehensweise sowie eine richtige Auswahl von Tools spielen eine wichtige Rolle für eine erfolgreiche Testautomatisierung. Ein weiterer Schlüssel zum Erfolg ist ein geeignetes Modell der Testorganisation. In der Testautomatisierung (TA) unterscheidet man im Wesentlichen drei Organisationsmodelle:

zentralisiert,
dezentralisiert und
hybrid.

Jedes Modell hat seine eigenen Stärken und Schwächen. Aber welches funktioniert am effektivsten sowohl team- als auch projektübergreifend im agilen Umfeld? Um diese Frage zu beantworten, muss man zuerst genau verstehen, wie die Testautomatisierung auch agil sein kann. Wenn wir im Oxford-Wörterbuch die Bedeutung von „agile“ nachschlagen, erhalten wir Folgendes:

„Able to move quickly and easily“,
“Able to think and understand quickly”.

Grob gesagt, um agil zu sein, müssen wir schnell reagieren und denken können. „Agile“ selbst ist eine Sammelbezeichnung für verschiedene Techniken und Regeln zur Organisation des Projektmanagements, die sich von Projekt zu Projekt leicht unterscheiden können.

Um Testautomatisierung in einem agilen Projekt erfolgreich anzuwenden, müssen wir agile Spielregeln gut kennen und befolgen [INT1]. Für uns ist es besonders wichtig, dass wir

für alle Projektstakeholder maximal transparent sind,
keine Kommunikationsbarrieren haben und
schnell auf die Änderungen im Projekt reagieren können.

Nun möchten wir uns TA-Organisationsmodelle näher anschauen und evaluieren, welche mit den erwähnten agilen Anforderungen konform sind. Außerdem möchten wir auch auf folgende Modellmerkmale eingehen, die den Erfolg der Testautomatisierung ebenfalls beeinflussen können:

Verantwortungsbereiche in Testaktivitäten und
Entwicklung von TA-Know-how.

Zentralisierte TA-Organisation

Sehr oft entscheiden sich Projekte für ein zentralisiertes Organisationsmodell, weil es auf den ersten Blick ganz praktisch und einfach aussieht. In dem Modell bilden TA-Ingenieure ein Team und kümmern sich um folgende TA-Aktivitäten:

Entwicklung des TA-Frameworks,
Aufbau von TA-Infrastruktur,
Automatisierung von Testfällen,
Testdurchführung,
Testwartung,
Testanalyse und Kommunikation der Testergebnisse im Projekt,
Aufbau einer zentralen TA-Wissensplattform,
Einhaltung der Organisationsstandards.

Abbildung 1 zeigt die Top-Level-Architektur einer zentral organisierten Testautomatisierung. Der Vorteil dieses Modells ist, dass die Entwicklerteams, sogenannte DEV-Teams, sich mehr auf die Entwicklung des Projekts und das Low-Level Testing fokussieren. Testautomatisierer kümmern sich wiederum zusammen mit den manuellen Testern um die Absicherung von Product-Features im Frontend und weisen entdeckte Defekte mittels eines Defekt-Management-Tools dem jeweiligen Team zu. Die Abnahme und Priorisierung von TA-Tasks führt in der Regel nur ein dafür verantwortlicher Product Owner (PO) in einem separaten Sprint-Review für Testautomatisierung durch.

Abb. 1: Zentralisierte TA-Organisation

Auf den ersten Blick scheint alles zu funktionieren. Irgendwann stellt sich aber oft dabei heraus, dass dieses Vorgehensmodell einige Transparenzdefizite aufweist. Das wird begünstigt durch die Tatsache, dass Testautomatisierung außerhalb der DEV-Teams agiert. Infolgedessen weiß nur der für die Automatisierung verantwortliche PO, womit sich Testautomatisierer genau beschäftigen. Für die restlichen POs bleibt Testautomatisierung teilweise eine „Black Box“. Die Situation wird auch durch die Tatsache verschärft, dass manuelle Tester beim TA-Sprint-Review oft nicht dabei sind und deswegen ein ständiges Update über die bereits automatisierten Testszenarios benötigen.

Einen wesentlichen Beitrag zur Transparenz der Testautomatisierung verschafft ein verständlicher Testreport mit einem Verweis auf die Dokumentation von Testfällen. Obwohl heutzutage die Testskripte fürs Frontend überwiegend mittels Page-Object-Model (POM) [INT2] entwickelt werden, was deren Lesbarkeit signifikant erleichtert, bleibt für manche nicht technische Stakeholder nicht leicht zu verstehen, was genau getestet wird. In diesem Fall ist es besser, auf Behavior Driven Development (BDD) umzusteigen und dadurch die Verständlichkeit der Testergebnisse für das Business zu erhöhen [INT3].

Die Informationsflüsse in einer zentral organisierten Testautomatisierung erfolgen meistens bidirektional nur zwischen dem PO und den manuellen Testern, die als Proxy zwischen Entwicklern und Testautomatisierern dienen. Welche Gefahr bringt das mit sich? Die eingeschränkte Kommunikation, insbesondere zu DEV-Teams, kann oft zu unnötigen Aktivitäten für TA-Ingenieure führen. Dies sind in der Regel die Klarstellung der Abweichungen im Frontend und Erstellung von Bugtickets für modifizierte Features. Das passiert, weil niemand das TA-Team rechtzeitig über die kommenden Änderungen informiert. Oft bleiben sogar die manuellen Tester in Unwissenheit. Bugtickets für modifizierte Features, aber auch unangekündigte Deployments oder Hotfixes sind ein Zeichen für mangelhafte Kommunikation im Projekt.

Wenn signifikante Kommunikationsprobleme auftreten, beeinflussen diese direkt die Flexibilität der Testautomatisierung und sie wird unfähig, schnell auf die Änderungen im Projekt zu reagieren. In einem solchen Fall kann man oft beobachten, dass die TA-Ingenieure an veralteten Tests arbeiten, anstatt neue Funktionalität zu testen.

Da sich in der zentral organisierten Testautomatisierung ein Team um alle technischen und nichttechnischen Aspekte des Testens kümmert, entwickelt sich das TA-Know-how auch zentral. Das ermöglicht das Erstellen und Einsetzen der anforderungsspezifischen Tools und Bibliotheken gleichzeitig in mehreren Projekten und verhilft zu einer gewissen Homogenität und Einhaltung von Organisationsstandards.

Dezentralisierte TA-Organisation

In einem dezentralisierten TA-Organisationsmodell kümmert sich jedes DEV-Team um alle TA-Aktivitäten selbst. Dies ermöglicht, das Problem der Intransparenz der Testautomatisierung innerhalb eines Teams vollständig zu beseitigen, weil das Team für sich selbst maximal transparent ist. Die TA-Transparenz eines einzelnen Teams gegenüber Mitgliedern anderer Teams bleibt dennoch verbesserungsbedürftig. Wenn die Funktionalität während des Sprints abgenommen wird, wird davon ausgegangen, dass Tests dafür geschrieben wurden und alles funktioniert. Niemand geht auf die Details des Testens ein oder dieses Thema wird gar nicht angesprochen.

Abbildung 2 zeigt das dezentralisierte TA-Modell. Dies kann sich oft sehr negativ auf die Gesamtqualität und -quantität von automatisierten Tests auswirken. Entwickler wenden viel Zeit für die Entwicklung auf und wenig Zeit für das Testen. In den meisten Fällen wird ein Entwickler es vorziehen, mit dem Release-Plan fertig zu sein, als hochwertige UI-Autotests zu schreiben und aus diesem Grunde einige Tasks in den nächsten Sprint zu verschieben. Darüber hinaus leiden End-to-End-Tests (E2E), da sich jedes Team hauptsächlich darauf konzentriert, die Tests für eigene Features zu schreiben. Die Probleme der Testqualität und E2E-Testing sind einfach zu lösen, indem jedes Team einen TA-Ingenieur einstellt. Einer davon kann sich überwiegend mit E2E-Testing beschäftigen. Aus Budgetgründen können sich das aber nicht alle Projekte leisten.

Abb. 2: Dezentralisierte TA-Organisation

Die Kommunikation zwischen den Teams ist normalerweise gut, was für die Testautomatisierung ein großes Potenzial birgt. Die Teams können Anpassungen in den Testszenarios und Testskripten unmittelbar nach Änderungen im Code vornehmen. Das kann die Testautomatisierung sehr flexibel und anpassungsfähig machen. Im Normalfall sind auch die manuellen Tester rechtzeitig über die kommenden Änderungen informiert und können DEV-Teams jederzeit mit dem Testen unterstützen.

Während bei der Einhaltung von Standards und Know-how in der zentralisierten Organisation der Testautomatisierung alles in Ordnung ist, ist im dezentralisierten Modell nicht alles so einfach. Warum? Weil jedes Team seine spezifischen TA-Probleme hat und sie mit verschiedenen passenden Tools, Techniken und Bibliotheken löst. Als Folge führt dies zu erhöhten Aufwänden und erschwert die Wiederverwendbarkeit von TA-Ergebnissen in anderen Teams. Darüber hinaus muss man beim Austausch von Teammitgliedern auch für sie den Zusatzaufwand für die Einarbeitung in die Testautomatisierung einkalkulieren. Teams können zwar abstimmen, dasselbe Testframework und dieselbe Programmiersprache zu verwenden. Trotzdem wird in einer dezentralisierten TA-Organisation eine Inkonsistenz bei der Verwendung von Methoden und Ansätzen sowie ein unterschiedliches Know-how-Niveau in Bezug auf die Testautomatisierung entwickelt.

Hybride TA-Organisation

Das letzte TA-Organisationsmodell ist ein Hybrid aus den zuvor beschriebenen Modellen und versucht, sowohl die positiven Eigenschaften der beiden Modelle zu übernehmen als auch deren Nachteile zu unterdrücken. In dieser Lösung gibt es wie im zentralisierten Ansatz eine Kerngruppe von TA-Experten, die Automatisierungslösungen entwickelt und sich mit folgenden Aktivitäten beschäftigt:

Auswahl, Entwicklung und Anwendung von Technologien und Werkzeugen (sowohl zugekauften als auch eigenen,
Implementierung und Wartung von Bibliotheken, Konfigurationen und Schnittstellendefinitionen,
Verantwortlichkeit für die Testinfrastruktur, sowohl Inhouse als auch in der Cloud, Umgebungen, Server-Racks, virtuelle Maschinen, Container usw.,
Verantwortlichkeit für die Wartung, Aktualisierung des Core-Frameworks und der gemeinsamen Bibliotheken usw.,
projektübergreifende Unterstützung von Teams mit dem TA-Framework und TA-Know-how,
Durchführung von Schulungen, um die Best Practices der Testautomatisierung zu diskutieren und zu demonstrieren,
Durchführung von Code-Reviews der von den Teams implementierten und automatisierten Tests.

In dem Modell konzentriert sich das TA-Team mehr auf die technischen, architektonischen und organisatorischen Aspekte der Automatisierung und weniger auf das Testen selbst.
Abbildung 3 demonstriert die High-Level-Sicht des hybriden TA-Organisationsmodells. Das TA-Team ist verantwortlich für alle Framework-spezifischen Helper und Projektkonfigurationen.

Abb. 3: Hybride TA-Organisation

DEV-Teams, ähnlich wie in dem dezentralisierten Vorgehen, befassen sich neben dem Schreiben und der Wartung von projektspezifischen automatisierten Testfällen auch mit allen damit verbundenen Testaktivitäten wie Testreporting und Bugtracking.

Das hybride Modell verbessert nicht die Transparenz oder Informationsflüsse einzelner Entwicklergruppen im Bereich Testing. Diese bleiben ungefähr auf dem Niveau des dezentralisierten Modells und sind auf jeden Fall besser als in dem zentralisierten Organisationsmodell, in dem Testingenieure von den Teams abgekapselt sind und hauptsächlich nur mit dem manuellen Tester und PO kommunizieren.

Defizite in Transparenz oder Kommunikation können durch separate Sitzungen, in denen Testautomatisierer und manuelle Tester von jedem Team teilnehmen und sich austauschen, nachgebessert werden. Zunehmend wird auch ein globales Onlinedashboard mit mehreren Kanbanboards für jedes Entwicklungsteams eingesetzt. Ein solcher Service wird beispielsweise von https://miro.com/ angeboten und ermöglicht es, sehr komplexe Boards zusammenzustellen und die Aktivitäten aller Teams an einem Ort zu tracken.

Die Präsenz eines zentralen TA-Teams kann jedoch einige kritischen Probleme der oben genannten Modelle unterdrücken oder sogar beseitigen. Das TA-Team kann den Entwicklern praktische Workshops anbieten und dort seine Testexpertise und Know-how in der Testautomatisierung teilen. Dadurch kann die mangelhafte Qualität der automatisierten Testfälle (wie es oft der Fall beim dezentralisierten Vorgehen ist) gesteigert werden. Darüber hinaus kann das Core-Team die Pull-Requests in TA-Repositories auf die Qualität hin überprüfen und sein Feedback geben.

Das Problem des Nutzens von eigenen TA-Tools in unterschiedlichen Projekten ist nicht mehr relevant, weil das TA-Team für die Auswahl, die Integration und den Support in Projekten verantwortlich ist. Auch im hybriden Modell sollte man das E2E-Testing nicht vergessen. Einer der Testautomatisierer aus den Teams kann diese Verantwortung übernehmen.

Fazit

Im agilen Umfeld wird großer Wert auf die Transparenz, barrierefreie Kommunikation im Projekt und Anpassungsfähigkeit gelegt. Die UI-Testautomatisierung stellt dabei keine Ausnahme dar. Neben hoher Effizienz muss sie zunächst diese Anforderungen erfüllen. Die Wahl eines Modells für die Organisation der Testautomatisierung bestimmt den erforderlichen Aufwand, um eine ausreichende Transparenz im Projekt zu erreichen und die erforderlichen Kommunikationskanäle einzurichten.

Keines der drei vorgestellten Organisationsmodelle ist ideal, jedes weist seine spezifischen Mängel auf. Unserer Meinung nach ist weder ein zentralisiertes noch ein dezentralisiertes Organisationsmodell, insbesondere für große agile Projekte, eine gute Wahl. Das zentralisierte Modell stößt auf Probleme in Bezug auf Transparenz und Kommunikation und kann deswegen auch nicht schnell auf die Änderungen im Projekt reagieren. Im dezentralisierten Modell können diese Probleme gelöst werden, es besteht jedoch ein großes Risiko, die Qualität von Autotests zu verringern und Heterogenität bei der Entwicklung der Automatisierung in verschiedenen Projekten zu erzeugen.

Der Kompromiss ist das hybride Modell, welches mit dem richtigen Ansatz bei dessen Implementierung im Projekt wertvolle Ergebnisse liefert und wirklich effektiv sein kann.