La révolution LLM SAP Testing

Testing umfasst eine ganze Reihe von Aktivitäten. An den beiden Enden eines SAP-Projekts stehen Unit-Tests (Entwickler) und User-Acceptance-Tests (Key User). Dazwischen ist das funktionale Testing die Hauptaktivität – es macht rund 80 Prozent der Kosten aus –, ergänzt durch nicht funktionale Tests (z. B. Security-, Performance- und mittlerweile auch UX-Tests). SAP-Testing unterscheidet sich von dem Testen individueller Anwendungen. Zwar bleiben die Grundkonzepte dieselben, aber die Werkzeuge sind meist andere – SAP hat sich inzwischen auf Tricentis als Standard festgelegt. Zudem legt SAP-Testing einen stärkeren Fokus auf Integrationstests und den Datenfluss zwischen Anwendungen. Daten – also Datenaustausch, Tabellen und Stammdaten – haben in der SAP-Welt eine weitaus höhere Priorität als bei individuell entwickelten Anwendungen.

In den vergangenen zwanzig Jahren blieb das funktionale Testing weitgehend unverändert und beruhte auf einem grundlegenden Prozess: Anforderungen bzw. User Stories, Testfälle und Testskripte. Es gab zahlreiche Versuche, diesen Prozess zu automatisieren – erinnern Sie sich an die „Scriptless Testing Frameworks“? Mit dem Aufkommen agiler Methoden und DevOps-­Tools entstanden neue Plattformen, ob sie nun DevOps- oder Continuous-Testing-­Plattformen genannt wurden. Die Branche sprach von Hyperautomation. Dennoch blieb der Prozess aus Anforderungen, Testfällen und Skripten zentral.

Enorme Produktivitätsgewinne

Warum dieser historische Überblick über das Testing? LLMs werden das Testing grundlegend verändern. Wenn User Stories einigermaßen gut formuliert sind, können LLMs Testskripte in Minuten generieren – statt in Wochen. Die Produktivitätsgewinne sind beeindruckend, und die Kosten für LLMs sind im Vergleich zu menschlicher Arbeitskraft minimal (und sinken weiter). Das Schreiben von Testskripten erfordert keine Testingenieure mehr – es wird automatisiert. In Zukunft wird das funktionale Testing somit kein Engpass mehr in SAP-Projekten sein.

Eine Revolution ist im Gange, deren Auswirkungen in den kommenden Jahren weitreichend sein werden – sie wird das Tool-Ökosystem verändern, Softwarelizenzen und -abonnements überflüssig machen und den Testaufwand deutlich reduzieren. LLMs sind bestens geeignet für Greenfield-, Grow- oder Public-Cloud-Projekte. Die Natur von SAP, mit seiner Abhängigkeit von standardisierten Geschäftsprozessen, macht es ideal für solche Projekte im funktionalen Testing. Standardisierte SAP-Geschäftsprozesse sind gut dokumentiert und leicht zugänglich und können zur Erstellung von Testartefakten verwendet werden.

Schwieriger wird der Einsatz von LLMs in Brownfield-(und Bluefield-)Umgebungen – die, man kann mit gutem Grund sagen, den Großteil aller S/4-Projekte ausmachen. Aus Testperspektive liegt hier die Priorität nicht mehr darauf, neue Testartefakte von Grund auf zu erstellen, sondern darauf, die bestehenden Testbestände zu verstehen.

Die meisten Organisationen (Zahlen sind schwer zu erfassen) verfügen über mehrere tausend Testartefakte (ebenfalls schwer zu quantifizieren), darunter Anforderungen, Testszenarien, Testfälle und Skripte. Diese Artefakte sind zugleich ein Vermögenswert (sie spiegeln die Geschäftsprozesse der Organisation auf SAP-Transaktionsebene wider) und eine Belastung.

Der nächste Schritt besteht also darin, diese Artefakte zu verstehen: ihre Funktion, ihre Qualität und ihre Relevanz. Das ist keineswegs das erste Mal, dass Organisationen ihre Testbestände überprüfen – der letzte Versuch, vor einigen Jahren, nutzte NLP, um redundante Testfälle zu identifizieren. Diesmal jedoch bieten LLMs Reverse-Engineering-Fähigkeiten: Sie können Testfälle aus Testskripten oder User Stories generieren. Mit anderen Worten: LLMs können helfen zu bestimmen, welche Testskripte tatsächlich ausgeführt werden müssen, sodass Organisationen sich auf das Wesentliche konzentrieren können – anstatt ihren gesamten Testbestand abzuarbeiten.

Kosteneinsparungen, aber wo?

Dies ist der erste Schritt beim Einsatz von LLMs im Quality Engineering. Die Welt der LLMs ist eine Welt voller Chancen – aber auch voller Herausforderungen. LLMs bringen zwar enorme Produktivitätsgewinne, doch diese führen nicht zwangsläufig zu signifikanten Kosteneinsparungen. Das muss noch besser verstanden werden. Wir haben jedoch einige Hinweise: Testing ist ein Prozess mit vielen Schritten – über das funktionale Testing hinaus – und enthält Engpässe (zum Beispiel die Verfügbarkeit von Testumgebungen), die die Gesamtdauer des Testzyklus beeinträchtigen können.

Ein weiterer Aspekt ist, wie Testexperten LLMs einsetzen werden. Werden sie die Produktivitätsgewinne nutzen, um Test­zyklen zu verkürzen? Oder werden sie einen Teil der gewonnenen Zeit für zusätzliche Qualitätsprüfungen und Ursachenanalysen verwenden, um die Softwarequalität zu erhöhen? Das wäre eine großartige Entwicklung – denn Softwaretesting und Softwarequalität sind einander noch nie so nahe gewesen wie heute.

Continuer vers l'inscription du partenaire :