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

Warum testen?

"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 und das Unterlassen der Tests damit als mindestens grob fahrlässig eingestuft werden kann. Wie wir bereits festgestellt haben, 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 die Methode zur Prüfung auf Fehler.

Eine militärische Software, die in Serienherstellung Verwendung finden soll, muss sicherlich gründlicher getestet werden, als eine Verwaltungssoftware, die individuell für einen einzelnen Kunden erstellt wird, allein schon deshalb, weil der mögliche Schaden bei einem Unfall deutlich höher ausfallen 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 Product" bezeichnet: dies ist ein Produkt, das frühzeitig seinen Produktionsort verlässt und erst beim Kunden ausreift - halt wie eine Banane, die grün gepflückt wird und während der Schiffsreise oder oft eben erst beim Kunden ausreift.

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!