Test-Ingenieure und AI in SWE.4 bis SWE.6 | sensified

Test-Ingenieure und AI (SWE.4–6): Test-Design bleibt, Testlogistik geht

Fehlerhypothesen, Abdeckungs-Entscheidungen und die Beurteilung der Ergebnisse bleiben Kern der Test-Rollen. Maschinell werden zerlegte Ausführungsanteile: Harness-Boilerplate, Testfall-Implementierung, Lauf-Ausführung, Reporting und Trace-Pflege. sensified beschreibt diese Trennung in drei Rollenkarten für SWE.4 bis SWE.6, die im Audit gegen die Realität des jeweiligen Projekts geprüft werden.

In den Verifikationsprozessen von Automotive SPICE (ASPICE), also SWE.4 Software Unit Verification, SWE.5 Component and Integration Verification und SWE.6 Software Verification, liegt ein hoher Anteil formal beschreibbarer, wiederholbarer Arbeit. Genau deshalb sind sie das Lieblingsziel jeder Automatisierungs-Diskussion, und genau deshalb lohnt sich hier Präzision: Wer pauschal von Testautomatisierung spricht, vermischt anspruchsvolle Entscheidungsarbeit mit Logistik. Dieser Beitrag zerlegt die drei Test-Rollen entlang unserer Rollenkarten; das zugrunde liegende Modell erläutert der Grundlagen-Beitrag zum Wertbeitrags-Prinzip im Automotive Software Engineering. Auch hier gilt: Die Karten beschreiben typisierte Rollen und Tätigkeits-Anteile als Hypothesen-Startpunkt, der beim Kunden validiert wird. Sie bewerten keine Personen.

Die Zerlegung: Test-Design, Implementierung, Durchführung, Dokumentation

Der Schlüssel zu den Test-Rollen ist eine Zerlegung in vier Anteile, die sensified in jeder der drei Karten konsequent durchhält. Das Test-Design umfasst Techniken, Äquivalenzklassen und Grenzwerte, Fehlerhypothesen, Pass-Fail-Kriterien und Abdeckungsziele; es ist Entscheidungsarbeit der Klasse K2 und in Safety-Kontexten selbst sicherheitsrelevant. Die Implementierung setzt das Design in Testcode und Harness um. Die Durchführung startet Läufe und zeichnet Ergebnisse auf. Die Dokumentation konsolidiert Ergebnisse, Coverage-Reports und Trace-Links.

Nur der erste Anteil ist durchgängig Kern. Implementierung, technische Lauf-Ausführung und Dokumentations-Logistik sind nach der Zerlegung überwiegend regelgebundene K4-Anteile, und auf genau diesen mechanischen Anteilen ist die Evidenzlage für AI-Unterstützung am stärksten. Die Verantwortung für die Durchführung bleibt dabei ungeteilt in der Rolle: Wer entscheidet, welcher Umfang läuft und wie mit Auffälligkeiten umgegangen wird, trägt weiterhin das Ergebnis.

Normative Pflicht bestimmt nicht die K-Klasse

Ein Review-Befund aus der Entwicklung unseres Vorgehensmodells ist für die Test-Rollen zentral: Dass eine Tätigkeit als Base Practice gefordert ist, macht sie nicht automatisch zu Urteils-Arbeit. Beispiel SWE.4.BP3, die Durchführung der Unit-Verifikation: Die Ausführungs- und Ergebnisverantwortung, also die Entscheidung, dass und wie verifiziert wird, und die Beurteilung der Ergebnisse, ist K2- und K3-Kern. Die technische Ausführung der Maßnahmen-Läufe und die Ergebnis-Aufzeichnung sind regelgebundener K4-Anteil, der heute schon weitgehend werkzeuggestützt läuft, mit Testrunnern und Coverage-Tools. Dasselbe gilt für SWE.5.BP4 und BP5 sowie SWE.6.BP3. Zerlegt und gegebenenfalls automatisiert wird nur der Ausführungsanteil, die Verantwortung bleibt ungeteilt.

Kern und Overload je Rolle: SWE.4, SWE.5, SWE.6

Die drei Karten unterscheiden sich in ihren Schwerpunkten: SWE.4 lebt vom Unit-Kontext, SWE.5 von Schnittstellen- und Interaktions-Wissen, SWE.6 vom Anforderungs-Bezug gegenüber dem Auftraggeber. sensified fasst die wichtigsten Anteile je Rolle in einer Kern-Overload-Tabelle zusammen, wobei jede Zeile beim Kunden als Hypothese geprüft wird und erst das Audit die tatsächlichen Anteile zeigt:

