Stefan Schmerler - Softwaretest in der Praxis

Abb. 1-3: Teufelsquadrat des Tests

Planung des zu inves-

tierenden Testaufwands

Auch Pol kommt in [2] zu der Erkenntnis: »Testen ist ökonomisch sinnvoll, solange die Kosten für das Finden und Beseitigen eines Fehlers im Test niedriger sind als die Kosten, die mit dem Auftreten eines Fehlers bei der Nutzung verbunden sind.« Der Testaufwand ist also immer in Abhängigkeit von dem mit dem Fehlerfall verbundenen Risiko zu sehen. Das wirtschaftliche Risiko wiederum ergibt sich als Produkt der potenziellen Schadenshöhe mit der Fehlereintrittswahrscheinlichkeit.

Bei sicherheitskritischen Sys-

temen gelten andere Regeln.

Anders verhält es sich, wenn noch weitere Faktoren eine Rolle spielen, z. B. Sicherheitsaspekte. Wenn Leib und Leben von Menschen auf dem Spiel stehen, sind a priori die größten sinnvoll darstellbaren Aufwände zu treiben. Hier macht der Gesetzgeber an vielen Stellen auch Vorgaben, z. B. in Form von ASIL (Automotive Safety Integrity Level)-Einstufungen in der Automobiltechnik. Sowie ein Hersteller Kenntnis über die Möglichkeit sicherheitskritischer Fehler erhält, ist er zum Rückruf verpflichtet. Dies ist bei Fahrzeugen einfacher durchführbar als bei gewöhnlichen Elektrogeräten – in jedem Fall aber mit hohen Kosten verbunden.

1.2.3 Frontloading

Interessant ist auch die Fehleranfälligkeit der einzelnen Entwicklungsphasen von Software (Abb. 1-4). Auch hier wurden statistische Erhebungen vorgenommen [3] mit durchaus interessantem Ergebnis.

Offensichtlich entstehen die meisten Fehler nicht, wie man sich vielleicht vorstellt, bei der klassischen Codeerstellung, sondern bereits in der Entwurfs- und Spezifikationsphase, also gleich zu Beginn des Projekts.

Abb. 1-4: Fehlerverteilung über die Softwareentwicklungsphasen

Besonders schwerwiegend ist hierbei, dass Fehler in der Spezifikationsphase oder gar im Lastenheft in den folgenden Absicherungsphasen, z. B. durch Funktionstests, nicht gefunden werden können, denn dieser Test erfolgt ja gerade gegen die Spezifikation!

Frontloading

Von großer Relevanz für die Fehlerbehebungskosten ist auch der Zeitpunkt im Entwicklungsprozess, zu dem ein Fehler gefunden wird (Abb. 1-5). Je früher dies gelingt, desto weniger kostenintensiv ist seine Beseitigung. Wenn ein Fehler erst sehr spät gefunden wird (im schlimmsten Fall erst am Ende des Lebenszyklus in der Wartung der Software), kann seine Behebung zweihundertmal so teuer sein, als wäre dies bereits in der Spezifikationsphase erfolgt.

Absicherungskapazitäten in

die frühen Phasen verlagern

Es ist also überaus sinnvoll, Absicherungskapazitäten bereits auf die frühen Entwicklungsphasen zu konzentrieren. Dieses Phänomen wird als Frontloading bezeichnet. Auf keinen Fall darf man also z. B. in der Spezifikationsphase die Qualitätssicherung außer Acht lassen. Fatalerweise ist allerdings oft genau dies zu beobachten. Eine Qualitätssicherung für Spezifikationen/Lastenhefteerfolgt oft allein dann, wenn sie Grundlagen für den Entwicklungsvertrag mit einem Zulieferer sind, wo nachträgliche Änderungen in der Regel kostenpflichtig sind.

Abb. 1-5: Frontloading und relative Fehlerbehebungskosten

1.2.4 Erfolgsfaktoren für den Test

In der Praxis haben sich einige Erfolgsfaktoren für Planung und Durchführung von Tests im Softwareentwicklungsprozess herausgebildet [2].

Tester so früh wie möglich in die

Entwicklung miteinbeziehen

