Agentisch testen: Wie wir eine ISMS-Software im simulierten Unternehmen prüfen
Beim agentischen Testen bekommt eine KI einen Auftrag in Alltagssprache und keinen vorgegebenen Pfad, und sie bedient die Software selbst, so wie es ein Mensch tun würde. Herkömmliche Tests prüfen, ob eine Software tut, was vorher festgelegt wurde. Ein agentischer Test fragt zusätzlich, ob jemand, der nur sein Ziel kennt, mit der Software dort ankommt. Aus unserer Sicht zählt das vor allem, wenn viele Rollen mit einer Software arbeiten und ihre Aufträge in eigenen Worten formulieren. OdySecure soll viele Rollen durch die Einführung eines Managementsystems für Informationssicherheit (ISMS) führen. Deshalb testen wir OdySecure zusätzlich agentisch, in einem simulierten Unternehmen, in dem Agenten mit Aufträgen handeln.
Was herkömmliche Tests leisten
Ein Unit-Test prüft eine einzelne Funktion mit festgelegten Eingaben, etwa ob eine Berechnung aus zwei Werten das erwartete Ergebnis liefert. Ein geskripteter Oberflächentest klickt einen festgelegten Pfad durch die Anwendung. Bei einer manuellen Abnahme prüfen Menschen ausgewählte Abläufe vor einer Freigabe.
Alle drei prüfen gegen eine vorher festgelegte Erwartung. Das macht sie wiederholbar und eindeutig. Unsere Backend- und Frontend-Tests laufen in der CI, bevor eine Änderung in OdySecure übernommen wird.
Ein ISMS entsteht aber in Abläufen über mehrere Rollen und Freigaben und in Entscheidungen, die Menschen anhand dessen treffen, was die Software ihnen zeigt. Unsere Simulation verbindet beides. Eine Kette spielt die Einführung eines ISMS mit Personen in unterschiedlichen Rollen durch, und eine Persona sucht ihren Weg aus einem Auftrag in Alltagssprache selbst. So werden auch Fehler sichtbar, die zwischen den Funktionen liegen.
Ein Unternehmen, das es nicht gibt
Die Kessler & Rauh Armaturen GmbH stellt Armaturen für Wasserversorger und die chemische Industrie her. Sie hat 340 Beschäftigte, ihre Zentrale mit Werk in Siegen, ein zweites Werk in Olpe und ein Vertriebsbüro in Linz. Dazu kommen 15 Lieferanten. Namen, Adressen und Lieferanten sind erfunden.
Im Szenario handeln 24 Personen mit eigenen Rollen, von der Geschäftsführung und der Informationssicherheit über Werksleitung, Einkauf und Datenschutz bis zu den Ansprechpartnern eines Lieferanten. Jede Person meldet sich mit eigenem Konto an und arbeitet in einer eigenen Browsersitzung. Bei Freigaben nach dem Vier-Augen-Prinzip beantragt etwa die Informationssicherheit, ihre Stellvertretung prüft, und die Geschäftsführung gibt frei. Nach jedem Schritt prüft der Test den Stand aus Sicht der jeweils anderen Person.
25 Stationen, 253 Schritte
Die Kette folgt der Einführung eines ISMS. Sie beginnt mit dem Auftrag der Geschäftsführung und dem Einrichten von Mandant, Modulen, Benutzern und Rollen. Danach liest das Team vorhandene Unterlagen ein, legt Kontext und Anwendungsbereich fest, bewertet Geschäftsprozesse, Assets und Schutzbedarf und schreibt die Leitlinie.
Es folgen Risikomethodik und Risikoappetit, das Bewerten und Behandeln der Risiken, Themenrichtlinien, Controls und die Erklärung zur Anwendbarkeit. NIS-2 nach dem BSIG kommt mit einer Bewertung je Werk hinzu. Danach geht es um Nachweise, eine Lieferantenbewertung mit Fragebogen, das Notfallmanagement, einen Sicherheitsvorfall mit Schwachstellen und eine Awareness-Schulung. Am Ende steht der Behandlungsplan.
Das sind 25 Stationen, einige mit Unterstationen, zusammen 253 Schritte. Ein vollständiger Lauf dauert rund 21 bis 26 Minuten.
Das Bild oben zeigt den Grundriss des Unternehmens mit Büros und Werkhallen, wie ihn die Bühne eines aufgezeichneten Laufs vom 2. November darstellt. Jede Figur steht für eine Person. Die Sprechblase zeigt den laufenden Schritt, ein grünes Häkchen zeigt, dass die Person fertig ist. Maßgeblich für das Ergebnis bleibt die Textsicht.
Jeder Schritt hat eine feste Prüfregel
Die Schritte laufen als automatisierte Tests mit Playwright, einem Werkzeug für Browsertests. Jeder Schritt endet mit einem von vier Ergebnissen: bestanden, nicht bestanden, nicht messbar oder nicht durchgeführt. Der Test prüft die Anzeige in der Oberfläche und die gespeicherten Daten.
Über das Ergebnis entscheidet eine feste Prüfregel. Kein Sprachmodell bewertet, ob ein Schritt gelungen ist, und so bleibt jedes Ergebnis nachprüfbar. Die Tests selbst schreibt eine KI, und ein zweites, unabhängiges Modell prüft jede neue Fassung.
Eine KI-Persona sucht ihren Weg selbst
Eine KI-Persona aus der Informationssicherheit arbeitet Aufträge in Alltagssprache selbst ab, etwa diesen: „Wir müssen jetzt auch NIS-2 erfüllen. Nimm das in OdySecure auf und sieh nach, was uns noch fehlt.“ Ein zweiter Auftrag beginnt mit: „Ein Kunde verlangt von uns TISAX.“
Einen Pfad bekommt die Persona nicht vorgegeben. Sie sucht ihn selbst über Menüs, Seiten und Beschriftungen und bedient OdySecure im Browser so, wie es ein Mensch tun würde. Damit prüft der Lauf, ob die Oberfläche einen Menschen zum Ziel führt, der nur seinen Auftrag kennt. Zum Schluss berichtet die Persona der Geschäftsführung, was sie aufgenommen hat und welche Anforderungen offen sind.
Jeder Auftrag läuft in mehreren gezählten Durchgängen, und nach jedem Durchgang wird der Ausgangsstand wiederhergestellt. In den Läufen vom 3. November hat die Persona beide Aufträge in jedem Durchgang erledigt und brauchte dafür zwischen 44 und 85 Schritte. Das Sprachmodell hinter der Persona betreiben wir selbst, und seine Anfragen laufen über OdyControl, unsere Kontrollebene für Unternehmens-KI.
Was zwischen den Funktionen passiert
Ein Beispiel: Der Auftrag „NIS-2 erfüllen“ aktivierte am 31. Oktober die EU-Richtlinie als Regelwerk. OdySecure aktivierte damit genau das Regelwerk, das die Persona ausgewählt hatte. Für ein Unternehmen in Deutschland war es trotzdem das falsche, denn hier gilt NIS-2 über das BSIG, das die Richtlinie in deutsches Recht umsetzt.
Nach unserer Einschätzung hätte ein Test, der nur die Aktivierung des ausgewählten Regelwerks prüft, bestanden. Sichtbar wurde der Fehler im Lauf der Persona, weil das ausgewählte Regelwerk nicht zum Auftrag passte.
Findet die Simulation einen Fehler, beheben wir ihn im Produktcode, nie nur im Testaufbau. In diesem Fall zeigen Name und Beschreibung der Regelwerke jetzt, ob es um die EU-Richtlinie oder um das deutsche Gesetz geht. Die Richtlinie verweist außerdem auf das BSIG. Am 3. November haben wir auf der Testumgebung nachgemessen, und derselbe Auftrag aktivierte das BSIG. Ob ein Fehler verschwunden ist, misst jeweils ein späterer Lauf nach.
Was jede Testart beantwortet
Ein Unit-Test beantwortet, ob eine Funktion richtig rechnet. Ein geskripteter Oberflächentest beantwortet, ob ein bekannter Pfad funktioniert. Die Simulation beantwortet, ob ein Unternehmen mit seinen Rollen und mit Aufträgen in eigenen Worten zum richtigen Ergebnis kommt. Für eine ISMS-Software halten wir die dritte Frage für die, an der sich der Nutzen im Alltag entscheidet.
Die Simulation läuft in eigenen Testmandanten auf unserer Testumgebung, nie im Produktivbetrieb und nie in Kundenmandanten.
Wie die Plattform aufgebaut ist, zeigt die Seite zur Cybervize-Plattform. Wie Agenten im ISMS mitarbeiten, beschreibt die Seite zum Agentic ISMS.