Mythos Software Test im Automobil

Der größte Mythos beim Software-Testen ist, dass man ALLES testet. Der Tester meint damit, er lässt alle definierten Tests durchlaufen und der Manager meint, dass alle möglichen Fehler gefunden werden. Damit man hier Konsens findet, hat man versucht zu bestimmen, was ALLES nun wirklich ist und da als technischer Input i.d.R. nur die Anforderungen oder das Design zur Verfügung stehen, wird hieraus abgeleitet, dass man z.B. alle Anforderung abtestet. Also wenn man alle Anforderung abtestet, hat man zumindest ein Mindestmaß an Tests geleistet - so scheint es.

Die Anforderungen

Man kann zwei Arten von Lastenheften unterscheiden. Sogenannte Querschnittslastenhefte bzw. Firmenstandards und dann die produktbezogenen Lastenhefte. Zu den Querschnittslastenhefte gibt es häufig auch schon Testspezifikation hinzu bzw. der Kunde selbst hat Testgewerke, die die Kompatibilität zu den allgemeinen Anforderung abprüft. Bei den produktbezogenen Lastenhefte kann man nicht-funktionale, funktionale sowie diagnostische Anforderungen unterscheiden. Testbar sind i.d.R. nur die beiden Letzteren.

Beispiel

Als einfaches Beispiel soll das Abblendlicht des Fahrzeuges dienen. Anforderung 1: Das Abblendlicht wird nur bei Kl.15 (Zündung ein) und bei der Lichtschalterstellung „2“ eingeschaltet. Der Testfall, der nun den Ausgang Abblendlicht überprüft direkt nach dem man Kl.15 ein und den Lichtschalter aus „2“ gestellt hat, liefert ein „FAILED“, weil es eine kleine Verzögerung gibt, die nicht spezifiziert war. Wenn man Glück hat, bekommt man ein Update der Anforderung, wenn nicht führt man eine beliebige Verzögerung ein, die aber nirgends spezifiziert ist. Das Problem ist, dass vielen Anforderungen sowohl die zeitliche Bereich als auch der Wertebereich unzureichend spezifiziert ist, aber ein Testfall immer genau die Zeit als auch den Wert exakt überprüfen muss und hier „gut“ oder „schlecht“ erteilen muss. Damit sind Testfälle deutlich genauer bzw. inkorrekter als die Anforderungen. Das Update der Anforderung könnte so aussehen: Das Abblendlicht wird spätestens nach 50ms bei Kl.15 (Zündung ein) und bei der Lichtschalterstellung „2“ eingeschaltet. Gut, der Testfall wartet nun nach dem Einschalten der Zündung und des Lichtschalters 50ms und kontrolliert dann, ob das Abblendlicht an ist. Test erledigt und Anforderung abgedeckt - wirklich? Wir würden kein Flackern des Lichts entdecken. Ein einzelner Peak bei 50ms würde genügen, um den Testfall als „PASSED“ zu markieren. Ah ha, negativ testen ist angesagt. Also anstatt zu überprüfen, das Licht ist an, überprüft man, dass es nach 50ms nicht aus ist. Bei einfachen binären Signalen ist es noch besser nur nach Flanken zu testen (es darf nur ein Flanke von aus auf ein geben, die spätestens 50 ms nach einer Flanke vom Lichtschalter 2 kommt). Dies einfache Beispiel veranschaulicht, dass eine einfache Anforderungen, welche auch recht einfach implementiert werden kann, beim Testen schon eine gewissen Komplexität erreicht. Wenn man diese Komplexität scheut und eher zu einem einfachen Testfall neigt, ihn auch gleich weglassen sollte, da er nur dazu dient, einen „grünen“ Testfall zu einer Anforderung zu generieren, um damit die Anforderung als „getestet“ zu markieren.

Der andere Weg

Gute Tests, die wirklich Fehler finden, sind erfahrungsbasiert bzw. risikobasierend und nicht anforderungsbasiert. Der Prozess, wie man zu Testfällen kommt, unterscheidet sich. Anstatt zu jeder testbaren Anforderung ein Test zu schreiben, sollte man gemeinsam mit der Entwicklung alle Anforderungen durchsprechen und festlegen, welche Teile der Implementierung große Risiken bergen und was man besonders beobachtet werden sollte. Daraus ergeben sich die Testfälle, die auch die Entwickler brauchen, um ihre Implementierung zu überprüfen. Das Ziel des Tests sollte sein, jenseits der Anforderungen zu schauen, ob die Implementierung robust genug ist, das Ziel zu erreichen. Das bedeutet, dass man immer ein gewisses Repertoire an Stressfaktoren entwickelt, welche zu der zu testenden Funktion hinzugeschaltet werden können bzw. die Funktion selbst immer wieder jenseits der Grenzen vermisst, die funktionieren müssen. Das bedeutet, dass im Gegensatz zum herkömmlich Testansatz, das Testen gemeinsam mit der Entwicklung betrieben wird und nicht unabhängig von einander. Das Ziel des Testen ist es, die Schwächen der Implementierung festzustellen und somit diese zu stärken. Das bedeutet auch, dass die Tests nicht nachgelagert durchgeführt werden, sondern kontinuierlich und damit natürlich so automatisiert wie möglich. Jeder Fehler, welche in einer Auslieferung an den Kunden entdeckt wird, wird als Möglichkeit betrachtet, die Tests weiter auszudehnen. Einerseits, um den Nachweis zu erbringen, dass der Fehler gefixt wurde und andererseits auch, dass es in der Umgebung des Fehlers nicht weitere Fehler implementiert wurden.

Zusammenfassung

Der Weg zu einer möglichst fehlerfreien Software geht nur über intensives Testen, welches hilft die Risiken des Projektes zu minimieren. Testen über Anforderungen hat zwar projekttechnische Vorteile (einfach zu messen und zu verfolgen), findet aber nur bedingt viele Fehler.