Systematische Softwareentwicklung

8Test

8.1Warum testen?

"Man muss immer das Beste hoffen, das Schlimme kommt von alleine."
(Deutsches Sprichwort)

"Kein Produkt menschlicher Intelligenz kommt fehlerfrei zur Welt. Wir formulieren Sätze um, trennen Nähte wieder auf, setzen Pflanzen um, planen Häuser neu und reparieren Brücken. Warum sollte es uns mit Software anders gehen?" [B4] Bei der Softwareentwicklung nach dem oben genannten Sprichwort zu verfahren, wäre also töricht. Denn wenn Sie wissen, dass Software Fehler hat, diese aber nicht suchen und erst recht nicht beheben, dann werden Sie nie zuverlässig bestimmen können, wann Ihr Projekt zuende und Ihr Produkt fertig sein wird.

Wir sollten also zunächst akzeptieren, dass Software per Definition fehlerhaft ist. Wie wir später noch sehen werden, ist im Qualitätsmanagement ein Fehler als die Nichterfüllung einer Anforderung definiert und stellt damit einen Mangel im Produkt dar, der in aller Regel ausgebessert werden muss. Wir sind schließlich nicht nur verantwortlich für das, was wir tun, sondern auch für das, was wir nicht tun! Daher sollten Fehler nach bestem Wissen und Gewissen gesucht, gefunden und behoben werden, bevor der Kunde das Produkt erhält. Nur mit dieser Einstellung kann beim Kunden ein hohes Maß an Zufriedenheit sichergestellt werden - und nur ein zufriedener Kunde ist ein guter Kunde! Also muss getestet werden, denn "Testen" ist der Prozess zur Prüfung der Erfüllung/Nichterfüllung der Anforderungen.

Natürlich muss militärische Software, die in Serienherstellung Verwendung finden soll, gründlicher getestet werden, als eine Verwaltungssoftware, die individuell für einen einzelnen Kunden erstellt wird. Aber man sollte darüber mit dem Kunden reden, bevor der Aufwand für das Projekt geschätzt wird - nicht, dass der Kunde später auf einmal eine ganz andere Einstellung zum Testen hat, als man zuvor angesetzt hat. Und selbst wenn der Kunde auf Tests verzichten will und nur die Fehler beheben will, die nach der Einführung im Betrieb hochpoppen, sollte man die Software nicht ohne Testprozesse in den Iterationen erstellen, denn ein nicht behobener Fehler in einer Iterationsstufe kann drei neue in der nächsten Iterationsstufe nach sich ziehen. Dann zahlt man als Entwickler die Strafe dafür, dass der Kunde kein Geld fürs Testen ausgeben will. Außerdem sollte man die Fehler möglichst finden, solange die Quellen noch "frisch" sind, denn auch mit phantastischer Dokumentation kann es später evtl. schwierig werden, sich wieder in die Quellen einzuarbeiten. Ungetestete Software wird - wie ungetestete Produkte in anderen Branchen auch - gerne als "Banana Products" bezeichnet: dies sind Produkte, die frühzeitig ihren Produktionsort verlassen und erst beim Kunden ausreifen - halt wie Bananen.

Einsatz- oder sicherheitskritische Software (z.B. militärische oder medizinische Software) muss ggf. schon bei der ersten Inbetriebnahme fehlerfrei funktionieren. Dazu muss das Softwaresystem formal spezifiziert werden und verlangt eine mathematische Kontrollmöglichkeit. Hier kann man spezielle Spezifikationssprachen verwenden, die im Gegensatz zur menschlichen Sprache streng logisch aufgebaut sind. Dadurch können die Spezifikationen dann teilweise sogar automatisch verarbeitet werden. Da der Anwender in aller Regel eine solche Sprache nicht verstehen wird, muss diese formale Spezifikation immer zusätzlich zur normalen Spezifikation erstellt werden und dient damit im Wesentlichen zum mathematischen Testen der normalen Spezifikation und ggf. zum automatischen Testen der Software. Diese Verfahren werden beispielsweise bei der Entwicklung von Software für Herzschrittmacher eingesetzt und sind äußerst aufwändig. Außerdem erfordern logische symbolische Sprachen eine enorme Konzentration und keiner hat wirklich Lust, diesen Kram zu schreiben oder gar zu lesen. Daher sind diese Verfahren nur für kleinere Softwareprodukte interessant. Wie umfangreich wäre wohl auch die formale Spezifikation für die Cockpitsteuerung einer Boeing, wenn doch die englische schon mehrere Ordner umfasst? Erfahrungsgemäß müssen bei formaler Verifizierung die Mitarbeiter auch alle sechs Wochen durch ausgeruhte Kräfte ausgetauscht werden. Machbar ist das sicherlich alles, aber bevor Sie das als Entwickler einplanen, sollten Sie zuerst den Kunden finden, der das auch bezahlen kann und will!

8.2Testen bis zum jüngsten Tag

"Einen Fehler begangen haben und ihn nicht korrigieren: Erst das ist ein Fehler."
(Konfuzius, Lunyu 15.30)

