Vorteile und Limits der Automatisierung

DevOps: Vollständige Automatisierung ist nicht zwingend die Lösung

Jan Wolter

© Shutterstock / Viktoria Kurpas

Mit dem Siegeszug von DevOps in der Softwareentwicklung gehen einige grundlegende Veränderungen einher. IT und Development rücken näher zusammen, um schneller hochwertige Software liefern zu können. Viele Prozesse – auch im Testing – sollten dafür automatisiert werden. Warum das jedoch nur bedingt machbar beziehungsweise sinnvoll ist, erklärt Jan Wolter, General Manager EU bei Applause.

Agilität ist das Buzzword schlechthin in Entwicklungsabteilungen. Und das nicht ganz zu unrecht. In einer Welt, in der Kunden ihre Ansprüche an Produkte stets nach oben schrauben und kaum mehr etwas auf Dauer besteht, müssen Unternehmen ihren Entwicklerteams ein schnelles, autonomes und flexibles Arbeiten ermöglichen. Vorbei ist die Zeit, in der das Wasserfallmodell dominierte. Heute zählen agile Frameworks und Methoden, um in unserem modernen VUCA-Zeitalter (das Akronym steht für “volatile, uncertain, complex, and ambiguous“, also volatil, unsicher, komplex und mehrdeutig) zu bestehen.

Ein kurzer Exkurs: Was ist so toll an DevOps?

Doch reine Geschwindigkeit in der Softwareentwicklung ist längst nicht mehr alles. Es geht vielmehr um Ressourceneffizienz, sprich die optimale Nutzung von Kapazitäten für Development und IT. Gerade in Krisenzeiten kommt hinzu, dass Unternehmen stets geschäftsfähig sein müssen und der Betrieb unterbrechungsfrei funktioniert. Um beides unter einen Hut zu bekommen, setzen Firmen zunehmend auf DevOps. Dabei geht es darum, die IT (sprich “Operations”) und die Entwicklungsabteilung (“Development”) enger zusammen zu bringen und Zielkonflikte aufzulösen. Letzterer besteht oft darin, dass das Development möglichst schnell neue Features und Softwareupdates veröffentlichen und in den laufenden Betrieb integrieren will, wohingegen solche aus Sicht der IT die operative Infrastruktur gefährdet und man eher für wohlüberlegte, längerfristige und damit langsamere Update-Zyklen plädiert. Um diese Problematik besser in den Griff zu bekommen, setzen Unternehmen auf Build- und Deployment-Tools wie zum Beispiel Docker, um schnell passende Umgebungen aufzusetzen, in denen isolierte Teile der Anwendung oder Software entwickelt und getestet werden können, ohne die operative Infrastruktur zu belasten.

“Automatisiere alles, was du kannst”

Des Weiteren stößt man im Zuge der Debatte um das DevOps-Prinzip, welches an sich keine feste Definition oder Vorgaben zur Umsetzung bietet, unweigerlich auf die “DevOps Agile Skills Association” (DASA). Dabei handelt es sich um eine Organisation, die sich dem DevOps-Prinzip verschrieben hat und deren Verbreitung fördert. Sie bietet ein Kompetenz- und Skillframework für IT-Mitarbeiter und hat entsprechende DevOps-Prinzipien entwickelt, die beschreiben sollen, wie eine IT-Organisation sich und vor allem seine Mitarbeiter in Richtung DevOps entwickeln kann. Die sechs Kernprinzipien lauten:

  1. Customer-Centric Action
  2. Create with the End in Mind
  3. End-To-End Responsibility
  4. Cross-Functional Autonomous Teams
  5. Continuous Improvement
  6. Automate Everything You Can

Hier ist vor allem das letzte Prinzip interessant, denn es bedingt nicht nur neue Anforderungen an Entwickler und IT, sondern auch an die QA-Teams. Im originalen Wortlaut heißt es dort:

To adopt a continuous improvement culture with high cycle rates and to create an IT organization that receives instant feedback from end users or customers, many organizations have quite some waste to eliminate. Fortunately, in the past years, enormous gains in IT development and operations can be made in that respect. Think of automation of not only the software development process (continuous delivery, including continuous integration and continuous deployment) but also of the whole infrastructure landscape by building next-gen container-based cloud platforms that allow infrastructure to be versioned and treated as code as well. Automation is synonymous with the drive to renew the way in which the team delivers its services.

