KI-generierte Testfälle im ISO-26262-Assessment

Bestehen KI-generierte Testfälle das ISO-26262-Assessment?

Ja, KI-generierte Testfälle bestehen ein ISO-26262-Assessment, wenn drei Bedingungen erfüllt sind: eine dokumentierte Herleitung je Testfall mit Anforderungsbezug und Traceability, ein Review- und Validierungsnachweis durch eine qualifizierte Person und ein beschriebener Testprozess, in dem das KI-Werkzeug ausdrücklich eingeordnet ist. Der Assessor bewertet das Arbeitsprodukt und den Prüfprozess dahinter; die Herkunft des Entwurfs ist dabei zweitrangig. Ein LLM-basiertes Werkzeug erhält dieses Vertrauen über die nachgelagerte Prüfung seines Outputs, denn auf das Werkzeug selbst lässt sich wegen seines Nicht-Determinismus kein tragfähiges Qualifizierungsargument bauen. sensified ordnet KI-gestützte Testfall-Erstellung als vorbereitende Automatisierung mit Prüfpunkt beim Menschen ein und beschreibt den Nachweispfad, der sie assessierbar hält.

Die Frage im Titel wird selten aus Neugier gestellt. Sie kommt auf, wenn ein Assessment im Kalender steht und das Testteam in den Monaten davor Testfall-Entwürfe aus einem Sprachmodell übernommen hat: Die Regressionssuite ist gewachsen, die Erstellungszeiten sind gesunken, und jetzt will die Qualitätssicherung wissen, ob diese Testfälle vor einem Assessor nach ISO 26262 bestehen. Die ehrliche Antwort beginnt mit einer Gegenfrage: Wie sieht die Nachweiskette je Testfall aus? Dieser Beitrag beschreibt aus Sicht von SQA- und Safety-Verantwortlichen, was der Assessor sehen will, warum das KI-Werkzeug in die Tool-Vertrauensbetrachtung gehört und weshalb der Prüfprozess über das Ergebnis entscheidet. Er vertieft das Testunterstützungs-Feld aus dem Überblick zur KI in der Automotive-Softwareentwicklung. Die Eignungsaussagen sind typisierte Hypothesen aus Projekterfahrung, die je Kunde und Toolchain zu prüfen sind. Über Personen oder deren Leistung trifft dieser Beitrag keine Aussage.

Was der Assessor prüft: Arbeitsprodukt und Prozess

Ein Assessment nach ISO 26262 ist keine Werkzeug-Abnahme. Geprüft wird, ob die Arbeitsprodukte die Anforderungen der Norm erfüllen und ob der Prozess, der sie erzeugt hat, beherrscht und dokumentiert ist. Das ist die gute Nachricht für Teams, die KI im Test einsetzen wollen, und zugleich die unbequeme: Die Messlatte liegt nicht beim Werkzeug, sie liegt bei der Evidenz.

Was ISO 26262 vom Testfall verlangt

ISO 26262-6 verlangt in der Software-Verifikation anforderungsbasiertes Testen über alle ASIL-Stufen hinweg und benennt Methoden zur Ableitung von Testfällen, darunter die Analyse der Anforderungen, die Bildung von Äquivalenzklassen, die Grenzwertanalyse und die Fehlererwartung aus Erfahrung. Jeder Testfall braucht demnach einen nachvollziehbaren Bezug zu der Anforderung, die er prüft, und eine benennbare Ableitungsmethode. Dazu kommt die bidirektionale Traceability: Von der Sicherheitsanforderung muss der Weg zu den zugehörigen Testfällen führen und umgekehrt. Diese Anforderungen existierten lange vor Sprachmodellen, und sie gelten unverändert für jeden Testfall, der heute aus einem KI-Werkzeug kommt.

Warum die Herkunft des Entwurfs zweitrangig ist

Die Norm unterscheidet Testfälle nicht nach ihrem Autor. Sie verlangt Eigenschaften und Nachweise: Anforderungsbezug, Ableitungsmethode, Review, Abdeckung. Ein Testfall aus einem Sprachmodell wird an denselben Kriterien gemessen wie ein Testfall aus der Hand eines Testingenieurs. Was sich ändert, ist die Beweislast im Prozess: Bei einem menschlich erstellten Testfall trägt die Qualifikation des Erstellers einen Teil des Vertrauens. Bei einem KI-Entwurf muss dieses Vertrauen vollständig aus der nachgelagerten Prüfung kommen, und genau dort schauen Assessoren inzwischen genau hin.

Die Nachweiskette je Testfall

Aus den Norm-Anforderungen ergibt sich eine Kette von Nachweisen, die für jeden einzelnen Testfall stehen muss. Wer sie einmal sauber aufsetzt, kann KI-Entwürfe in Serie übernehmen; wer sie auslässt, sammelt mit jedem übernommenen Entwurf Assessment-Risiko an.

