Testautomatisierung, ja! Doch wer macht's?

Wir leben in einer agilen Welt. Alles wird schneller! Auch, oder vor allem, in der IT. Der Weg und die Zeit zwischen Anforderungen aus den Fachbereichen, aus dem Markt oder seitens unterschiedlicher Regulative und deren Umsetzung durch die IT-Abteilungen werden kontinuierlich kürzer. Gleichzeitig nimmt die Komplexität von Anwendungen und Systemlandschaften dramatisch zu. Die hochgradige Vernetzung der Systeme und eine immer größere Zahl an Endgeräten sowie der Anspruch, stets „real-time“ beliebig viel an Informationen zu liefern, steigern den Druck, schnell und in hoher Qualität neue Anwendungen auf den Markt zu bringen.

Continuous Testing

Um diesen Anforderungen gerecht zu werden, haben sich in den letzten Jahren in SW-Entwicklungsprojekten agile Konzepte, Methoden und Werkzeug wie Scrum, Unified Process, Kanban usw. immer mehr durchgesetzt. Das Schlagwort „DevOps“ ist in aller Munde und verspricht blitzschnelle Durchlaufzeiten [Swi18]. Und was den Test betrifft, so bleibt diesem auch in dieser Wortkonstruktion scheinbar nur der Platz zwischen „v“ und „O“. Manchmal liest man auch „Dev-TestOps“, aber das holpert, dauert zu lange und Test ist sowieso Teil der Entwicklung – das kommt einem doch bekannt vor, oder?

Durch ein agiles Vorgehen wird vor allem die Zeit zwischen Anforderungen und Entwicklung deutlich verkürzt, die Qualitätssicherung stellt – auch wenn sie wichtiger Teil des agilen Vorgehens ist – nach wie vor einen gewissen „Engpass“ dar. Testen ist sowohl innerhalb des Sprints in den agilen Teams als auch nachgelagert, wie im Abnahmetest, durchzuführen. Und das immer wieder – Continuous Testing als Teil dieser „Continuous Everything”-Ansätze.

Doch wie ist dieser Spagat zwischen schneller Umsetzung und Erfüllung hoher Qualitätserwartung überhaupt zu schaffen? Testen erfordert eine gewisse Zeit – selbst im agilen Umfeld lassen sich Testaufwände nicht vollständig zur Entwicklung parallelisieren. Ein uneingeschränktes Aufstocken von Testexperten ist nicht nur aus budgetären Gründen wenig sinnvoll, sondern verursacht auch unnötige Koordinationsaufwände.

Und hier kommt nun „Testautomatisierung“ ins Spiel. Durch das Minimieren von manuellen Testaufwänden und das Schaffen eines hohen Automatisierungsgrades soll für schnelle Testdurchlaufzeiten, eine hohe Testabdeckung und gleichzeitig minimale personelle Aufwände gesorgt werden. Doch was gibt es dabei zu beachten [Bau17]?

Die Automatisierungslösung ist nicht immer rasch erhältlich

Viele Jahre lang war Testen eine größtenteils manuelle Tätigkeit. Im klassischen V- oder Wasserfallmodell war im Idealfall der Testexperte bereits in der Anforderungserstellung eingebunden, der Testmanager konnte sich frühzeitig mit der Erstellung eines Testkonzeptes und einer Teststrategie beschäftigen, in dem Testobjekte, Kritikalität, Priorität, Testabdeckungsgrad, Testendekriterien usw. definiert wurden. Darauf aufbauend wurden in der Testvorbereitung in passenden Tools Testszenarien und Testfälle beschrieben und in der Testdurchführungsphase die Testfälle manuell durchgeführt und deren Ergebnisse beziehungsweise abweichende Fehler ebenfalls manuell dokumentiert.

Dies erfordert hohes fachliches und methodisches Know-how, weniger jedoch Programmierkenntnisse oder tiefer gehende IT-Kenntnisse.

