Automotive-Testen bezeichnet die Qualitätssicherung von Software und Hardware in Fahrzeugen unter strengen Normen wie Automotive SPICE, funktionaler Sicherheit und AUTOSAR. Vorgeschrieben sind Prozesse, Dokumente, Rollen und konkrete Testmethoden. Sicherheitskritische Systeme wie Airbag oder Scheibenwischer erfordern zwingend definierte Blackbox-Verfahren; höhere Risikoklassen machen Entwicklung und Zertifizierung deutlich teurer.
Das Wichtigste in Kürze
- Automotive-Testen ist durch Normen wie Automotive SPICE und die funktionale Sicherheit reguliert: Sie schreiben vor, welche Prozesse, Dokumente, Rollen und Testmethoden mindestens eingesetzt werden müssen.
- Steigt das Sicherheitsrisiko eines Systems um eine Stufe, wächst der gesamte Entwicklungsaufwand um Faktor zwei bis drei, was erklärt, warum zertifizierte Subsysteme kaum noch angetastet werden.
- Schon ein Scheibenwischer gilt im Automotive-Umfeld als sicherheitskritisches System und zwingt Teams zu vorgeschriebenen Blackbox-Methoden wie Äquivalenzklassen, Grenzwertanalyse und MCDC.
- Prüfstände mit echter Hardware laufen Tag und Nacht, damit möglichst nahe an hundert Prozent aller Testfälle automatisiert ablaufen, weil die schiere Variantenvielfalt individuell konfigurierter Fahrzeuge manuelles Testen ausschließt.
- Die Automotive-Tester-Zertifizierung setzt den ISTQB Foundation Level als Pflichtvoraussetzung voraus, inhaltlich behandelt sie aber überwiegend neue Themen wie Automotive SPICE, funktionale Sicherheit und Autosar.
Was Automotive-Testen von klassischem Softwaretest unterscheidet
Testen im Automobilbereich heißt, immer auch die Hardware mitzudenken. Selbst wer als reiner Softwaretester arbeitet, braucht Grundlagen über die Hardware und prüft zumindest in Teilen die Hardware-Kommunikation. Das ist der erste große Unterschied zum Test im Web- oder reinen Softwareumfeld.
Ein Auto ist groß, komplex und voller Software. Daran arbeiten viele Menschen, Firmen und Zulieferer parallel. Genau diese verteilte Entwicklung macht die Kommunikation schwierig und erklärt, warum die Branche so stark mit Normen und Standards arbeitet.
Für Tester bedeutet das viel Kontakt zu Unternehmen aus der ganzen Welt und einen hohen Lernfaktor. Der Preis dafür ist der Nachverfolgungsaufwand. Jede Aktivität muss belegbar sein.
Automotive-Testen ist ein stark reguliertes Umfeld
Die Standards regeln für Tester nahezu alles. Sie legen fest, welche Aktivitäten durchgeführt werden, welche Dokumente entstehen und welche Rollen wo beteiligt sein müssen.
Sobald funktionale Sicherheit im Spiel ist, gehen die Normen noch weiter. Funktionale Sicherheit beschreibt den Fall, dass ein Softwarefehler eine Person verletzen könnte. Für solche Systeme schreiben die Normen vor, welche Testmethoden mindestens anzuwenden sind.
Diese Vorgaben sind ausführlich und streng. In der Praxis tun Teams selten mehr als das, was die Normen verlangen, weil die Vorgaben den Umfang bereits weitgehend ausfüllen.
Kreativität beim Testen ist hier vorgeschrieben
Exploratives und intuitives Testen ist im Automotive-Umfeld kein Zusatz, sondern Pflicht. Tester sind verpflichtet, am Ende auch frei mit dem System zu arbeiten und es auszuprobieren.
Der Einstieg in den Testprozess sieht anders aus. Am Anfang stehen strenge Methoden über viele Teststufen, von Blackbox bis hin zu Coverage-Verfahren. Diese Grundlast ist vorgegeben.
Erst danach kommt der explorative Teil. Die Kombination aus festgelegter Methodik und vorgeschriebener Kreativität ist typisch für diese Branche.
Wie der Entwicklungs- und Testprozess aufgebaut ist
Über allem steht ein System-Lebenszyklus mit sechs Phasen. Am Anfang existiert weder Produkt noch Idee, am Ende existiert das Produkt nicht mehr. Dazwischen liegen Konzeption, Entwicklung samt Test, Produktion, Nutzung, Wartung und Außerbetriebnahme.
Tester arbeiten fast ausschließlich in der Entwicklungsphase. Dort kommt in der Regel ein V-Modell zum Einsatz, aber nicht das klassische Software-V mit vier Stufen. Im Automobil hat das V häufig sieben, neun oder mehr Stufen.
Diese Stufen brechen das System von oben nach unten herunter: von der Fahrzeugebene über die Innenelektronik zur Steuergeräteebene bis zur Software-Ebene. Je nach Position testet man kleine Softwarekomponenten, ganze Steuergeräte oder den Verbund auf eigens aufgebauten Prüfständen.
Auf der linken Seite des V muss immer jemand in der Testerrolle dabei sein. Das betrifft Reviews und statische Analyse. Diese Rolle ist verpflichtend Teil des Prozesses, auch wenn sie sich in der Praxis auf viele Personen verteilt.
Im Automobilbereich kannst du dir deinen Schwerpunkt aussuchen
Die Bandbreite der Tätigkeiten ist breit. Man kann ein Jahr lang ausschließlich am fast fertigen Fahrzeug testen, bei jeder neuen Steuergeräteversion die Testfälle anpassen und durchführen.
Wer näher an der Software arbeitet, übernimmt Unit-Tests, also Softwarekomponententests, dazu Integrations- und teilweise Systemtests. Häufig kommen Reviews hinzu.
So lässt sich eine Funktion von der kleinen Softwarekomponente bis fast zum fertigen Fahrzeug begleiten. Wie tief oder breit man arbeitet, hängt stark vom Unternehmen und vom Bereich ab.
Warum Agilität an der Hardware ihre Grenzen findet
Agile Methoden sind auch im Automotive angekommen. Für große Unternehmen ist SAFe als skaliertes Framework der gängige Ansatz, den die Branche durchzusetzen versucht.
Wo Software dominiert, funktioniert das gut. Serverlastige Bereiche mit viel Backend-Logik, bei denen die Software später remote auf das Fahrzeug geflasht wird, lassen sich weitgehend agil entwickeln. Viele Unternehmen sind damit zufrieden.
An der Hardware wird es schwierig. Bis aus einer Hardware-Entwicklung ein Prototyp entsteht, vergehen schnell acht bis zehn Wochen. Das passt schlecht zu sprintbasierten Ansätzen. Ein Ausweg ist, die Hardware-Entwicklung als eigenes Epic parallel herauszuziehen.
Auch die Dokumentenwelt lässt sich agil denken. Pflichtdokumente sind keine lästige Begleitlast, sondern Arbeitsprodukte, die einen Wert liefern und sich als Output in Scrum oder SAFe einordnen lassen. Der Wandel ist eingeleitet, aber nicht abgeschlossen.
Wie sicherheitskritische Systeme die Testmethoden bestimmen
Sobald ein System sicherheitskritisch ist, schreiben die Normen vor, was mindestens getestet werden muss. Viele dieser Systeme sind kritischer, als man zunächst vermutet.
Ein Scheibenwischer gilt bereits als Hochrisikosystem. Fällt er bei Regen aus, kann das gefährlich werden. Ein Airbag liegt noch deutlich höher in der Risikobewertung.
Für solche Systeme wird die Wirkkette analysiert und das System möglichst modular gestaltet, um Nebeneffekte zu begrenzen. Tabellen legen dann die Pflichtmethoden fest. Für den Scheibenwischer etwa Blackbox-Verfahren wie Äquivalenzklassen und Grenzwerte auf Software-Unit-Ebene sowie MC/DC, Modified Condition/Decision Coverage.
Wer diese Vorgaben missachtet und es kommt zum Schaden, haftet. In den Tabellen bleibt dennoch Spielraum: oft ist eine geeignete Kombination aus mehreren Methoden zu wählen.
Modellbasiertes Testen ist meist optional, aber im Kommen
Model-Based Testing ist in vielen Fällen empfohlen, aber nicht verpflichtend. Bei sicherheitskritischen Anwendungen wird der Ansatz häufig wieder herausgenommen.
Bei nicht sicherheitskritischen Themen ist die Methodenwahl freier, solange das Ergebnis als sicher genug gilt. Hier wächst das Interesse an modellbasierten Ansätzen.
Eingesetzt wird der Ansatz quer durch die Bereiche. Bei E-Fahrzeugen wird etwa das Energiesystem modelliert und daraus werden Testfälle automatisiert generiert. Am beliebtesten sind Aktivitätsdiagramme und Zustandsautomaten.
Am Anfang eines Projekts entscheidet ein Team aus Testmanagern und funktionalen Sicherheitsmanagern über die Methodenwahl. Diese Entscheidung wird dokumentiert.
Alles, was nicht dokumentiert ist, hat im Automobilumfeld nicht stattgefunden.
Christian Schwarzer
Neuentwicklung nutzt moderne Methoden, Bestand bleibt unangetastet
In der klassischen Verbrennerwelt steckt viel Altlast. Die Software ist oft älter, und nach dem Prinzip “never change a running system” wird zertifizierter, laufender Code kaum noch angefasst. Alte Dokumentation und alter Code werden mitgeschleppt.
Neuentwicklungen sehen anders aus. Bei Elektrofahrzeugen oder hochautonomem Fahren kommen die aktuellen Methoden zum Einsatz, und dort wird besonders viel modellbasiert gearbeitet.
Bestehende Systeme bekommen rückwirkend keine Modelle. Der Aufwand würde sich nicht lohnen, denn auch nachträglich erstellte Modelle müssten wieder geprüft werden, ohne echten Mehrwert.
Dahinter steht eine harte Kostenlogik. Steigt ein Subsystem eine Risikostufe nach oben, wird der gesamte Entwicklungsprozess grob um den Faktor zwei bis drei teurer. Ein Airbag liegt auf der höchsten Stufe, ASIL D. Solche Faktoren multiplizieren sich über die Stufen, weshalb funktionierende Systeme bewusst nicht mehr angefasst werden.
Warum Testautomatisierung im Automotive unverzichtbar ist
Die Variantenvielfalt erzwingt Automatisierung. Ein konfigurierter Neuwagen existiert mit seiner Kombination aus Scheinwerfern, Innenlichtern und Optionen oft nur ein einziges Mal weltweit.
Theoretisch müsste jede dieser Kombinationen getestet werden. Praktisch ist das unmöglich, deshalb wird massiv automatisiert. Auf Unit- und Code-Ebene ist das einfach umsetzbar.
Auf höheren Ebenen entstehen Prüfstände mit echter Hardware, die die spätere Umgebung eines Steuergeräts so genau wie möglich nachbilden. Auch hier ist das Ziel, nahezu alle Testfälle zu automatisieren. Bis zu 20 Prüfstände laufen Tag und Nacht, ergänzt um eingekaufte Server-Kapazität für die Software.
Manuell getestet wird vor allem ganz oben am Fahrzeug, etwa bei Fahrdynamik. Die Automatisierung nimmt den menschlichen Faktor aus Wiederholungen und Regressionstests heraus und macht die Arbeit zugleich abwechslungsreicher, weil der Fokus auf Automatisierung und neuen Features liegt.
Was die Zertifizierung zum Automotive Tester vermittelt
Der Kurs zum Automotive Tester dauert in der Regel zwei Tage und vermittelt die Begriffe und Normen, die Tester in der Branche brauchen. Er wurde unter Beteiligung des German Testing Board aufgelegt.
Im Zentrum stehen drei Standards. Automotive SPICE beschreibt die Prozesslandschaft: welche Dokumente entstehen, wer wo beteiligt ist, dazu die Test- und Review-Prozesse.
Der zweite Block ist funktionale Sicherheit, also der Umgang mit Systemen, bei denen ein Softwarefehler jemanden verletzen könnte, betrachtet aus der Testerperspektive. Der dritte Standard ist AUTOSAR, die Kommunikationsschicht im Fahrzeug. Man kann sie sich wie eine Lego-Platte vorstellen, auf der Softwareblöcke oben und Hardwareblöcke unten andocken und austauschbar bleiben.
Für die Prüfung ist der Foundation Level Pflicht. Inhaltlich sind die Themen aber überwiegend neu. Wer aus dem Testumfeld kommt und keine Zertifizierung anstrebt, kann den Kurs auch ohne Foundation Level besuchen. Für alle, die neu einsteigen, schafft der Foundation Level eine sinnvolle Grundlage an Methoden und Begriffen.