Zwei Punkte verdienen einen zweiten Blick. Erstens die Umgebungsarbeit in SWE.5: Das Design der Prüfumgebung, etwa der Topologie von Hardware-in-the-Loop-Prüfständen (HIL) und der Restbus-Strategie, ist in Safety-Kontexten selbst Engineering-Arbeit und bleibt K2. Provisionierung nach bestehender, versionierter Definition ist dagegen K4. Zweitens die Konsolidierungsstelle SWE.6: Hier laufen die Ergebnisse aller Verifikationsebenen zusammen und werden zur Release-Evidenz verdichtet; die Testfall-Auswahl nach Release-Scope ist hochwertige K2-Arbeit, ihre Vor- und Nachbereitung ist regelbasiert.

Was AI je Triage-Klasse übernimmt

Unsere Triage kennt vier Klassen: A1 für regelgebundene Hintergrund-Automatisierung, A2 für vorbereitende Automatisierung mit Einzelfall-Prüfung, B für rein lesende Sichten und C für autonome Fallabwicklung, die grundsätzlich als Prüfkandidat mit Status nicht zulässig startet. sensified ordnet die Test-Bausteine so ein, dass der Commit-Punkt in den führenden Systemen beim Menschen bleibt; die Abgrenzung im Detail erklärt der Beitrag zu den AI-Triage-Klassen im Engineering.

A1: Provisionierung, Pipelines, deterministische Läufe

Regelgebunden und damit A1-Kandidaten sind die Umgebungs-Provisionierung als Code, also SIL-Container und HIL-Konfigurationen aus versionierten Definitionen, während das Umgebungs-Design beim Ingenieur bleibt; der baseline-getriebene Stand-Zusammenbau nach Integrationssequenz; die Messdaten-Pipeline von der Aufzeichnung über die Konvertierung bis zur baseline-bezogenen Ablage; die Coverage- und Ergebnis-Reporting-Pipeline; die Kampagnen-Orchestrierung nach versioniertem Regelwerk; und die deterministische Durchführung eines menschlich festgelegten Regressions-Umfangs samt vollständigem Protokoll. Jeder dieser Bausteine braucht dokumentierte Rückholwege und Protokollierung, damit die Evidenzkette assessierbar bleibt.

A2: Testfall-Entwürfe mit Prüfpunkt, C bleibt Prüfkandidat

Vorbereitende Automatisierung mit Einzelfall-Prüfung sind die Testfall- und Harness-Entwürfe: aus dem Detaildesign abgeleitete Entwürfe für Unit-Tests, bei denen Wertebereiche zu Äquivalenzklassen und Grenzwerten werden, sowie Testfall-Entwürfe aus Anforderungen für SWE.6. Der Ingenieur prüft, ergänzt und verantwortet jeden Entwurf; die Test-Design-Verantwortung und die Auswahl bleiben K2 beim Menschen. Voraussetzung ist maschinenlesbare Eingangsqualität, beim Unit-Test also ein Detaildesign mit sauberen Wertebereichen und Einheiten. Auch die Vorklassifikation von Umgebungs- gegenüber Prüflingsfehlern nach bekannten Signaturen läuft als A2, die Erst-Diagnose unbekannter Fälle bleibt K2.

Eine ehrliche Grenze gehört dazu: Das Regressions-Auswahl-Urteil, also eine lernende Selektion mit Interpretationsspielraum ohne Einzelfall-Prüfung, ist in unseren Karten ein C-Prüfkandidat mit Status nicht zulässig. Der Weg dorthin führt über einen A2-Piloten, dessen Messung insbesondere den Recall kritischer Regressionen gegen eine menschliche Referenz-Selektion belegen muss. Bis dieser Nachweis vorliegt, bleibt die Auswahl beim Menschen. „Was die Evidenz trägt, ist vorbereitende Generierung mit Prüfung. Was sie nicht trägt, ist das autonome Test-Urteil.“

Warum das für Traceability und Assessment zählt

Die Test-Rollen sind in der Sicht von sensified die Hauptlieferanten der Verifikations-Evidenz: Trace-Matrizen von der Anforderung über die Maßnahme bis zum Ergebnis, Coverage-Nachweise, Release-Reports. Wie schwer dieser Nachweis in der Breite fällt, zeigt eine Selbstauskunfts-Zahl: 46 % der Automotive-Teams fällt der ISO-26262-Nachweis schwer (Quelle: Perforce, 2025).

Bei der maschinellen Zusammenstellung gilt eine harte Grenze: Aggregation und Export bereits menschlich verantworteter Zuordnungen sind A1-fähig; jede semantische Neu-Zuordnung ist ausgeschlossen, fehlende oder strittige Links werden als Befundliste an den Menschen gegeben, nie automatisch ergänzt. Warum die Compliance-Arbeit als Ganzes nicht wegautomatisiert wird, sondern leichter wird, vertieft der Beitrag K3 wird nicht wegautomatisiert.

Nächste Schritte

Welche dieser Anteile in Ihren Test-Teams tatsächlich Aufwand binden, wie Ihre Toolchain die Bausteine trägt und was zuerst kommt, klärt sich am realen Projekt. Der Einstieg ist ein strukturiertes Audit entlang der Wertströme und Rollenkarten.