Ganz wesentlich scheint die Beteiligung von Testern an der Prüfung von Anforderungen zu sein, z. B. durch Reviews. Letztlich erfolgt jeder Funktionstest auf Basis der und gegen die Spezifikation in Lastenheften. Spätestens hier fallen dem geübten Auge eines Testers nichttestbare oder lückenhafte Anforderungen auf. Frühzeitige Identifizierung und Behebung fehler- oder lückenhafter Anforderungen reduzieren das Risiko, dass falsche oder nichttestbare Funktionen entwickelt werden.

Auch die enge Zusammenarbeit von Systemdesignern und Testern in der Phase des Systementwurfs wirkt sich sehr vorteilhaft auf den Reifegradverlauf eines Softwareprojekts aus. Grundlegende Architekturfehler, die später kaum noch zu korrigieren sind, können so oft vermieden werden.

Arbeiten Entwickler und Tester in der Phase der Codeerstellung zusammen, hat das positive Auswirkungen auf das gegenseitige Verständnis und reduziert sowohl das Risiko von Defects im Quellcode als auch die Häufigkeit fehlerhafter Tests.

1.2.5 Die sieben Grundsätze des Softwaretests

Aus den Erfahrungen beim industriellen Softwaretest in den letzten Dekaden lassen sich wichtige Erkenntnisse ableiten, aber auch Trugschlüsse erkennen, was in die sieben Grundsätze des Softwaretests mündet:

Grundsatz 1: Testen zeigt (nur)

die Anwesenheit von Fehlern.

Die Durchführung von Tests reduziert die Wahrscheinlichkeit des Eintretens von Fehlerzuständen, weil diese dadurch frühzeitig erkannt und behoben werden können. Werden keine Fehlerzustände mehr identifiziert, bedeutet dies aber nicht die Fehlerfreiheit der Software. Testen kann nur die Anwesenheit von Fehlern zeigen, nie aber deren Abwesenheit!

Grundsatz 2: Es gibt keinen

erschöpfenden Test.

Ein vollständiger und alle Aspekte der zu testenden Software prüfender, erschöpfender Test ist außer bei trivialen Problemstellungen nicht möglich. Komplexität und Kombinatorik führen sehr schnell dazu, dass Testaufwand und Zeitbedarf in sehr unwirtschaftliche Regionen abdriften.

Grundsatz 3: Frontloading

spart Zeit und Geld.

Ein früher Testbeginn spart im Entwicklungsprojekt Zeit und Geld. Je früher ein Fehler identifiziert werden kann, desto schneller und kostengünstiger ist er zu beheben. Ein Fehler, der erst beim Kunden in Erscheinung tritt, kann ganz erhebliche Aufwände nach sich ziehen bis hin zum Rückruf des Produkts, sollte es sich um sicherheitskritische Mängel handeln.

Grundsatz 4: Fehler treten

in Clustern auf.

Es hat sich als durchgehendes Muster gezeigt, dass Fehler gehäuft auftreten (»wo einer ist, sind viele«). Aus bestimmten funktionalen, formalen oder projektspezifischen Gründen ist die Fehlerneigung nicht über den gesamten Quellcode gleich verteilt. Bei einer Aktualisierung der Ressourcenplanung ist es also sinnvoll, die bislang auffällig gewordenen Teilsysteme in ihrer Priorität heraufzustufen – dies ist auf jeden Fall ein besserer Ansatz als die »Gießkanne«.

Grundsatz 5: Auch Tests altern!

Die repetitive Durchführung immer derselben Testsuites stiftet auch beim Regressionstest immer weniger Nutzen. Mit denselben Tests werden natürlich dieselben Fehler gefunden, aber eben auch nur die. Die Tests verlieren sozusagen im Laufe der Zeit ihre Wirksamkeit. Mit Fortschreiten der Entwicklung ist es deshalb unerlässlich, den Testbestand zu überarbeiten und auf diese Weise bislang auch unberücksichtigte Codeanteile beim Test abzudecken.

Grundsatz 6: Einsatzgebiete

sind zu beachten.

Bei Testplanung und Testkonzept ist unbedingt auf die Berücksichtigung des späteren Einsatzgebiets der Software zu achten. Eine Bürosoftware ist anders zu testen als ein eingebettetes System. Dies kann bis zur Definition typischer Anwendungsfälle gehen, sog. operationaler Profile.