Herleitung und Anforderungsbezug

Der erste Nachweis ist die Herleitung: Aus welcher Anforderung ist der Testfall abgeleitet, mit welcher Methode, gegen welchen Versionsstand? Ein KI-Werkzeug kann diese Angaben im Entwurf mitliefern, verlässlich werden sie erst durch die Verknüpfung im Testmanagement-System und die Bestätigung durch den Menschen. Praktisch heißt das: Kein Testfall wird ohne verknüpfte Anforderung übernommen, und die Ableitungsmethode wird je Testfall dokumentiert, nicht pauschal je Suite. Wie diese Evidenzarbeit über den Test hinaus funktioniert, beschreibt der Beitrag zu Traceability und Evidenz mit KI unter Automotive SPICE (ASPICE).

Review und Validierung durch eine qualifizierte Person

Der zweite Nachweis ist die Prüfung. Jeder KI-generierte Testfall durchläuft dasselbe Review, das auch für menschlich erstellte Testfälle gilt: fachliche Prüfung gegen die Anforderung, Kontrolle der Grenzwerte und Äquivalenzklassen, Bewertung der Verifizierbarkeit. Der Reviewer ist benannt, seine Rolle und Qualifikation sind dokumentiert, das Review-Ergebnis liegt je Testfall vor. Sinnvoll ist zusätzlich eine Kennzeichnung, welche Testfälle KI-gestützt entstanden sind. Sie schafft Transparenz im Assessment und erlaubt gezielte Stichproben durch die SQA, bevor der Assessor sie zieht.

Das Nachweisraster für das Assessment

Die folgende Übersicht verdichtet die Nachweiskette zu einem Raster, mit dem sich die eigene Assessment-Reife prüfen lässt. Jede Zeile beantwortet eine Frage, die der Assessor in dieser oder ähnlicher Form stellen wird.

Das Raster ist bewusst werkzeugneutral gehalten. Es funktioniert für Testfälle aus einem Sprachmodell genauso wie für Testfälle aus einem Skript-Generator oder aus menschlicher Arbeit; nur die letzte Zeile verlangt beim KI-Werkzeug eine besondere Begründung, und um die geht es jetzt.

Das KI-Werkzeug in der Tool-Vertrauensbetrachtung

Sobald ein Werkzeug Einfluss auf sicherheitsrelevante Arbeitsprodukte nehmen kann, gehört es in die Tool-Vertrauensbetrachtung. Das gilt für den Compiler, das gilt für das Testmanagement-System, und das gilt für ein KI-Werkzeug, das Testfälle für sicherheitsrelevante Software entwirft.

TI, TD, TCL: die Logik der Norm

ISO 26262-8:2018 beschreibt in Klausel 11 das Vorgehen, mit dem Vertrauen in Software-Werkzeuge hergestellt wird (Herausgeber: ISO, 2018). Zuerst wird der Tool Impact bestimmt: TI1, wenn ein Werkzeugfehler keine Sicherheitsanforderung verletzen kann, TI2, wenn diese Möglichkeit besteht. Danach die Tool Error Detection: TD1 bei hoher, TD2 bei mittlerer Zuversicht, dass ein Werkzeugfehler verhindert oder erkannt wird, TD3 in allen übrigen Fällen. Aus der Kombination ergibt sich der Tool Confidence Level nach der Matrix in 11.4.5: TCL1 erfordert keine weitere Qualifizierung, für TCL2 und TCL3 verlangt die Norm eine Qualifizierung über eine geeignete Kombination der vier Methoden aus 11.4.6, also erhöhtes Vertrauen aus der Nutzung, Bewertung des Werkzeug-Entwicklungsprozesses, Validierung des Software-Werkzeugs oder Entwicklung nach einer Sicherheitsnorm.

Warum ein LLM anders zu bewerten ist als ein deterministischer Generator

Für einen deterministischen Testfall-Generator, etwa ein Skript, das aus Signalspezifikationen Grenzwert-Testfälle erzeugt, funktionieren die klassischen Qualifizierungswege: Das Werkzeug hat ein spezifiziertes Verhalten, gleiche Eingabe erzeugt gleiche Ausgabe, und die Validierung gegen die Spezifikation ist durchführbar. Ein LLM-basiertes Werkzeug bricht mit diesen Annahmen. Sein Output ist nicht deterministisch, dieselbe Eingabe kann unterschiedliche Testfälle liefern, und ein vollständig spezifiziertes Soll-Verhalten, gegen das sich validieren ließe, existiert nicht. Auch das Argument des erhöhten Vertrauens aus der Nutzung trägt kaum, weil sich aus fehlerfreier Vergangenheit keine Aussage über den nächsten Entwurf ableiten lässt.