Nachdem wir soeben festgestellt haben, was "Testen" eigentlich bedeutet und warum man auf keinen Fall darum herum kommt, sollte wir nun klären, "was wann" getestet und behoben werden sollte. Das "was wann behoben" ist schnell geklärt: alles Gefundene zeitnah (oder wie mein Rechtsanwalt so gerne sagt: unverzüglich)! Gemäß obigem Spruch ist ein Fehler schließlich nur dann ein Fehler, wenn er nicht korrigiert wird.

Aber "was wann testen"? Nun, pauschal sage ich immer: Teste mit dem nächsten Schritt den vorherigen und am besten auch noch mit dem übernächsten den nächsten und den vorherigen. Beispielsweise können Sie die gefundenen Teilziele gegen das Hauptziel auf Vollständigkeit und Widerspruchsfreiheit testen: Sollte ein Teilziel nichts mit dem Hauptziel zu tun haben oder diesem widersprechen, ist dies wahrscheinlich ein Fehler. Haben Sie in der In/Out-Liste etwas bei "Out" stehen, was vorher als Teilziel formuliert wurde, ist dies wahrscheinlich ein Fehler. Formulieren Sie später in einem Anwendungsfall etwas, was in der In/Out-Liste bei "Out" eingetragen wurde, ist auch dies wahrscheinlich ein Fehler. In diesem Fall sollten Sie den gleichen Sachverhalt auch nochmal gegen die Teilziele testen, denn vielleicht ist ja auch hier der "Out"-Eintrag der Fehler. Vielleicht finden Sie auch beim Übergang vom AF-Modell zum Klassenmodell doppelte Anwendungsfälle. Vielleicht stellen Sie auch fest, dass ein Anwendungsfall gar nicht so implementiert wurde, wie er spezifiziert wurde (passiert immer wieder, weil die Entwickler immer wieder ohne Rücksprache was einbauen, was sie viel besser finden). Vielleicht bekommen Sie ja auch einfach beim Klick auf eine Schaltfläche einen "Fatal internal error 0xAFFE". Vielleicht wird auch bei einem Report in den Zwischensummen falsch gerundet, weil gar nicht spezifiziert wurde, dass mit den präzisen Werten weiter gerechnet werden soll und der Entwickler sich die einfachste Variante rausgesucht hat. Und so können Sie vom ersten Akquisegespräch beim Kunden bis weit in die Wartungsphase immer und immer wieder an allen Ecken testen. Es gibt reichlich Gelegenheiten, man muss nur die Augen aufhalten.

Wie heißt es bei [L13] so schön: "I've always said that the last bug will be found when the last customer dies." (dt.: "Ich habe immer gesagt, dass der letzte Fehler gefunden sein wird, wenn der letzte Anwender stirbt.") Ich bin im Jahr 2000 von einer Firma angemailt worden, die einen Fehler in einem Programm auf SCO-Xenix gefunden hat, das wir 1989 ausgeliefert hatten! Ich bin auch 2001 von einem Großhandel angesprochen worden, ob es nicht ein Fehler sei, dass das Filialprogramm, das ich 1986 für die vier Standorte geschrieben hatte, den Euro nicht unterstützt! Dies führt auch zur Frage nach der Beurteilung bzw. Klassifizierung von Fehlern, zu der ich etwas weiter unten bei den Systematischen Tests komme.

Unter "Testen" wird landläufig nur das Testen des programmierten Codes verstanden, aber was nutzt es denn, wenn man die korrekte Implementierung einer falschen Annahme überprüft? Das Testen muss also bereits beim Erstellen der Spezifikation und sogar noch früher, nämlich beim Aufnehmen der Anforderungen, erfolgen. Wenn sich beispielsweise Anforderungen widersprechen, kann auch der sicherste Programmierer kein vernünftiges Programm daraus machen. Und wenn die Anforderungen nicht verbindlich fixiert wurden, kann man oft nicht einmal feststellen, ob es eigentlich überhaupt ein Fehler ist. Das stinkt dann immer mächtig nach Streit. Das Testen ist also keine Phase des Projekts, sondern ein Prozess, der am Ende jeder Phase angezogen wird.

Darüber hinaus reicht es oft nicht, nur das Softwaresystem zu testen. Stattdessen muss das Gesamtsystem inklusive des Softwaresystems getestet werden. Eventuell versagt die Software der Gewächshaussteuerung oder der Waschanlage ja nur dann, wenn die elektrische Schnittstelle wegen Feuchtigkeit durch Spritzwasser nicht spezifizierte Signale auf die Ports haut, die dann von der Software falsch ausgewertet werden. Sehr häufig ist die Ursache des Fehlers einfach überhaupt nicht da, wo man sie zunächst vermutet. So erinnere ich mich auch an eine Situation, wie ich auf der Suche nach der Ursache eines Fehlers in einem ISAM Datenbanksystem beim Debuggen auf den Kundendaten einen völlig anderen Fehler gefunden hatte, dessen Effekt die Testmannschaft mit mehreren Leuten seit einer Woche zu reproduzieren versuchte. ("Debuggen" ist englisch für "entwanzen"; so nennt man die schrittweise Ausführung eines Programms zwecks Fehlersuche. Der Begriff stammt noch aus der Zeit, wo in den Relaismaschinen die Fehler als Kurzschlüsse durch Käferchen und andere kleine Haustierchen entstanden waren. Der Fehler wurde dann durch das Herausnehmen der toten Tierchen und das Erneuern der Kabel und Kontakte behoben.)