Testautomatisierung ist heutzutage weniger das „Bedienen“ eines Testautomatisierungswerkzeuges, wie es in den Anfängen der Automatisierung vor allem bei Capture-Replay-Tools der Fall war, sondern vielmehr das Verstehen und Analysieren von Systemlandschaften, das Konzeptionieren und Entwickeln von Automatisierungsframeworks, das Skripten von automatisiert durchlaufenden Testfällen und das Erstellen von Ergebnisberichten. Diese Tätigkeiten werden von einer Vielzahl an Werkzeugen unterstützt. Dennoch braucht es zur Implementierung einer nachhaltigen Automatisierungslösung Spezialisten, die neben einer fundierten IT-Ausbildung gute Programmier- und Architekturkenntnisse sowie ein fachliches Verständnis und einen Sinn für Testmethoden und Qualitätsmerkmale besitzen. [Sne12]

Doch hier wird’s dann schwierig: Wer insbesondere die programmiertechnischen Skills mitbringt, will meistens eines nicht: Testen. Technikaffine Informatiker wollen lieber programmieren, Systeme designen, vielleicht Scrum Master, Software- oder Enterprise-Architekten sein. Auf jeden Fall wollen sie etwas schaffen, das man „nutzen, bedienen, anwenden kann“, etwas, das – wie man so schön sagt – „das Licht der Welt erblickt“ ... Welches Automatisierungsframework hat jemals Beachtung gefunden (auch wenn viel Programmierarbeit darin steckt), welche Testskripts sind in Dankesreden erwähnt oder auch nur in irgendeinem Store „bewertet“ worden? Die Lorbeeren erhält immer das „zu testende Ding“, nicht das „Ding, das testet“.

Da sowohl am Arbeitsmarkt als auch in den IT-Unternehmen kaum bis wenig Mitarbeiter verfügbar sind, die „Testautomatisierungsexperte“ oder „Testautomatisierungsarchitekt“ als Berufsbild vor Augen haben, hinkt die Umsetzung von Testautomatisierungsvorhaben oft den Wunschvorstellungen hinten nach.

Viele fürchten sich vor der Rolle „Testautomatisierer“

Stellen Sie sich eine Gruppe von zehn Entwicklern vor, die gefragt werden, ob jemand für die nächsten sechs Monate ein Testautomatisierungsprojekt übernehmen möchte? Sie können sicher sein, dass Sie in zehn angstgeweitete Gesichter blicken werden. Freiwillige Meldungen sind nahezu ausgeschlossen. Ähnliches Verhalten werden Sie vermutlich bei manuellen Testexperten vorfinden – jedoch aus entgegengesetzten Gründen. Entwickler befürchten, unterfordert und gelangweilt zu sein, weil die Aufgabe zu trivial ist, beim Tester ist es genau das Gegenteil.

Testautomatisierung ist eine langfristige Investition

Die Entscheidung, in Entwicklungsprojekten verstärkt auf Testautomatisierung zu setzen, beruht oft auf der Annahme, dass mit dem Einsatz eines Testautomatisierungswerkzeuges sofort massive Ressourceneinsparungen und die Verkürzung der Testzeiten zu erwarten sind. Dies ist jedoch selten der Fall. Fakt ist, dass der Einsatz einer Automatisierungslösung immer eine langfristige Investition ist, die über den gesamten Lebenszyklus der Anwendung Entwicklungs- und Wartungsaufwände verursacht. Diese sind aber deutlich geringer als entsprechende manuelle Aufwände. Vor allem ermöglicht Testautomatisierung die Durchführung tausender Regressionstestfälle in kurzer Zeit, was manuell nicht machbar ist, schon gar nicht im engen Zeitfenster agiler Projekte im DevOps-Modus.

Testautomatisierung erfordert einiges Geschick und Know-how

Wer als Testautomatisierer tätig ist, benötigt sehr gute technische Skills, ein positives Verhältnis zum Softwaretest und die Bereitschaft, auch „im Hintergrund“ zu arbeiten. Ein Testautomatisierer muss sich vor allem sehr gut in die agilen Entwicklungsteams integrieren. Er muss in der Lage sein, innerhalb der Sprints bereits erste lauffähige Testfälle zu erstellen, die über den Sprintzyklus hinaus – zum Beispiel in einer späteren Systemintegrations- oder Abnahmephase – lauffähig oder zumindest als Basis für automatisierte End-to-End-Tests einsetzbar sind.