1. Grundlagen lesen: Das Wertbeitrags-Prinzip im Automotive Software Engineering erklärt Tätigkeitsklassen, Wertströme und Triage im Zusammenhang.
2. Audit prüfen: Das Wertbeitrags-Audit für Automotive Software Engineering beschreibt Ablauf, Ergebnisse und Compliance-Leitplanken des Einstiegs.
3. Gespräch vereinbaren: In einem Qualifying-Call klären wir, ob Scope und Ausgangslage Ihres Projekts zum Vorgehen passen.

Häufige Fragen

Die folgenden Antworten fassen die Position von sensified zu den Test-Rollen in SWE.4 bis SWE.6 zusammen. Sie beziehen sich auf typisierte Rollenkarten und Tätigkeits-Anteile; wie die Anteile in einem konkreten Projekt tatsächlich liegen, wird im Audit beim Kunden validiert.

Kann AI Testfälle für Automotive-Software generieren?

Als Entwurf ja, als verantwortetes Ergebnis nein. In unserer Triage sind Testfall- und Harness-Entwürfe A2-Bausteine: Das System erzeugt Entwürfe aus Detaildesign oder Anforderungen, der Ingenieur prüft, ergänzt und verantwortet jeden einzelnen. Voraussetzung ist maschinenlesbare Eingangsqualität; das Test-Design mit Fehlerhypothesen und Abdeckungszielen bleibt Entscheidungsarbeit des Menschen.

Was bleibt beim Test-Ingenieur, wenn Läufe und Reports automatisiert sind?

Die anspruchsvolle Hälfte der Arbeit: Fehlerhypothesen bilden, Äquivalenzklassen und Grenzwerte festlegen, Abdeckungsziele entscheiden, Maßnahmen nach Release-Scope selektieren, Ergebnisse beurteilen und Abweichungen bewerten. Diese K2- und K3-Anteile sind in Safety-Kontexten selbst sicherheitsrelevant. Automatisiert werden Boilerplate, Lauf-Ausführung, Reporting und Trace-Logistik.

Ist die Testdurchführung nicht ohnehin normativ Pflicht?

Ja, und trotzdem wird sie zerlegt. Dass SWE.4.BP3 die Durchführung fordert, macht sie nicht zu Urteils-Arbeit: Die Ausführungs- und Ergebnisverantwortung ist Kern, die technische Lauf-Ausführung und die Aufzeichnung sind regelgebundene Anteile, die heute schon werkzeuggestützt laufen. Die normative Pflicht bestimmt den Anlass, die Zerlegung bestimmt die Klasse.

Darf AI den Regressions-Umfang selbst auswählen?

In unserem Modell derzeit nicht. Eine lernende Auswahl mit Interpretationsspielraum ohne Einzelfall-Prüfung ist ein C-Prüfkandidat mit Status nicht zulässig. Der Hochstufungspfad läuft über einen A2-Piloten mit Messung, insbesondere des Recalls kritischer Regressionen gegen eine menschliche Referenz-Selektion. Die deterministische Durchführung eines festgelegten Umfangs ist dagegen als A1 zulässig.

Was ist mit HIL-Umgebungen, lässt sich dort automatisieren?

Teilweise, mit klarer Grenze. Die Provisionierung nach bestehender, versionierter Definition, der Stand-Zusammenbau und die Messdaten-Pipeline sind regelgebundene A1-Kandidaten. Das Design der Prüfumgebung, also HIL-Topologie und Restbus-Strategie, bleibt Engineering-Arbeit der Klasse K2. Die HIL-Spezifika begrenzen zugleich die Generierbarkeit von Testcode, ein ehrlicher Dämpfer gegen Vollautomatisierungs-Erwartungen.

Werden mit den Rollenkarten Test-Teams oder Personen bewertet?

Nein. Die Karten beschreiben typisierte Rollen und Tätigkeits-Anteile, keine Personen und keine Teams. Sie sind Hypothesen-Startpunkte, die im Audit gegen die Kundenrealität geprüft werden. Kennzahlen erhebt unser Vorgehen ausschließlich auf Prozess- und Wertstrom-Ebene, etwa Durchlaufzeiten oder Abdeckungs-Quoten je Release, niemals auf Personen-Ebene.

Dieser Beitrag nimmt die Rollen-Perspektive ein. Den konkreten Tooling-Pfad von der Anforderung zur ausführbaren Robot-Framework-Suite zeigt der Beitrag Von der Anforderung zum Robot-Framework-Test.

Wie dieser Baustein in eine beherrschte Gesamt-Capability passt, zeigt unsere Seite zur AI-Transformation im Automotive-Engineering. Den strategischen Rahmen erklärt der Beitrag AI im Engineering ist ein Capability-Thema, kein Tool-Thema.