Geteilte Teamverantwortung in der (Test-)Automatisierung

Überlegen wir also, an welchen Stellen im Entwicklungs- und Testprozess Automatisierung zum Einsatz kommen kann. Ein Blick in die agilen Testquadranten von Gregory und Crispin [GrCr14] offenbart, dass vor allem die technologiebezogenen Testarten den entwicklungsbegleitenden Einsatz von Frameworks und speziellen Werkzeugen für produktbewertende nicht-funktionale Tests bedingen. In geringerem Maße werden auch die geschäftsbezogenen Tests (u. a. Akzeptanz- und Systemintegrationstests) automatisiert, die aber zum Teil – wie der explorative Test – manuell durchgeführt werden müssen.

Automatisierung geht über reine Testausführung hinaus

Ist jedoch gefordert, dass alle Änderungen der Anwendungslandschaft automatisch alle relevanten Teile des Qualitätssicherungssystems durchlaufen, geht Automatisierung weit über reine Testausführung hinaus. Änderungen am Produktivsystem umfassen neben Codeänderungen Anpassungen an Umgebungen und Daten, die automatisiert erfolgen sollten. Verbindet man alles zu einer CI/CD-Pipeline (siehe Abbildung 1), werden Automationswerkzeuge an den folgenden Stellen benötigt:

Codeanalyse,
Testausführung,
Profiling,
Umgebungsbereitstellung,
Datenbereitstellung und
Testprozessautomatisierung (die Pipeline).

Abb. 1: Automatisierungspotenzial rund um die Qualitätssicherung

Die nächste Frage betrifft die geeignete Automatisierungslösung. Meist bestehen im Unternehmen bereits (Teil-)Lösungen und neue Werkzeuge beziehungsweise Frameworks müssen in die bestehende Werkzeuglandschaft integriert werden. Gleichzeitig muss die Lösung die jeweilige Zieltechnologie optimal unterstützen. Letzteres bedingt oft eine starke Nähe zur Entwicklung, ausgeprägt durch die direkte Integration in die IDE (integrierte Entwicklungsumgebung), die Verwendung der „gleichen Sprache“ und Features wie die automatisierte Erzeugung von Testfallvorlagen für das Test-Driven Development. Die Entwickler sind jedoch nicht die einzigen Anwender einer Testautomatisierung. In den höheren Teststufen (Akzeptanz-, Schnittstellen-, Integrations- und Systemtest sowie Ende-zu-Ende-Test) sind unter Umständen Fachbereiche einzubinden, die andere Anforderungen an die Benutzbarkeit von Testautomatisierungslösungen haben.

Ein weiterer Aspekt – gerade in höheren Teststufen – ist die Anpassbarkeit der Testautomatisierungslösung an neue Technologien und damit die Zukunftsfähigkeit der gewählten Lösung. Bei jeder Lösung – kommerziell oder Open Source – kann es passieren, dass aktuelle Technologien, wie neueste Browser oder mobilen Betriebssysteme, nur mit Verzug unterstützt werden. Noch folgenschwerer ist eine vollständige Einstellung des (kommerziellen) Produkts oder die Abkehr des Contributors von der Open-Source-Lösung. Bleibt bei der kommerziellen Lösung nur die Umstellung auf ein neues Produkt und damit einhergehend die Migration aller Testfälle, erlaubt die Open-Source-Lösung die Mitentwicklung als Contributor oder ein „Forking“ für interne Zwecke – Kapazität und notwendige Skills vorausgesetzt. Open-Source-Lösungen sind in Sachen Zukunftsfähigkeit tendenziell weniger riskant als kommerzielle Lösungen, bedürfen aber gleichzeitig mehr Eigeninitiative im Support.

Strukturierte Ermittlung einer tragfähigen Testautomatisierungslösung

Wie also kann die Entscheidung für eine geeignete Lösung am besten getroffen werden? Der Aufbau auf der vorhandenen Werkzeuglandschaft ist ein guter Start, kann jedoch auch einschränken: Waren die bisherigen Problemstellungen immer Nägel und der Hammer das geeignete Werkzeug, kann sich dieses bei einem neuen Projekt trotzdem als ungeeignet herausstellen. Dann nämlich, wenn zukünftig Schrauben statt Nägel verarbeitet werden sollen. Wenn beispielsweise eine hochdynamische JavaScript-basierte Single-Page-Webanwendung getestet werden soll, reicht das Webframework Selenium allein nicht mehr aus, der JavaScript-Anteil wird gegebenenfalls besser Jasmine-basiert getestet.

Für die strukturierte Ermittlung einer tragfähigen Testautomatisierungslösung lohnt es sich daher, eine Multifaktorenanalyse durchzuführen, bei der zunächst die eigenen Anforderungen sowie die der weiteren Nutzer priorisiert werden. Bei der anschließenden Recherche werden die Fähigkeiten und Kosten potenziell geeigneter kommerzieller und Open-Source-Werkzeuge mit diesen Anforderungen abgeglichen, um eine Vorauswahl zu treffen, die dann im Rahmen eines Durchstichs erprobt wird.

Und wie viele Lösungen werden nun benötigt? Die Automatisierung in jedem Team betrifft häufig eine relativ isolierte Aufgabenstellung rund um ein Produkt und aller damit verbundenen technischen Aspekte wie Programmierparadigmen und -sprachen, aber auch das Zielsystem wie die Cloud oder mobile Endgeräte. Mit diesem Fokus muss die Automation – insbesondere mit dem Ziel der Wiederholbarkeit – nicht nur die Ausführung von Testfällen betrachten. Vielmehr muss man, um den nachhaltigen Nutzen zu stiften, den gesamten – erweiterten – Testprozess im Auge behalten:

Aktualisierung und Wartung von Frameworks wegen technischer Anpassungen,
Wartung des Testfallportfolios mit nachgelagerter Pflege der Automatisierung,
automatisierte Bereitstellung von Umgebungen unter Anwendung von Virtualisierungsmechanismen,
Initialisierung der Testumgebung mit entsprechenden Testdaten,
Simulation fehlender Nachbarkomponenten über Mechanismen der Service-Virtualisierung,
Paketierung der relevanten Assets und Verteilung in das Zielsystem zum Beispiel Container in der Cloud,
vorgelagerte automatisierte statische Analysen rund um Wartbarkeit, Security und License-Compliance,
die eigentliche Testausführung (White-Box & Black-Box) mit entsprechendem Logging und eingebautem Profiling,
Rückführung von Ergebnissen mit einem automatisierten Soll-Ist-Vergleich,
das automatisierte Reporting in Dashboard-Systeme zur Sichtbarmachung des Qualitätszustands.

Alle diese Aspekte kommen ohne entsprechende Kenntnis von Werkzeugen und deren Best-Practice-Nutzung sowie die Entwicklung angemessener Frameworks nicht aus, was die Automatisierung zu einer höchst spannenden und kreativen Aufgabe für Experten macht, die als Team zu Innovationstreibern werden. Vor allem die Abhängigkeit zu Technologien mündet daher immer in folgender Forderung:

„Automatisierer müssen in jede Scope- und Technologie-Entscheidung eingebunden werden!“

Gleichzeitig muss man aber aufpassen, die Automatisierer in den einzelnen Entwicklungs- und Testteams nicht losgelöst voneinander zu betrachten. In einem größeren Unternehmen mit verschiedenen Abteilungen, die unterschiedliche Anwendungen entwickeln und nutzen, läuft man sonst Gefahr, dass die verschiedenen Automatisierer untereinander inkompatible Lösungen einsetzen (Vorgehensweisen, Werkzeuge und selbstentwickelte Frameworks). Diese Insellösungen vervielfachen bei zentralen Änderungen an der Infrastruktur des Unternehmens den Änderungsbedarf und verhindern zudem den freien, bedarfsgerechten Austausch von Automatisierern zwischen den Abteilungen. Die Schaffung einer integrierenden Kraft zum Abgleich der Automatisierungslösungen, wie zum Beispiel einer Community of Practice, wird daher empfohlen.

Wir stellen zudem immer noch fest, dass Automatisierung häufig als nachgelagerte Aktivität – quasi in einem Miniwasserfall – betrachtet wird. Aufgrund der Vielzahl von Abhängigkeiten und des damit verbundenen Aufwands für die Automatisierung muss der Automatisierer an der Sprint-Planung beteiligt sein, damit:

