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

Testen bis zum jüngsten Tag

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 Teilprozess, der am Ende jedes Prozesses und erst recht am Ende jeder Phase angezogen wird. Eigentlich ist es sogar eine "Methode", die nach jedem Schritt zur Anwendung kommen sollte.

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.)