Softwareentwickler Benjamin Willenbring war begeistert, als sein Arbeitgeber Autodesk im Jahr 2015 automatisiertes Software Testing einführte. Diese Begeisterung legte sich allerdings relativ schnell wieder, denn die Kommunikation mit dem kleinen Automation Team gestaltete sich schwierig und die Ergebnisse der Bemühungen entsprachen nicht den Erwartungen.

"Meine Kollegen sprachen darüber, dass Testläufe aus unvorhersehbaren Gründen scheiterten und ließen keinen Zweifel daran, dass sie nicht besonders überzeugt von der ganzen Sache waren", plaudert Willenbring aus dem Nähkästchen. Die Testphase zum Laufen zu bringen, gestaltete sich schwierig: Es gab keine Dokumentation und Files in Hülle und Fülle. Das automatisierte Testing sollte Willenbrings Arbeit eigentlich vereinfachen - stattdessen warf das Automation-Projekt so viele neue Probleme auf, dass der Entwickler den Großteil seiner Energie in den Folgejahren dafür investieren musste, diese zu lösen.

Die Erfahrungen, die Willenbring in Sachen Automatisierung gemacht haben, sind allerdings nicht ungewöhnlich. Je höher der Automatisierungsgrad in den IT-Abteilungen, desto mehr lehrreiche Beispiele gibt es, die zeigen, wie man Automation nicht angehen sollte. Egal, ob automatisierte DevOps Workflows, Robotic Process Automation oder Prozessautomatisierung - eigentlich soll die Technologie dafür sorgen, Fachkräfte von repetitiven Aufgaben zu befreien. Aber unzureichende Rahmenbedingungen und Fail-behaftete Rollouts können aus dem Automation-Traum schnell einen Albtraum machen. Wir zeigen Ihnen sechs Wege, um es gar nicht erst zum Automatisierungs-Desaster kommen zu lassen.

Automatisierung geht alle an

Willenbrings Testing-Automation-Albtraum wurde insbesondere durch einen Umstand ausgelöst: Die einzigen, die in der Lage waren, die automatisierten Tests zu verstehen, waren die, die sie aufgesetzt haben. Leider war das entsprechende Team in einer anderen Stadt angesiedelt.

"Ein Problem am Test-Framework war, dass es bei Fehlern kein wirklich gutes Feedback zur Verfügung gestellt hat", erzählt Willenbring. "Wenn ein Fehler auftrat, war die erste Maßnahme Slack anzuwerfen, um den Test-Lead nach der Ursache zu fragen. Der wiederholte den Test dann manuell und kommunizierte die Ursache für den Fehler."

Das Testing Framework verletzte somit wesentliche Regeln, an denen jede Automatisierungs-Initiative ausgerichtet werden sollte, so Robert Haas, DevOps Product Manager bei DXC: "Automation Code muss dokumentiert sein, egal ob Sie auf moderne Methoden wie Documentation-as-a-Code setzen oder Visio-Diagramme verknüpfen. Probleme zu lösen ist deutlich einfacher, wenn sich nachvollziehen lässt, wie der Ursprungszustand ausgesehen hat."

Weil das in Willenbrings Fall nicht passierte, waren die Testergebnisse für sein Team unbrauchbar. Das führte wiederum zu sinkendem Vertrauen in die Tests und das Team, das diese aufgesetzt hatte. "Manchmal blockierten die Entwickler einfach und ignorierten offensichtliche Fehler", erzählt der Softwareentwickler.

Aufgrund der räumlichen Distanz zwischen Entwickler- und Testing Team entstanden zusätzliche Probleme: "Man braucht Experten, die wissen was sie tun und gezielt auswählen, was getestet wird. Unmengen an Tests ohne echten Plan führen in der Regel nicht zu verwertbaren und sinnvollen Ergebnissen", so Willenbring.

Erst ein neuer Leiter der Entwicklungsabteilung war in der Lage, Willenbring und sein Team aus diesem Teufelskreislauf zu befreien - er stellte klar, dass Qualität oberste Priorität hat, auch wenn es um Testing Automation geht. Zentralisiertes Testing ist seitdem passé - inzwischen setzen individuelle Abteilungen die Tests für "ihren" Code auf. So konnten auch Willenbring und sein Team Tests an den Start bringen, die auf ihre Bedürfnisse angepasst waren und diesen Prozess letztlich in den Arbeitsalltag integrieren. Willenbrings Fazit zu dieser Erfahrung: "Eine Einstellung im Sinne von 'das gehört nicht zu meinem Job' sollten Sie gar nicht erst zulassen."

Automation bringt Komplexität

Bei Tripwire, Anbieter für Automatisierungslösungen im Bereich IT Security und Compliance, wunderte man sich über die Vorgänge bei einem Großkunden aus dem Finanzbereich. "Unsere Lösungen werden automatisiert ausgerollt", erzählt Irfahn Khimji, Country Manager für Kanada bei Tripwire. "Deswegen haben wir uns irgendwann gefragt, warum das bei diesem Kunden so lange dauert. Wir konnten keinen Anstieg bei der Nutzung der Lizenzen feststellen, was nicht dem normalen Muster entsprach."

Wie sich herausstellte, wurde das Ideal einer nahezu vollständig automatisierten CI/CD Pipeline von der Realität eingeholt: Jede der vielen unterschiedlichen Abteilungen beim Kunden nutzte ein eigenes, individuell ausgestaltetes Set von Softwarekomponenten.

"Der Kunde wollte mehr als 30 Applikationen einbinden - was zu zahlreichen Problemen führte, etwa, wenn es um die diversen Bibliotheken ging", erzählt Khimi. "Die Pipeline so anzupassen, dass sie alle Anforderungen zuverlässig abdeckt, verlangsamte den Automatisierungsprozess deutlich."

Um ein solches Problem zu lösen, gibt es kein Wundermittel. Sie sollten sich aber darüber im Klaren sein, dass mit einer steigenden Zahl von Komponenten, die in den Automation-Prozess eingebunden werden sollen, auch die Komplexität steigt - schließlich müssen diese Komponenten miteinander verknüpft und entsprechende Anpassungen vorgenommen werden. Das wird wiederum dazu führen, dass die Automatisierungs-Initiative mehr Zeit und Ressourcen benötigt. Dabei spielt es auch eine Rolle, woher diese Komponenten kommen: Das Gros der Pipelines und RPA-Umgebungen beinhaltet einen heterogenen Mix aus Inhouse- und Third-Party-Komponenten. Gerade letztere können beim Auftreten von Fehlern zu echten Problemen führen.

Automation-Prozesse als Black Box

Insbesondere in der Finanzbranche stehen Robotic Process Automation und Chatbots hoch im Kurs. In diesem Zusammenhang warnt Muddu Sudhakar, CEO und Mitbegründer der Softwarefirma Aisera vor einem gängigen Szenario: Prozesse werden als monolithische Funktionseinheit gesehen, deren interne Abläufe nur noch schwer voneinander zu trennen sind und so zur Black Box werden: "In einer monolithischen Struktur will der Kunde seinen Kontostand checken, Geld abheben oder überweisen - das alles passiert in einem Schritt", erklärt Sudhakar. "Wenn dabei etwas schiefgeht und keine Monitoring-Maßnahmen bestehen, bleibt nur noch ein Anruf beim Kundenservice oder der physische Besuch der Filiale."

Dem Experten zufolge ist diese Art der Architektur typisch für die Anfangsbemühungen von Unternehmen mit Automatisierungstechnik. Zwar könnten solche Projekte gute Ergebnisse hervorbringen, so Sudhakar, aber nur solange alles nach Plan läuft. Wenn nicht, bleibe nur, die einzelnen Funktionen aus der Black Box herauszulösen - weswegen man eine solche von vornherein vermeiden sollte.

"Unterteilen Sie jeden Prozess in Bausteine, die auditier- und überprüfbar sind", empfiehlt der Automation-Spezialist von Aisera.

Automatisierungs-Gewaltenteilung

So manch automatisierter Prozess kann vom Poka-Yoke-Prinzip profitieren. Die in Japan erfundene Fehlervermeidungsstrategie kommt beispielsweise im Produktionssystem von Toyota zum Einsatz. Hierbei wird ein einzelner Prozessschritt in zwei verschiedene aufgeteilt - wobei der zweite Schritt vom ersten abhängt. Paradoxerweise führt die Vermehrung der einzelnen Schritte zu Effizienzgewinnen, weil Fehler nicht in die Produktionskette einfließen - wo sich ihre Effekte vervielfachen können.

Einzelne Automatisierungsschritte sollten nicht nur auditierbar sein, sondern konstant von anderen automatisierten Prozessen überprüft werden. Damit nähern Sie sich dem Bereich AIOps: Hierbei entlasten automatisierte Plattformen menschliche Fachkräfte von der Bürde des IT Managements.

Automation braucht Security

Automatisierte CI/CD Pipelines haben oft ein schmutziges Geheimnis: Viele wurden initial von der Schatten-IT ausgerollt, um Security-Richtlinien zu umgehen. "Entwickler wollen eben entwickeln und zügig mit ihrem Code vorankommen", erklärt Irfahn Khimji von Tripwire. "Wenn rigorose IT- und Security-Prozesse dabei im Weg stehen, haben sie sofort Ideen im Kopf, um diese zu umgehen."

Das soll nicht heißen, dass solche CI/CD Pipelines per se unsicher wären - aber Sie sollten unbedingt im Blick haben, welche Sicherheits-Praktiken dem Automatisierungs-Effizienzgewinn geopfert wurden. Darüber hinaus sollten Sie nicht vergessen, dass jeder automatisierte Prozess immer auch einen weiteren Angriffsvektor darstellt. Autonome Prozesse, die mit erweiterten Berechtigungen ausgestattet sind, stellen unter Umständen besonders attraktive Angriffsziele dar. Muddu Sudhakar kann sich nicht nur an einen Fall erinnern, bei dem Innentäter die DevOps Pipeline dazu missbraucht haben, Malware einzuschleusen. Diese konnte sich ihren Weg bis in die Produktionsumgebung bahnen und legte das komplette System lahm.

Billig-Automatisierung lohnt sich nicht

Jeder Hype kommt mit Missverständnissen im Schlepptau. Ajeet Dhaliwal, Lead-Entwickler und Gründer von Tesults, hat schon viele Unternehmen gesehen, deren Vision von automatisiertem Testing in recht deutlichem Kontrast zu den Best Practices steht. Insbesondere kleinere Unternehmen, deren Führungsebene keinen technischen Hintergrund mitbringt, scheinen von diesem Phänomen betroffen zu sein. In der Logik dieser Menschen stellen automatisierte Tests schlicht manuelle Tests ohne menschliche Beteiligung dar.

"Also ermutigen sie traditionelle QA-Tester ohne Kenntnisse in der Softwareentwicklung dazu, das Testing zu automatisieren", fasst Dhaliwal die Folgen zusammen. "Die Robustheit und Flexibilität solcher Ansätze liegt deutlich hinter dem, was ein Softwareentwickler mit Automatisierungs-Knowhow leisten kann." Natürlich sei es kein Problem, auch junge Entwickler mit einzubinden, so der Testing-Experte. Aber diese sollten von erfahrenen Developern angeleitet werden, um gute Ergebnisse sicherzustellen. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CIO.com.