Im Endeffekt geht es also darum, eine automatisierte Prozesskette zu schaffen, die “Continuous Delivery”, also die fortlaufende Auslieferung von Releases, ermöglicht. Agile Teams liefern hierbei Input, der zu automatisierten Softwarepaketen zusammengesetzt und in die Bibliothek aufgenommen wird (“Continuous Integration”), wobei eine Programmroutine die sich wiederholenden Aufgaben übernimmt. Diesem Prozess anschließend erfolgen automatisierte Test auf verschiedenen Ebenen: Statische Tests für die Validierung des Quellcodes, Unit-Tests für alle Komponenten, Smoke-Tests für grundlegende Funktionen und Tests auf Systemebene, um Überlauffehler und andere Probleme aufzudecken. All diese Tests lassen sich – solange sie mit entsprechender Weitsicht geplant und definiert sind – innerhalb kürzester Zeit massenhaft wiederholen und sind entsprechend skalierbar. Und darum geht es vielen Unternehmen am Ende.

Neue Anforderungen an QA-Teams

Die eben genannte Weitsicht im Umgang mit Tests zeigt sich vor allem in der Testausführung. Denn DevOps impliziert auch, dass der Druck auf QA-Teams steigt. Es geht darum, Test-Umgebungen zu standardisieren, Automatisierungen für Deployments und Testing-Abläufe zu schreiben, Testszenarien zu gruppieren und im besten Fall die Dauer der Tests durch ein verlässliches Time-Boxing in den Griff zu bekommen. Die Prüfung von Software wird damit sowohl intensiver als auch kontinuierlich, was wiederum ein penibles Vorgehen bei der Planung von Automatisierungsprozessen erfordert. Im Endeffekt bedingt DevOps, dass QA-Teams mehr und mehr Zeit auf die Erstellung von Test-Skripten oder Programmroutinen sowie das Monitoring verwenden müssen. Und das ist auch wichtig, schließlich ist ein ausgereiftes Automatisierungsframework entscheidend, um neue Testfälle schnell skripten und implementieren zu können.

Limits der Automatisierung

Gleichzeitig sollten sich Unternehmen klar machen, dass sich selbst mit einer hundertprozentigen Testabdeckung durch automatisiertes Testing nicht alle Fehler verhindern lassen können. Das hat mehrere Gründe: 

Die menschliche Komponente bleibt: Bei aller Automatisierung, die wir uns wünschen, steht zu Beginn stets ein Mitarbeiter, der sie manuell codiert. Das gilt auch für Testszenarien. Hier kann es gleich zu mehrfachen Herausforderungen kommen. Nicht nur denken einzelne Menschen an eine begrenzte Anzahl von möglichen Testszenarien, sie unterliegen dabei auch oft einem gewissen Bias. So haben Mitarbeiter unter Umständen andere Einsatzzwecke im Sinn als der Endnutzer. Hinzu kommt, dass Mitarbeiter, die sich stets mit dem gleichen Produkt oder Prozess beschäftigen, irgendwann betriebsblind werden und Szenarien vernachlässigen, bei denen bisher nie Probleme aufgetreten sind. Und selbst wenn der vollständige Code abgedeckt wird, so kann es immer noch sein, dass Seiteneffekte auftreten, beispielsweise wenn unterschiedliche Bearbeitungsmethoden und veränderte Variablen zum Einsatz kommen.

Technische Limitierungen: Rein aus technischer Sicht gibt es ebenfalls Beschränkungen: Es gibt Prozesse im Testbetrieb, die sich nicht – oder nur unter erheblichem Aufwand – automatisieren lassen. Exemplarisch dafür steht ein Test, der es erfordert, ein Smartphone aus- und wieder einzuschalten. Aber auch Tests für Software, die auf Bewegung reagieren soll oder das Verbinden eines Geräts über Bluetooth mit anderen Geräten ist schwer zu automatisieren. Natürlich wäre das mit entsprechenden robotergestützten Tests denkbar, doch stellt sich hier schnell die Frage nach der Wirtschaftlichkeit. 

Begrenzte Ressourcen: Mit Blick auf die Wirtschaftlichkeit ist auch der zu Beginn genannte Ressourceneinsatz ein limitierender Faktor. Es steht schlichtweg weder unbegrenzt Zeit noch Budget zur Verfügung, um alle erdenkbaren Szenarien für Tests zu automatisieren. Zudem mag es zwar für Unternehmen möglich sein, eine große Anzahl an virtuellen Testumgebungen effizient zu betreiben. Der Betrieb eines ständig aktuellen Pools von Testgeräten ist dagegen kaum wirtschaftlich zu realisieren.

Unter Berücksichtigung dieser Restriktionen sollten sich Unternehmen gut überlegen, wann und wo es Sinn ergibt, Prozesse weiter zu automatisieren. Denn auch DevOps stößt an einem gewissen Punkt an seine Grenzen, nämlich dann, wenn es um Tests in der realen Welt geht. Hier müssen die Usability, geographische und kulturelle Lokalisierungen sowie Integrationen mit anderen Services bedacht werden. Die dafür notwendigen explorativen Post-Production-Tests stehen aber außerhalb des DevOps-Scope.