Der tragfähige Weg dreht deshalb die Blickrichtung: Statt Vertrauen in das Werkzeug aufzubauen, wird die Fehlererkennung im Prozess hochgehalten. Wenn jeder generierte Testfall verpflichtend durch Review, Validierung gegen die Anforderung und Traceability-Prüfung läuft, wird ein fehlerhafter Entwurf mit hoher Zuversicht erkannt, bevor er wirksam wird. Genau diese Argumentation kennt die Norm: Die Einstufung der Fehlererkennung bewertet den Werkzeug-Einsatz im Kontext des Prozesses, und ein lückenloser nachgelagerter Prüfschritt ist das stärkste Argument, das ein Team für ein nicht-deterministisches Werkzeug führen kann. Die Begründung gehört schriftlich in die Tool-Vertrauensbetrachtung, einschließlich der Annahme, dass der Prüfschritt für jeden einzelnen Entwurf verbindlich ist.

Der dokumentierte Prozess: wo das Werkzeug eingeordnet ist

Die dritte Bedingung aus der Kernantwort ist der Prozess selbst. Ein Assessor, der auf KI-gestützte Testfälle trifft, will die Prozessbeschreibung sehen, in der das Werkzeug vorkommt: als benannter Schritt mit definiertem Ein- und Ausgang, nicht als stillschweigende Praxis einzelner Teammitglieder.

Freigabepfad und Kennzeichnung

In unserem Vorgehensmodell ist die KI-gestützte Testfall-Erstellung eine Tätigkeit der Klasse A2, also vorbereitende Automatisierung mit Prüfpunkt beim Menschen. Der rote Faden lautet: KI assistiert, der Mensch verantwortet. Konkret bedeutet das ein versioniertes Regelwerk für die Nutzung, eine Kennzeichnung KI-gestützter Entwürfe im Testmanagement, einen definierten Freigabepunkt je Testfall und einen dokumentierten Rückholweg, falls das Werkzeug aus dem Prozess genommen werden muss. Nichts davon ist Papier für den Assessor allein; dieselbe Ordnung schützt das Team im Alltag vor unmarkierten Entwürfen in der Suite.

Typische Lücken kurz vor dem Assessment

Die Lücken, die in der Vorbereitung auffallen, ähneln sich. Testfälle wurden informell mit einem frei verfügbaren Werkzeug entworfen und ohne Kennzeichnung übernommen. Das Review hat stattgefunden, wurde aber nicht je Testfall dokumentiert. Die Tool-Vertrauensbetrachtung existiert für Compiler und statische Analyse, das KI-Werkzeug fehlt darin. Jede dieser Lücken ist einzeln behebbar, zusammen erklären sie, warum die Branche beim Nachweis unter Druck steht: 46 % der Automotive-Teams fällt der Nachweis der ISO-26262-Konformität schwer (Quelle: Perforce, 2025). Werkzeuge, die Testfälle schneller erzeugen, verschärfen dieses Problem, wenn die Nachweiskette nicht mitwächst; sie entlasten es, wenn die Kette steht.

Die Position: der Prüfprozess besteht, das Werkzeug nicht

Damit lässt sich die Titelfrage präzise beantworten. „Der Testfall besteht das Assessment, wenn der Prüfprozess trägt; das Werkzeug allein besteht nichts.“ Ein Assessment bewertet Arbeitsprodukte und Prozesse, und beide lassen sich mit KI-Unterstützung in derselben Qualität führen wie ohne. Wer umgekehrt hofft, ein zertifiziertes oder qualifiziertes KI-Werkzeug könne die eigene Nachweisarbeit ersetzen, missversteht die Logik der Norm: Für ein nicht-deterministisches Werkzeug gibt es diese Abkürzung nicht.

Die Frage nach den Testfällen ist dabei Teil eines größeren Bildes. Auf derselben Teststrecke stellt sich die Nachweisfrage auch bei der änderungsbasierten Auswahl von Regressionstests, die der Beitrag zur KI-basierten Testselektion am HIL-Prüfstand behandelt. Und wer über die Werkzeug-Ebene hinaus denkt, findet in ISO/PAS 8800 die Norm-Perspektive für KI-Funktionen im Fahrzeug selbst; die Abgrenzung zwischen KI als Entwicklungswerkzeug und KI als Fahrzeugfunktion ordnet der Beitrag zur Einordnung von ISO PAS 8800 ein.

Nächste Schritte

Ob die eigene Nachweiskette ein Assessment trägt, entscheidet sich an der Toolchain, an den Evidenzpflichten des Projekts und an der Frage, wie das KI-Werkzeug heute tatsächlich genutzt wird. Der geordnete Einstieg sieht so aus:

