Christoph Witte: Quality Engineering, von Profis kurz QE genannt, in der Cloud – worauf müssen Anwender dabei achten?
Pankaj Rai Jain: Bei On-Premises konzentriert sich QE auf funktionale und nicht funktionale Anforderungen. In der Cloud, die inzwischen von sehr vielen Unternehmen genutzt wird, kommen weitere Herausforderungen rund um eine adäquate Cloud-Nutzung hinzu. Da geht es zum Beispiel darum, dass Anwender die Cloud richtig konfgurieren und passende Features korrekt nutzen, und das alles, ohne dass ihnen die Kosten davonlaufen. Darüber hinaus müssen Software- und Cloud-Architektur aufeinander abgestimmt werden, sodass die passende Skalierbarkeit und Flexibilität erreicht werden kann. All dies sollte in eine ganzheitliche QE einbezogen werden. Hierbei geht es über Software und Funktionalitäten hinaus und die Frage sollte beantwortet werden, ob auch der erwartete Business-Nutzen erzielt werden kann.
"Wir können in dieser komplexen, eng verzahnten Cloud-Welt allerdings unmöglich jedes Ereignis voraussagen."
Die meisten der genannten Anforderungen treffen auch auf On-Premises-Installationen zu. Aber macht die Cloud das Quality Engineering nicht deutlich komplexer?
Ja, zum Beispiel ist der Softwareentwicklungs-Lebenszyklus in der Cloud anders. Anwender orchestrieren die Produkte Dutzender verschiedener Hersteller. Aber auch hier gilt die Aussage: Eine Kette ist immer nur so stark wie ihr schwächstes Glied. Deshalb müssen Nutzer sicherstellen, dass sie die Produkte robust orchestrieren und Fehler in Komponenten im Zuge eines Frühwarnsystems frühzeitig über Shift Left identifzieren, um unerwartete Fehler in der Produktion abzufangen, und dies, ohne dass die Leistung eingeschränkt wird oder gar nicht mehr erbracht werden kann.
Aber Cloud-Komponenten stehen nicht hundertprozentig unter der Kontrolle der Nutzer. Die Provider gestalten sie um, spielen Updates ein, stellen neue Funktionalität bereit und verändern andere Bedingungen kontinuierlich, nicht mehr nur in zwei oder drei geplanten Releases pro Jahr. Schauen Sie beispielsweise auf Microsoft 365.
Korrekt. Fast immer gibt es eine Mischung aus sehr robusten Anbietern sowohl für die Infrastruktur als auch für industrielle Plattformen. Die Stärke liegt jedoch in der Fähigkeit, auch Einzellösungen, Spezialkomponenten und aufkommende Ideen zu nutzen, um überall ein ähnliches Qualitätsniveau zu erreichen. Viele andere Hersteller entwickeln deutlich weniger stabile Produkte. Das müssen Sie als Nutzer in ihrem QE-Ansatz berücksichtigen. Dies gilt auch, wenn Sie die Cloud „nur“ als Infrastruktur nutzen. Sie müssen diese Cloud-Infrastruktur richtig konfgurieren, um sie effektiv zu nutzen. Wenn das nicht der Fall ist, leidet Ihr Business.
Wenn ein Nutzer feststellt, dass er an einer bestimmten Stelle ein Qualitätsproblem hat, dann ist der Fehler ja noch nicht behoben. Deshalb die Frage: Wie viel QE fällt vor dem Deployment eines Service an und wie viel während der Nutzung?
Es gibt einen präventiven und einen reaktiven Teil im QE. Beim präventiven Teil geht es um die Vermeidung von Fehlern.
Wie viele Fehler im Vorfeld erkannt und behoben werden können, hängt sehr stark von der Erfahrung der Beteiligten, den Testmethoden und den durchgeführten Tests ab. Bei Letzteren geht es darum, möglichst schnell auf Incidents zu reagieren und Fehler zu beseitigen. Inzwischen gibt es auch neue Methoden wie Chaos Engineering und Chaos Testing, um die wirklich anspruchsvolle Arbeit von Cloud-Infrastruktur-Testing besser zu bewältigen. Beim Chaostest wird die Fehlerinjektion in einer kontrollierten Umgebung eingesetzt, um künstliche Fehler während des Betriebs zu erzeugen und zu testen, wie ein System reagiert und wie die Fehler eingedämmt werden. Aus diesen Incidents wiederum lernt man kontinuierlich und stärkt so die Prävention. Wir können in dieser komplexen, eng verzahnten Cloud-Welt allerdings unmöglich jedes Ereignis voraussagen. Es ist daher äußerst wichtig, den "reaktiven" Teil der ganzheitlichen Qualitätssicherung auch zu berücksichtigen und die Angemessenheit der Wiederherstellungsprozesse zu testen.
Wie geht man QE in einem Multi-Cloud-Set-up an? Gibt es da ein übergeordnetes Vorgehen oder wird die Qualität der Produkte und Services einzeln überprüft?
Ich kenne keine Methode, die sich für alle eingesetzten Services und Provider gleichermaßen eignet. Schließlich werden nicht nur verschiedene Cloud-Delivery-Methoden wie Infrastructure as a Service, Platform as a Service oder Software as a Service eingesetzt, sondern die meisten Unternehmen nutzen auch noch On-Premises-Bausteine. Dafür gibt es meines Wissens kein einzelnes Werkzeug oder eine einzelne Methode, die alles ausreichend abdeckt. Deshalb ist eine QE-Strategie so wichtig. Dabei geht es um die Frage, wie sie die Qualitätsrisiken und damit ihre Business-Risiken über verschiedene Infrastrukturen und Applikationen hinweg eindämmen und durch ein Frühwarnsystem oder auch intelligente Mechanismen wie Predictive Analysis managen können. Die QE-Strategie sollte auf diese unvorhersehbaren Fehlerbedingungen in der Produktion eingehen und das Unternehmen in die Lage versetzen, schnell zu reagieren, den Schaden einzudämmen und sich in kürzester Zeit vollständig zu erholen.
Sie haben gerade eben von Predictive Analysis gesprochen. Ist damit das Gleiche gemeint wie mit Predictive Maintenance?
Im Gegensatz zu Predictive Analysis im QE geht es bei Predictive Maintenance vor allem um Warnungen und Maßnahmen, die bei drohenden Engpässen im Betrieb eingeleitet werden, um Fehlfunktionen oder Staus zu vermeiden, in der Regel auf der Grundlage historischer Leistungsdatenmodelle. Beispielsweise wird bei einer Warnung, dass die Festplatte zu 90 Prozent gefüllt ist, mehr Kapazität zur Verfügung gestellt. Das Gleiche gilt, wenn die Auslastung der CPU auf einen bestimmten Schwellenwert zusteuert. Es geht also darum, bekannte kritische Zustände zu vermeiden. Wenn wir über Predictive Analysis sprechen, geht es hingegen darum, unvorhergesehene Bedingungen zu erkennen.
Beispielsweise gibt es das Thema Defect Analysis. Diese gibt Auskunft darüber, welche Art von Applikation am ehesten welche Fehler produziert. Diese Vorausschau basiert zum Teil auf historischen Daten, auf Daten über vorgenommene Veränderungen an Infrastruktur und Komponenten und vielen anderen Indikatoren. Dabei geht es darum, das Risiko von Fehlverhalten vorherzusagen. Komponenten mit hohem Fehlerrisiko müssen dann im Zuge eines risikobasierten Ansatzes intensiver getestet werden als solche mit niedrigerem Risiko.
Warum ist diese Fehlervorausschau wichtig?
Zeit ist Geld. Je kürzer der Zeitraum, in dem ein Unternehmen einen Service oder ein Produkt auf den Markt bringen kann, desto profitabler kann sie ihn verkaufen. Wenn man deshalb an bestimmten Stellen im Entwicklungsprozess Zeit sparen kann, sei es durch Automatisierung, durch Stichprobentests statt flächendeckendem Testen bei risikoarmen Applikationen oder durch eine effizientere Testabfolge, bringt dies den Unternehmen Zeit und damit fnanzielle Vorteile.
Arbeiten diese vorausschauenden Systeme mit Machine Learning oder anderen KI-Komponenten?
Ja, es ist menschlich unmöglich, die Komplexität des Testens moderner Softwaresysteme zu bewältigen, wenn man die Anforderungen an Komplexität und Agilität bedenkt. Daher setzen wir ML-/KI-Techniken in der QE ein, um die Effizienz und Geschwindigkeit der Testaktivitäten zu erhöhen. Auch die jüngsten Fortschritte in der GenAI sind sehr vielversprechend, um weitere erhebliche Kosten-, Arbeits- und Geschwindigkeitsvorteile zu erzielen.
"Inzwischen denken wir aber bereits darüber nach, die Generierung von Testskripts weitgehend zu automatisieren."
Automatisierung und Priorisierung sind wichtige Elemente, um QE besonders in großen IT-Landschaften zu realisieren. In Bezug auf Automatisierung: Was ist heute automatisierbar und wie entwickelt sich das Thema weiter?
Heute findet Automatisierung vor allem bei der Ausführung von Tests statt. Testautomatisierung wird von vielen Unternehmen auf breiter Front eingesetzt. Inzwischen denken wir aber bereits darüber nach, die Generierung von Testskripts weitgehend zu automatisieren (Weiterentwicklung des modellbasierten Testens, Verwendung von NLP), die Wartung automatisierter Testsuiten mit Konzepten wie Self-Healing-Testautomatisierung und die autonome Ausführung von Tests. Die jüngsten Fortschritte im Bereich GenAI eröffnen uns spannende Möglichkeiten und ein immenses Potenzial, um in der Qualitätssicherung schneller und besser zu werden, zum Beispiel durch das Training großer Datenmodelle zur Generierung automatisierter Testskripte, Re-Sequenzierung, Risikoquantifizierung und präzise Vorhersagen für bestimmte Plattformen.
Automatisieren der Automatisierung?
Ja. Das hat verschiedene Aspekte. Wir können heute bessere automatisierte Tests entwickeln, die stärker modularisiert und strukturiert und damit wiederverwendbar und effizienter sind. Wir beherrschen die Integration verschiedener automatisierter Testausführungsmaschinen in CI/CD-Pipelines und bis zu einem gewissen Grad auch die Bereitstellung von Testdaten. Damit ist die Ausführung einer definierten automatisierten Testfallabfolge gut gesichert.
Diese automatisierten Tests müssen auch autonom durchgeführt werden können. Das heißt, eine Test Execution Engine weiß, wann was getestet werden muss, und kann überschauen, ob die Tests ordnungsgemäß ablaufen, und sie im Fall von Störungen oder Abbrüchen erneut starten. Darüber hinaus muss man natürlich klären, was mit den Testergebnissen geschehen soll: Wie werden diese einerseits genutzt, um das getestete System automatisiert zu verbessern, und wie werden diese andererseits genutzt, um die Tests selbst zu verbessern? Am Ende verbessern sich die Tests selbst, eine neue Dimension des Themas Self-Healing in der IT.
Müssen die Entwicklungsplattformen und die entstehenden Applikationen in gewisser Weise ein Testbewusstsein haben, also „wissen“, dass an bestimmten Punkten im Entwicklungsprozess getestet wird, um die von Ihnen beschriebene Art des Testens überhaupt realisieren zu können?
Das Test-Driven Development, kurz TDD, hilft dabei. Wenn diese Methoden in Entwicklungsplattformen inkludiert sind, werden Applikationen quasi mit einem Test-Mindset entwickelt. Je früher Sie testen können, je früher Sie Fehler und Defekte feststellen können, desto eher haben Sie eine funktionierende Applikation. Deshalb ist es enorm wichtig, eine robuste und integrierte CI/CD-Pipeline zu haben, die mit Continuous Integration und Continuous Deployment hilft, doppelte Arbeit zu vermeiden.
Inwieweit unterscheiden sich die QE-Strategien bei individuell entwickelter Software und bei der Nutzung von Services aus der Cloud?
Die Art, wie Sie testen und welche Funktionalitäten Sie testen, unterscheidet sich. Aber in der Regel arbeiten Individualsoftware und Cloud-Services nicht unabhängig voneinander, sondern in der gleichen IT-Landschaft mit vielen Abhängigkeiten zueinander. Das bedeutet wiederum, dass zuerst die einzelnen Funktionalitäten, aber auch das Zusammenspiel des Gesamtsystems getestet werden muss. Ähnlich verhält es sich im Übrigen mit Multi-Speed-IT-Landschaften, in denen Applikationen sowohl nach der Wasserfallmethode als auch mit agilen Verfahren kreiert werden. Auch zwischen diesen gibt es viele Abhängigkeiten. Deshalb benötigen Unternehmen einen holistischen Quality-Engineering-Ansatz.
"Außerdem muss man sich auch die Frage stellen, was schlechte Qualität kostet: Was kostet eine Downtime, was kosten falsch ausgeführte Transaktionen etc.?"
Wahrscheinlich hat Accenture deshalb den Begriff Holistic Quality Engineering geprägt. Aber auf der anderen Seite müssen die Unternehmen den Cloud-Providern nachweisen können, dass es die Cloud-Seite ist, die nicht ordnungsgemäß funktioniert, sprich die vereinbarten SLAs verletzt.
Es geht darum, den Defekt zu erkennen, dem richtigen Verantwortungsbereich zuzuordnen und zu beheben. Aber wenn Sie der CEO oder der Product Owner sind, dann zählt für Sie eigentlich nicht, wo der Defekt genau liegt, sondern wichtig ist für Sie, dass der Prozess nicht funktioniert und Ihr Geschäft beeinträchtigt wird. Ganzheitlich bedeutet für uns, dass die vielen verschiedenen Aspekte von Qualität wie Performance, Security, Availability, Resilience etc. ebenfalls berücksichtigt werden. Da ist die Root-Cause-Analyse nur ein Teil davon.
Dieser ganzheitliche Ansatz klingt nach großer Komplexität, nach sehr großem Aufwand und nach sehr hohen Kosten für das Anwenderunternehmen. Wie kann ein durchschnittliches Unternehmen damit umgehen?
Ja, das ist kompliziert. Aber diese Komplexität ist eine Funktion der Business-Komplexität. Das bedeutet, eine kleinere oder nur durchschnittlich große Firma muss eine geringere Komplexität bewältigen als eine große oder sehr große Organisation. Außerdem muss man sich auch die Frage stellen, was schlechte Qualität kostet: Was kostet eine Downtime, was kosten falsch ausgeführte Transaktionen etc.? Das ist das Wesen von Risikomanagement. Wie viel Risiko kann ich in welchen Bereichen akzeptieren? Dort, wo ein höheres Risiko akzeptabel ist, kann ich auch eine geringere Qualität akzeptieren. Aber die Unternehmen müssen sich die Mühe machen, die Risikofähigkeit ihrer verschiedenen Tätigkeitsbereiche zu klassifizieren. Es geht beim Quality Engineering immer um die Balance zwischen Aufwand und Nutzen.
Können Unternehmen diesen holistischen Ansatz selbst bewältigen oder brauchen sie externe Unterstützung?
(lacht) Als Accenture-Mitarbeiter sage ich natürlich, dass es ohne externe Hilfe nicht machbar ist. Aber im Ernst: Die Software- und Cloud-Entwicklung ist so dynamisch, dass es für Unternehmen schwierig sein dürfte, stets "State of the Art" zu sein. Wir lernen schneller, weil wir von verschiedenen Kundenengagements und vom Markt lernen. Es hängt vom Unternehmen ab, welche Services es bei uns in Sachen QE einkauft. Manche machen ihr Quality Engineering nahezu komplett selbstständig, da beraten wir nur. Bei anderen sind wir viel tiefer involviert. Doch in jedem Fall benötigen Unternehmen eine gewisse Expertise in Sachen QE – zumindest so viel, dass sie die extern bezogenen QE-Services einschätzen und einkaufen können.
Organisatorisch gesehen: Ist es sinnvoller, QE als übergeordnete Funktion zu betreiben, oder muss es Bestandteil jedes Entwicklungsteams sein?
In Zeiten von Agile sowie Dev- und Sec-Ops muss QE bis hin zu den Systemtests in den verschiedenen Teams verankert sein. Wenn es aber in Richtung End-to-End-Softwarequalität geht, dann braucht es zentrale Verantwortlichkeiten auch außerhalb der agilen Product-Teams.
Wissen Sie, wie viele Unternehmen über eine ausführbare QE-Strategie verfügen?
Fast jedes Unternehmen hat eine QE-Strategie. Die wichtigere Frage ist aber, wie modern und effektiv diese Strategie ist. Meiner Einschätzung nach gibt es erst sehr wenige Unternehmen, die eine End-to-End-QE-Strategie entwickelt haben, die alle Aspekte berücksichtigt und aktuelle Technologien sinnvoll nutzt. In den meisten Unternehmen wird QE nicht ganzheitlich gesehen; sie begnügen sich mit Softwaretesting und setzen auf entsprechende KPIs. Aber Quality Engineering unterstützt ferner direkt das Business. Deshalb sollten die KPIs dafür auch nicht "Detection Rate", sondern beispielsweise "Customer Availability" oder "Process Downtime" lauten.
Welchen Einfluss hat QE auf technische oder architektonische Schulden?
In einer Zeit, in der das Thema Time-to-Market eine so herausragende Bedeutung hat, ist die Frage wichtig, wie viele technische Schulden akzeptabel sind. Je schneller ich sein will, desto mehr technische Schulden häufen sich an. Es müssen also auch hier Kompromisse eingegangen werden zwischen Qualität und Geschwindigkeit.
Softwarequalität hängt auch sehr stark von den Software- und Cloud-Providern ab. Je besser die Qualität ihrer Services, desto leichter tun sich Anwenderunternehmen mit dem QE. Aber stimmt mein Eindruck, dass die Softwarequalität in den letzten Jahren eher zurückgegangen ist? Die hohe Zahl an Patches, die zu den monatlichen Patch Days der großen Provider veröffentlicht wird, legt diese Vermutung nahe.
Wir wissen, dass Qualität eine Frage des Aufwands ist. Wenn der Kostendruck steigt, leidet die Qualität an irgendeiner Stelle. Das Gleiche gilt für die Zeit: Je schneller etwas fertig werden muss, desto weniger wird getestet. Abgesehen davon glaube ich nicht, dass die IT-Qualität insgesamt gesunken ist. Sie sollten Ihre Eindrücke aus der Perspektive der viel höheren Komplexität der Geschäftsprozesse betrachten, der viel reichhaltigeren Funktionalitäten, die oft über die organisatorischen Grenzen, den Nutzungsgrad und die Reichweite von Softwaresystemen hinausgeht. Ich persönlich denke, dass die Stabilität und Verfügbarkeit von Softwaresystemen in Anbetracht dieser Faktoren eher vergleichsweise deutlich zugenommen hat – allerdings kann man auch sagen, dass die Auswirkungen von Qualitätsmängeln oder Produktionsstörungen viel höher und sichtbarer sind.
Inwieweit ist Qualität eine Zeitfrage, was sind die Grenzen des Machbaren?
Sie können mit Automatisierung und AI die Zeit für Quality Engineering verkürzen, aber nicht auf null reduzieren. Das ist wie bei einem Rennwagenfahrer. Mehr Training, bessere, aerodynamische Ausrüstung reduzieren die Zeit, die er für eine bestimmte Strecke braucht. Aber die Zeit auf null zu reduzieren ist physikalisch nicht möglich. Jetzt übertragen Sie das auf die Softwareunternehmen. Früher haben sie vielleicht zweimal pro Jahr ein neues Release herausgebracht, heute tun sie das einmal im Monat, und das häufig mit viel mehr Lines of Code als früher. Softwareentwicklung ist viel effektiver als vor einigen Jahren. Aber weitreichendere Funktionalität und größere Komplexität wirken sich auf die Qualität aus, sodass mehr Aufmerksamkeit erforderlich ist, um die Qualität zu erhalten.
Zu Pankaj Rai
Pankaj Rai Jain ist seit 19 Jahren Managing Director und Partner für große Technologiekunden des Beratungsunternehmens Accenture und seit 13 Jahren von München aus tätig. Herr Jain ist auch Quality Engineering Business Lead für Accenture, Europa. Er studierte Wirtschaftsingenieurwesen am Indian Institute for Technology.