Die organisatorischen Auswirkungen sind umfangreicher als vermutet

Die Einführung von Testautomatisierung umfasst nicht nur den Kauf und die Implementierung eines Werkzeugs, sondern bedeutet eine Veränderung der Test- beziehungsweise Entwicklungs- und in manchen Fällen auch der Betriebsorganisation. Neben der Erweiterung der Teams um Mitarbeiter mit Testautomatisierung-Skills muss auch entschieden werden, wo diese Mitarbeiter in der Organisation, aber auch im Entwicklungsprozess eingesetzt werden. Automatisierung soll innerhalb von Sprintteams angesiedelt sein, darüber hinaus aber auch im Systemintegrationstest, teilweise sogar im Abnahmetest, etwa für die automatisierte Erstellung von Testdaten.

Wichtig ist auch eine effektive Auswahl und Erstellung von automatisierten Regressionstestfällen, die im Sinne von DevOps – vor allem beim schnellen Ausrollen von Changes, Erweiterungen usw. in die Produktion – die „Fehlerfreiheit“ durch kontinuierliche, automatisierte Testdurchläufe sicherstellen soll.

All dies bedeutet Veränderungen in Abläufen, Prozessen und der Organisation.

Testautomatisierung ist nicht gratis

Auch wenn Testautomatisierung mit der Überlegung, Geld und Zeit zu sparen, eingeführt wird, darf man nicht übersehen, dass selbst eine sehr gute, wartungsarme Automatisierungslösung regelmäßige Aufwände verursacht. Aufwände entstehen etwa, wenn Erweiterungen in der Anwendung umgesetzt werden oder bei Änderungen im Betrieb, wie Updates oder Upgrades auf neuere Betriebssystemversionen. Dies bedeutet in den meisten Fällen, dass das Regressionstestportfolio erweitert beziehungsweise adaptiert werden muss.

Im Idealfall rechnen sich diese Aufwände langfristig. Dieser stellt sich aber nicht automatisch ein. Je umfangreicher das Set an automatisierten Testfällen geworden ist, desto größer ist das Risiko überhöhter Wartungsaufwände bei gewissen Ereignissen im Produktlebenszyklus, wie eines Technologiewechsels, eines Werkzeugwechsels oder bestimmten sonstigen technischen und fachlichen Änderungen (siehe Abbildung 1).

Jede gute Automatisierungslösung braucht einen passenden Rahmen. Das heißt, es muss die passende (Test-)Organisation gefunden und gestaltet werden. Testautomatisierung alleine löst nicht alle Probleme. Es muss das gesamte Testvorgehen betrachtet und die Automatisierung in dieses Vorgehen eingebettet sein. [Cri09]

Trotz aller Schwierigkeiten ist Testautomatisierung in allen Branchen und Produktentwicklungen immer mehr im Kommen und in der Zukunft unabdingbar. Neben der eigentlichen Automatisierungsaufgabe – per Knopfdruck lauffähige Testfälle zu erstellen und das Ergebnis der Testdurchläufe automatisiert in lesbaren Report darzustellen – werden künftig auch das automatisierte „Hochziehen“ von unterschiedlichen Entwicklungs- und Test-Stages bis hin zur Produktion, die automatisierte Generierung von Testdaten und auch das automatisierte Erstellen von virtualisierten Schnittstellen mittels Service-Virtualisierung ([Lin13], S. 76-78) immer mehr in das Aufgabengebiet von Testautomatisierungsexperten und -architekten rücken. All diese Tätigkeiten unterstützen „Continuous Testing“ im Zuge von DevOps.

Der Mangel an Testautomatisierern

Um alle oben angeführten Herausforderungen zu meistern, braucht es eine höhere Zahl an hoch qualifizierten Mitarbeitern, die diese Tätigkeiten gerne übernehmen wollen und darin auch eine Karrierechance sehen. Aktuell gibt es das Berufsbild des Automatisierungsexperten [Buc15] mit dem Karriereschritt zum Testautomatisierungsarchitekten, der