1. Überblick lesen: Der Beitrag zur KI in der Automotive-Softwareentwicklung ordnet die Testunterstützung neben Code-Assistenz, Requirements-Prüfung und Doku-RAG ein.
2. Vorgehen prüfen: Die Seite zur AI-Transformation im Automotive Engineering beschreibt, wie aus einzelnen Bausteinen ein geführtes Transformationsvorhaben mit Nachweispfad wird.
3. Gespräch vereinbaren: In einem Qualifying-Call klären wir, wie Ihr Testprozess heute aufgestellt ist und welche Nachweise vor dem nächsten Assessment zu schließen sind.

Häufige Fragen

Die folgenden Antworten fassen die Position von sensified zur Assessierbarkeit KI-generierter Testfälle zusammen. Sie beschreiben typisierte Nachweispfade; wie die Kette in einem konkreten Projekt aussieht, wird je Kunde und Toolchain geprüft.

Akzeptieren Assessoren KI-generierte Testfälle grundsätzlich?

Ja, denn ISO 26262 unterscheidet Testfälle nicht nach ihrem Autor. Bewertet werden Anforderungsbezug, Ableitungsmethode, Review und Traceability des einzelnen Testfalls sowie der Prozess dahinter. Ein KI-generierter Testfall, der diese Nachweise vollständig führt, steht im Assessment nicht schlechter da als ein menschlich erstellter.

Muss ein LLM-basiertes Testfall-Werkzeug nach ISO 26262 qualifiziert werden?

Es muss in die Tool-Vertrauensbetrachtung nach ISO 26262-8, Klausel 11 aufgenommen und eingestuft werden, sobald es sicherheitsrelevante Arbeitsprodukte beeinflussen kann. Die klassischen Qualifizierungsmethoden greifen bei einem nicht-deterministischen Werkzeug jedoch schlecht. Der tragfähige Weg hält stattdessen die Fehlererkennung hoch: Ein verpflichtender nachgelagerter Prüfschritt je Entwurf begründet eine niedrige Vertrauensanforderung an das Werkzeug selbst.

Warum reicht das Vertrauen in ein deterministisches Generierungstool nicht als Vorbild?

Ein deterministischer Generator hat ein spezifiziertes Verhalten und liefert für gleiche Eingaben gleiche Ausgaben; er lässt sich gegen seine Spezifikation validieren. Ein Sprachmodell erfüllt keine dieser Voraussetzungen, dieselbe Eingabe kann unterschiedliche Testfälle erzeugen. Deshalb verschiebt sich die Absicherung vom Werkzeug auf die nachgelagerte Prüfung jedes einzelnen Outputs.

Welche Nachweise verlangt der Assessor je Testfall?

Vier Dinge: die Herleitung mit Anforderungsbezug und benannter Ableitungsmethode, die bidirektionale Traceability zwischen Anforderung und Testfall, ein dokumentiertes Review durch eine benannte und qualifizierte Person und die Einordnung des erzeugenden Werkzeugs im beschriebenen Testprozess. Eine Kennzeichnung KI-gestützter Testfälle erleichtert Stichproben und schafft Transparenz.

Wer darf KI-generierte Testfälle freigeben?

Dieselben Rollen, die auch menschlich erstellte Testfälle freigeben: fachlich qualifizierte Testverantwortliche, deren Rolle und Kompetenz im Projekt dokumentiert sind. Die Freigabe ist ein definierter Prüfpunkt im Prozess und wird je Testfall festgehalten. Eine pauschale Freigabe ganzer generierter Suiten ohne Einzelprüfung trägt im Assessment nicht.

Was passiert bei informeller KI-Nutzung ohne dokumentierten Prozess?

Das ist der riskanteste Fall: Entwürfe aus frei verfügbaren Werkzeugen fließen unmarkiert in die Testsuite, ohne Kennzeichnung, ohne dokumentiertes Review, ohne Einordnung in der Tool-Vertrauensbetrachtung. Im Assessment fällt das als Prozesslücke auf, nicht als Werkzeugfrage. Der geordnete Weg führt über ein versioniertes Regelwerk, Kennzeichnungspflicht und einen definierten Freigabepfad.

Unterscheidet ISO 26262 zwischen menschlich und maschinell erstellten Testfällen?

Nein. Die Norm formuliert Anforderungen an Arbeitsprodukte und Prozesse, etwa anforderungsbasiertes Testen, Methoden der Testfall-Ableitung und Traceability. Für das erzeugende Werkzeug gilt die Tool-Vertrauensbetrachtung nach ISO 26262-8, für den Testfall selbst gelten dieselben Prüf- und Nachweispflichten unabhängig von seiner Herkunft.