technische Entscheidungen immer auch mit Blick auf den Impact auf eine laufende Automatisierung bewertet und getroffen werden,
notwendige Anpassungen an Frameworks frühzeitig bewertet werden und
der Aufwand für die Automatisierung neuer Features im Sprint beherrschbar bleibt.

Qualität und ein hoher Automatisierungsgrad liegen in gemeinsamer Verantwortung im Team und bedürfen hochqualifizierter technischer Skills im Quality Engineering (siehe Abbildung 2).

Abb. 2: Interaktion von Teams hinsichtlich Automatisierung auf Produkt- und Systemebene

Betrachten wir weiter die integrativen Tests im Zusammenspiel aller Teamergebnisse für ein Release, die ebenfalls Automatisierung benötigen. Ist in den einzelnen Teams Heterogenität bezüglich unterschiedlicher Automatisierungsansätze und Tools noch zulässig, ist im Zusammenspiel ein homogener Ansatz und Technologie-Layer notwendig. Das gilt insbesondere bezüglich Deployments und des Managements von Abhängigkeiten über unterschiedlichste Technologien.

Nehmen wir ein System an, das aus einem SAP-Kern und angelagerten Java-Komponenten besteht. Die integrierte CI/CD-Release-Pipeline muss nun dafür Sorge tragen, dass in der Testumgebung zum Zeitpunkt des Deployments die korrekten Kombinationen aus Versionsständen der Java-Komponenten und dem zugehörigen SAP-Transport – also alle zusammengehörigen Teamergebnisse – installiert werden. Moderne agile Vorgehensmodelle, welche die Interaktion einer Vielzahl von Teams berücksichtigen, wie SAFe® [SAFe], tragen diesen Anforderungen aus Testautomatisierung und Release-Orchestration durch den Aufbau integrativer Teams (System Team in SAFe®) sowie die Unterstützung mit speziellen Werkzeugen zur Integration Rechnung, wobei zentral genutzte Werkzeuge nur einmal beschafft werden müssen. Weitere Kostenreduktion entsteht durch die Vermeidung von Konflikten und Wiederholungsaufwand.

Teams besitzen eine hohe Innovationskraft, das Rad sollte jedoch nicht immer wieder neu erfunden werden. Vielmehr ist der Austausch der Teams untereinander zu fördern, sich als lernende Organisation zu verstehen und voneinander zu profitieren. Hier schafft das System Team Synergien durch die Wahrnehmung folgender Aufgaben:

aktive Moderation des Austauschs der Teams in Bezug auf Automatisierung,
Konsolidierung von Methoden,
Verallgemeinerung von Team-Frameworks und Nutzungskonzepten,
Schaffung einer gemeinsamen Code-Basis für die Wiederverwendung,
gemeinsame Bewertung der Schwächen und Stärken von Tools,
Aufbau von Skill-Profilen für das Recruiting,
Diskussion von Pros und Cons,
Schaffung gemeinsamer Best Practices,
Retrospektiven und kontinuierliche Verbesserung,
hausinternes und externes Training durch Spezialisten.

Auf diese Weise wird die Innovationskraft der Teams durch Konsolidierung – um den Begriff Standardisierung zu vermeiden – gestärkt: Die Organisation lernt.

Für eine erfolgreiche und unternehmensweite Implementierung bedarf es Spezialisten im System Team. Hierzu zählt der Quality Influencer, der als Schnittstelle und Coach für die Teams ein zentraler Anker ist. Er verbindet Entwicklungsteams mit Automatisierungsexperten und organisiert den Austausch. Automatisierungsexperten ermitteln neue und gleichzeitig konsolidierte Lösungen gemeinsam mit dem Testarchitekten. Bei Bedarf arbeiten diese Spezialisten zur Aufnahme oder zum Weiterreichen von Erfahrungswerten temporär in Produktteams mit.

Moderne (Test-)Automatisierung in agilen, modernen Technologiefeldern ist komplex und fordert hohe Lösungskompetenz, Werkzeugwissen und eine moderierte strukturierte Arbeitsteilung, damit die Organisation – und damit jeder einzelne – profitiert.