Basiswissen Automotive Softwaretest. Ralf Bongard

       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ä¹nde 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 Development² 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 Fehlhandlungen³ 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