• für komplexe Teststellungen maßgeschneiderte, effiziente, gut wartbare Automatisierungslösungen konzeptioniert, entwickelt und implementiert,
• für Testautomatisierungsprojekte sowohl inhaltlich als auch budgetär verantwortlich ist und
• ganze Automatisierungsteams führt, noch so gut wie nicht am Berufsmarkt.

Was ist also zu tun, um junge Informatiker für das Berufsbild „Testautomatisierungsexperte“ zu begeistern, und welche bereits im Beruf aktive Mitarbeiter kann man für die Testautomatisierung sinnvoll ausbilden und einsetzen?

Zuerst müssen ein klares Berufsbild und entsprechende Karrierepfade dargestellt und vermittelt werden. Kaum jemandem ist klar, dass ein Testautomatisierungsexperte im Großen und Ganzen ähnliche Entwicklungsleistungen erbringen muss wie ein Programmierer. Es gilt Frameworks zu entwickeln und zu implementieren, gut wartbare Automatisierungsskripts nach gängigen Coding-Guidelines zu erstellen und eine lauffähige Lösung zu schaffen. Mit dem Unterschied, dass das in der Automatisierung erstellte SW-Produkt der Qualitätssicherung der „eigentlichen“ Applikation dient. Genau genommen sollten jedoch neben der Produktdokumentation sowohl die dokumentierten Testfälle als auch das Set an automatisierten Testfällen als Bestandteil der Software betrachtet und geachtet werden.

Ein Automatisierungsarchitekt ist genauso verantwortlich für die Qualität der Architektur seiner Automatisierungslösung wie jeder andere SW-Architekt auch. Darüber hinaus führt und steuert er ganze Automatisierungsteams, verantwortet – ähnlich wie ein Projektleiter oder Scrum Master – den Fortschritt, das Controlling und Budgets seines Vorhabens – eine tolle Aufgabe; bisher offenbar nur wenig transparent und daher wenig attraktiv.

Hier gilt es, an den Universitäten, technischen Schulen und Fachhochschulen ein Bewusstsein zu schaffen, dass Automatisierung ein hochattraktives und spannendes Feld im SW-Engineering ist. Dieses bietet jedem Absolventen glänzende Berufsaussichten, gute Bezahlung und hohe Chancen am Arbeitsmarkt. Neben diesen „Marketingmaßnahmen“ müssen künftig auch die Lehrpläne mehr Inhalte aus dem Test- und Automatisierungsbereich vermitteln, um die Absolventen rasch im Beruf einsetzen zu können. Bisher gibt es kaum Institute, die diese Inhalte vermitteln. Es wird also noch einige Jahre dauern, bis diese Maßnahmen wirksam werden.

Als sehr begrüßenswert sind in diesem Zusammenhang die Bemühungen des German Testing Boards zu sehen, welches ein Referenzschema zum Berufsbild „Tester“ [GTB17] erarbeitet und veröffentlicht hat. Darin werden unter anderem Entwicklungsdimensionen, allgemeine Kompetenzen, Rollenbilder und Verantwortungsstufen dargestellt – so auch für das Rollenbild „Testautomatisierungs-Spezialist“.

Aus Mangel an verfügbaren Testautomatisierern hat das mittelständische österreichische Unternehmen ANECON (seit 2018 Nagarro) im Jahr 2015 einen dualen Testautomatisierungslehrgang (TA-Curriculum) entwickelt. Seit 2016 werden eigene Mitarbeiter in vier Semestern zu Testautomatisierungs-Spezialisten und weiteren drei Semestern zu Automatisierungsarchitekten berufsbegleitend ausgebildet.

Dabei handelt es sich um einen modular aufgebauten Lehrgang, der den Mitarbeitern mit passenden Skills und Interesse offensteht und innerhalb der Arbeitszeit besucht werden kann. Es werden Lehrinhalte zu den Themen Test, Basiswissen Testautomatisierung, Systemarchitekturen, Programmierung, Frameworks, Automatisierungswerkzeuge, DevOps, Testdatenmanagement usw. vermittelt.

Es gibt drei Ausbildungsniveaus für Testautomatisierer (siehe Abbildung 2). Diese umfassen:

• TA Senior Expert: Dieser setzt eigenständig Kundenprojekte der Testautomatisierung, Service-Virtualisierung und Performanztest in unterschiedlichen Technologien um (vgl. GTB TA-Spezialist Junior/Advanced).
• TA Architect: Der Testautomatisierungs-Architekt konzipiert Automatisierungslösungen für Kunden und führt und steuert Automatisierungs- und Service-Virtualisierungs-Teams in Projekten (vgl. GTB TA-Spezialist Senior/Expert).
• TA Consultant: Er berät Kunden auf Managementebene in allen Automatisierungs-, Service-Virtualisierungs- und Performanzfragen (vgl. GTB TA-Spezialist Senior/Expert als Berater).

Die Einführung einer solchen Ausbildungsvariante kann ein geeigneter Weg für viele Unternehmen sein, den Mangel an verfügbaren Testautomatisierungs-Spezialisten in den eigenen IT-Abteilungen auszugleichen. Dies bedeutet natürlich auch eine Investition, da es sich um keinen kurzfristigen Ansatz handelt und dieser das Risiko birgt, dass gut ausgebildete Mitarbeiter möglicherweise das Unternehmen verlassen. Aber das ist das kleinere Übel gegenüber schlecht ausgebildeten Mitarbeitern, die bleiben und Automatisierungslösungen erarbeiten, die wirklich teuer zu stehen kommen.

Fazit

Testautomatisierung ist im Vormarsch und wird auch in den nächsten Jahren nicht aufzuhalten sein. Im Gegenteil: DevOps, agiles Vorgehen und enorm kurze Time-to-Market bei gleichzeitig hoher Qualitätserwartung sowie komplexen Anwendungen und Systemlandschaften erfordern einen immer höheren Automatisierungsgrad. Dafür braucht es Spezialisten, die effiziente, wartungsarme Lösungen schaffen, die über den gesamten Lebenszyklus der Anwendung wirksam sind.

Diese Spezialisten sind rar und am freien Arbeitsmarkt kaum zu finden. Auch IT-Dienstleister können derzeit den Bedarf nicht vollständig bedienen. Um die steigende Nachfrage nach Automatisierungsexperten decken zu können, sind neben den Universitäten und Fachhochschulen auch die Unternehmen selbst gefordert. [Vos16]

Es müssen attraktive Karrieremodelle für Testautomatisierer geschaffen werden und Unternehmen müssen selbst in die Ausbildung ihrer Mitarbeiter investieren. Mittelfristig werden idealerweise Absolventen von Universitäten und Fachhochschulen das nötige Rüstzeug und die Motivation, als Testautomatisierer tätig zu sein, vermittelt bekommen. Eine Anleitung dazu könnte das in diesem Artikel dargestellte Modell und das Referenzschema „Berufsbild Tester“ des German Testing Boards geben.

Referenzen

[Bau17]
M. Baumgartner, M. Klonk, H. Pichler, R. Seidl, S. Tanczos, Agile Testing – Der agile Weg zur Qualität, Carl Hanser Verlag, 2. Auflage, 2017

[Buc15]
T. Bucsics, M. Baumgartner, R. Seidl, S. Gwihs, Basiswissen Testautomatisierung, dpunkt.verlag, 2. Auflage, 2015

[Cri09]
L. Crispin, J. Gregory, Agile Testing – A practical Guide for Testers and agile Teams, Addison-Wesley-Longman, 2009

[GTB17]
Berufsbild Tester, German Testing Board e. V., Erlangen, 2017

[Lin13]
T. Linz, Stubs, Mocks und Dummies, Testen in Scrum-Projekten, dpunkt.verlag, 2013

[Sne12]
H. Sneed, M. Baumgartner, R. Seidl, Der Systemtest, Hanser, 3. Auflage, 2012

[Swi18]
SwissQ Consulting AG, Software Product Development 2018 – Trends & Benchmarks Studie Schweiz, Zürich, 2018

[Vos16]
K. Vosseberg, A. Spillner, M. Winter, Softwaretest in der Praxis – Umfrage 2016, dpunkt.verlag, 2017