Basiswissen Automotive Softwaretest (eBook)

2Grundlagen

Auch der Automotive Softwaretester (im Weiteren als Tester bezeichnet) ist ein Softwaretester. Für ihn gelten die gleichen Grundsätze, Prozesse und Verfahren. Er bewegt sich jedoch im automotive-spezifischen Kontext. So sind die Grundlagen des Testens, die im Rahmen der Ausbildung zum ISTQB® Certified Tester – Foundation Level (CTFL) [ISTQB 2018] vermittelt werden, auch hier anwendbar.

Hierzu gehören neben den Grundsätzen des Testens (Abschnitt 2.1) auch der Testprozess (Abschnitt 2.2) im Kontext des Systemlebenszyklus (Abschnitt 2.3). Darüber hinaus gilt es, die drei Dimensionen des Testens (Abschnitt 2.4) mit Teststufen, Testarten und Testverfahren im Kontext der Softwareentwicklung in der Automobilindustrie zu betrachten.

2.1Grundsätze des Testens

Im CTFL sind die sieben Grundsätze des Testens beschrieben, die jedem Tester als Leitlinien in seiner täglichen Arbeit dienen [ISTQB 2018]:

Grundsatz 1:
Testen zeigt die Anwesenheit von Fehlerzuständen, nicht deren Abwesenheit

In der Praxis wird der Tester oft mit der Anforderung konfrontiert, eine Funktionsfreigabe(empfehlung) (siehe Abschnitt 2.3) oder Funktionsbestätigung zu liefern. Dabei muss klar sein: Der Tester kann nur das Risiko unerkannter Fehlerzustä1nde reduzieren und einschätzen. Er kann die Fehlerfreiheit einer Funktion niemals nachweisen!

Grundsatz 2:
Vollständiges Testen ist nicht möglich

Um Marktanteile zu gewinnen und Kundenwünsche zu erfüllen, bieten die Fahrzeughersteller eine wachsende Anzahl an Modellvarianten, Konfigurationen und Features an. Im Jahr 2017 hat VW »fast 84.000 Golf in Deutschland verkauft. Davon hatten mehr als 58.000 unterschiedliche Konfigurationen. Gerade einmal 400 Golf waren identisch – von den unterschiedlichen Farben ganz abgesehen. Das heißt: Wir (VW) bauen Unikate« [Doll 2018, S. 15]. Und so wie VW geht es auch anderen Fahrzeugherstellern, die ihren Kunden eine umfangreiche Individualisierung der Fahrzeuge anbieten.

Die große Konfigurationsvielfalt führt unweigerlich zu einer hohen Komplexität, was das Risiko möglicher Fehlerzustände erhöht. Außerdem führt sie zu einer Explosion der Testaufwände, was hohe Kosten mit sich bringt. Selbst wenn ein vollständiger Test möglich wäre, die vollständig getesteten Unikate wären wegen der hohen Testkosten unbezahlbar. Wenn in Konsequenz ein vollständiges Testen weder sinnvoll noch möglich ist, kann Testen nur stichprobenhaft erfolgen. Bei der Auswahl geeigneter Stichproben können dem Tester sowohl Normen und Standards (siehe Kap. 3) als auch Testansätze und Testverfahren (siehe Kap. 5) helfen.

Grundsatz 3:
Frühes Testen spart Zeit und Geld

Je später der Tester einen Fehlerzustand aufdeckt, desto teurer ist die Korrektur des Fehlerzustands. Zu den Gestaltungsprinzipen des Lean Development2 gehört auch das Frontloading. Es basiert auf dem Ansatz, hohe Kosten durch spät entdeckte Mängel und Änderungen so weit wie möglich zu vermeiden. Für das frühe Finden von Fehlern spielen der statische Test (siehe Abschnitt 5.2) und der (Software-)Komponententest eine wichtige Rolle.

Darüber hinaus stellt das Testen von eingebetteten Systemen (Embedded Systems) den Tester vor große Herausforderungen. Da eingebettete Fahrzeugsysteme in den technischen Kontext des Fahrzeugs eingebunden sind, lässt sich das Verhalten der Software häufig auch nur im Fahrzeugkontext bewerten. Allerdings ist das Testen unter realen Bedingungen (d.h. auf der Zielhardware und in der realen Umgebung) häufig sehr zeit- und kostenintensiv. Frühes Testen spart auch hier Zeit und Geld, bedingt jedoch den Einsatz virtueller Testumgebungen, die den Kontext simulieren, in den die Systeme eingebettet sind (siehe Kap. 4).

Grundsatz 4:
Häufung von Fehlerzuständen

In der Praxis hat sich gezeigt, dass Fehlerzustände nicht gleichmäßig (im Sinne einer gleichen Fehlerdichte) über alle Testobjekte verteilt sind. Die Ursache hierfür liegt darin, dass während der Entwicklung Fehlerzustände durch Fehlhandlungen3 entstehen. Treiber von Fehlhandlungen sind Zeitdruck, hohe Komplexität, hoher Innovationsgrad des Testobjekts und mangelnde Qualifikation der Mitarbeiter.

Eine gleichmäßige Verteilung der Testressourcen hat den Nachteil, dass kritische Bereiche möglicherweise nicht ausreichend und unkritische Bereiche zu ausführlich getestet werden. Beides reduziert die Effizienz des Testens (Mehrwert des Testens bezogen auf den Aufwand für das Testen). Hier ermöglicht ein risikobasierter Testansatz (siehe Abschnitt 5.1.3) ein effizientes Testen. Bei diesem Ansatz ist die Verteilung der Testaufwände abhängig vom Risiko einer Fehlerhäufung (Produktrisiko) oder dem Risiko von Fehlhandlungen (Projektrisiko).

Grundsatz 5:
Vorsicht vor dem Pestizid-Paradoxon

Häufig trifft man in der Softwareentwicklung der Automobilindustrie die Regressionsteststrategie an, dass der Tester alle oder zumindest immer die gleichen Regressionstests durchführt. Dabei kann es zu dem vermeintlich positiven Effekt einer abnehmenden Anzahl von Regressionsfehlern kommen. Vermeintlich positiv, da die daraus abgeleitete Annahme eines zunehmend reiferen Produkts falsch sein kann. Denn auch das Pestizid-Paradoxon kann zu einer abnehmenden Anzahl von Regressionsfehlern führen. Ähnlich wie bei Schädlingen, die durch intensiven Einsatz von Pestiziden eine Resistenz gegen diese entwickeln können, können auch Testobjekte eine Resistenz gegen ständig wiederkehrende Regressionstests entwickeln. Tatsächlich können diese Bereiche von höherer Qualität sein. Da vollständiges Testen wiederum nicht möglich ist, lässt sich die Annahme einer höheren Qualität nicht automatisch auf alle Bereiche übertragen.

Die Auswahl der stichprobenhaften Regressionstests erfolgt auf Basis einer Regressionsteststrategie. Leider passen sich die Entwickler im Laufe der Zeit ebenso an diese Strategie an. So wie sich der Schädling an das Pestizid anpasst. Aus diesem Grund sollte eine Regressionsteststrategie immer variable Anteile enthalten. Beispielsweise durch wechselnde Schwerpunkte im Test oder den Einsatz erfahrungsbasierter Tests.

Grundsatz 6:
Testen ist kontextabhängig

Es gibt nicht die Teststrategie und die Testvorgehensweise. Testen ist an den Entwicklungskontext anzupassen. Hierzu gehören vor allem das verwendete Entwicklungsmodell, die Branche und die eingesetzte Technologie.

Entwicklungsmodell

Testen ist abhängig vom eingesetzten Entwicklungsmodell. So findet beispielsweise das Testen im Rahmen von sequenziellen Entwicklungsmodellen (wie dem V-Modell) innerhalb abgeschlossener Testphasen statt. Im Rahmen von iterativ/inkrementellen Entwicklungsmodellen (wie Prototyping oder Scrum) ist das Testen hingegen eine kontinuierliche und begleitende Aktivität.

Die Entwicklung eines Fahrzeugs verläuft typischerweise entlang der sequenziellen Phasen des Produktentstehungsprozesses (siehe Abschnitt 2.3). Um die hohe Komplexität und die Größe des Entwicklungsumfangs beherrschen zu können, lagern Fahrzeughersteller (im Weiteren als Hersteller bezeichnet) Teile der Entwicklung an Zulieferer aus. In der so entstehenden Zulieferkette steht der Hersteller an der Spitze, gefolgt von einer Kette von Zulieferern.

Branche

Das Testen ist auf die Branche bzw. die Art des zu testenden Produkts anzupassen. So muss beispielsweise der Bestellvorgang in einem Webshop auch für einen Laien möglich sein. Im Falle einer Fehlfunktion geht zumeist der Umsatz verloren. Im schlimmsten Fall kann die Fehlfunktion das Image des Betreibers schädigen. Wichtige Testziele sind also die Bewertung der Funktionalität (Geschäftszweck) und der Gebrauchstauglichkeit. Für die Nutzung der Bremsen in einem Fahrzeug darf hingegen ein Führerschein vorausgesetzt werden. Allerdings kann hier eine Fehlfunktion tödliche Folgen haben. Wichtiges Testziel ist hier zwar auch die Bewertung der Funktionalität (Geschäftszweck), allerdings bekommt die Bewertung der Zuverlässigkeit einen deutlich höheren Stellenwert.

Technologie

Die Software klassischer IT-Systeme läuft meistens auf kommerzieller Standardhardware (wie PC, Workstation, Server). Hierzu liefern die Hersteller der Hardware auch die notwendigen Treiber. Die...