Das Zusammenspiel von manuellen Tests und Automatisierung

Um die Entscheidung für den Bereich des Testings fundiert treffen zu können, gilt es zwei zentrale Evaluierungen vorzunehmen. Zum einen müssen sich Unternehmen darüber klar werden, wie fortgeschritten ihr derzeitiges funktionales Testing ist. Hält das Testing mit der Release-Geschwindigkeit mit? Wie umfangreich ist die zu testende Software? Gerade Unternehmen, die tendenziell noch wenig Erfahrung mit Automatisierung gemacht haben, sollten hier behutsam vorgehen und nur Szenarien automatisieren, die zuvor bereits verlässlich durch manuelle Tests validiert wurden. Die übrigen Tests bleiben vorerst manuell und auch der explorative Teil, der sich ohnehin kaum automatisieren lässt, spielt eine größere Rolle. Zudem ist gerade am Anfang ein manuell dokumentierter Prozess entscheidend, um verlässlich wiederholbare Tests zu automatisieren. Je erfahrener Unternehmen werden, desto größer wird dann der Anteil an automatisierten Test.

Zum anderen lohnt es sich herauszufinden, wo im Software Development Life Cycle (SDLC) sich das Automatisieren am meisten lohnt. Gerade zu Beginn des Zyklus, in dem einzelne Funktionen in isolierten Umgebungen entwickelt und getestet werden, machen hochfrequentierte und automatisierte Unit Tests durchaus Sinn. Je weiter hinten im Entwicklungszyklus man sich befindet, desto eher verringern komplexe manuelle Tests in geringer Frequenz die Fehleranfälligkeit der Anwendung. Dabei spielt natürlich auch die zuvor beschriebene Reife des funktionalen Testings sowie die Release-Frequenz eine Rolle.

Um manuelle Tests sicher in den Automatisierungsprozess zu integrieren, gibt es außerdem einige Techniken, die das Risiko für den laufenden Betrieb reduzieren. So können beispielsweise “Canary Releases” verwendet werden, bei denen Features nur einer Gruppe von Nutzern zugänglich gemacht wird, die dann testet und Feedback gibt, bevor alle Nutzer Zugriff erhalten. Gleiches gilt für “Blue-Green Deployments”, bei denen Änderungen in zwei verschiedenen Versionen veröffentlicht werden. Hierbei bekommt eine Gruppe die komplett neue Softwareversion, während der Rest die bisherige – und nur inkrementell adaptierte – Version nutzt. Treten bei der Testgruppe ernsthafte Probleme auf, kann hier schnell das Zurücksetzen auf die bisherige Version erfolgen. Außerdem gibt es die Möglichkeit, mit Funktionsflaggen oder sogenannten “Feature Switches” zu arbeiten. In der Live-Umgebung können so bestimmte Funktionen ein- oder ausgeschalten werden, um von einem bestimmten Anteil der Nutzer oder des QA-Teams Feedback aus manuellen Tests zu bekommen. In all diesen Techniken greifen manuelle Tests und die Automatisierung im Sinne des Continuous Delivery ineinander.

Automatisierung lohnt sich an den richtigen Stellen

DevOps und die damit verbundene Automatisierung stellen für Unternehmen sowohl Herausforderung als auch Chance da. Am Ende muss klar sein, dass nicht alles automatisiert werden kann und vor allem muss. Gerade bei repetitiven Prozessen, die vielfach einstudiert wurden und viel Zeit in Anspruch nehmen, lohnt es sich, Automatisierungen zu implementieren. Bereiche, in denen Unternehmen noch nicht genug Erfahrung im Testingprozess gesammelt haben sowie Szenarien und Features, die eine breiter Nutzerbasis und deren Gerätespektrum betreffen, sollten dagegen durch erfahrene Tester manuell überprüft werden. Gleiches gilt aus Effizienzgründen auch für Szenarien, die sich technisch nur schwer abbilden lassen. Sind interne Ressourcen knapp, empfiehlt sich der Rückgriff auf erfahrene Dienstleister. Dabei muss jedoch darauf geachtet werden, dass manuelle Tests reibungslos in die Automatisierungsstrategie integriert werden.

Geschrieben von
Jan Wolter
Jan Wolter
Als VP und Geschäftsführer EU leitet Jan Wolter das Europageschäft für Applause und ist verantwortlich für den Ausbau des Unternehmens im europäischen Markt. Zuvor war er CEO und Mitgründer von testhub, dem deutschen Softwaretesting-Anbieter, der sich im Mai 2014 mit Applause zusammenschloss. Durch beide Aufgaben verfügt er über jahrelange Erfahrung in der Umsetzung und Skalierung innovativer Testing-Lösungen und über tiefe Einblicke in die rasanten Entwicklungen der App Economy.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: