Die Zuverlässigkeit der Software gewinnt heute eine immer größere Bedeutung. Mit steigender Komplexität der Anwendungen wiegen die Auswirkungen von Fehlern in der Software immer schwerer. Das Testen, als Mittel zur Verbesserung der Zuverlässigkeit, findet deshalb in der Praxis beim Anwender erhöhte Beachtung. Unter ständigem Rationalisierungszwang ist der Anwender aber auch im Hinblick auf die Kosten genötigt, sich mit dem Testen intensiv zu beschäftigen. Mit einem Anteil von 30 Prozent bis 50 Prozent an den gesamten Entwicklungs- und Wartungskosten einer EDV-Anwendung bilden direkte und indirekte Testkosten den größten einzelnen Kostenblock.
Allgemein betrachtet bedeutet Testen das Überprüfen daraufhin, ob
geforderte Funktionen erfüllt werden. Treten Abweichungen auf, so müssen die Ursachen dafür ermittelt und beseitigt werden.
Im Rahmen der Softwareentwicklung wird Testen meist als eine eigene Projektphase gesehen, die auf die Codier-Phase folgt. Bezogen auf ein Programm, wird üblicherweise mit dem Test in dem Moment begonnen, in dem eine formal fehlerfreie Umwandlung vorliegt. Dieses Programm wird dann vom Programmierer im "Schreibtischtest" (leider viel zu selten!) oder mit Hilfe von Testdaten durch den Rechner getestet.
50 Prozent aller Programmfehler entstehen bereits vor dem Codieren
Stellt man aber die Frage, wann und wie Fehler im Programm entstehen, so ist zu erkennen, daß diese Art des Testens viel zu spät einsetzt und daß der Programm Code als einziges Testobjekt unzureichend ist.
Sorgfältige Untersuchungen bei umfangreichen Softwareprojekten haben gezeigt, daß etwa die Hälfte aller Fehler bereits vor dem Codieren entstehen.
Diese "frühen" Fehler sind hauptsächlich auf Kommunikationsprobleme in den Entwicklungsteams zurückzuführen. Sie schlagen sich nieder in unvollständigen, unrichtigen, mißverständlichen Unterlagen und Dokumenten, die schließlich die Arbeitsgrundlage für das Codieren bilden.
Ähnliche Untersuchungen haben außerdem gezeigt, daß das Beheben eine solchen Entwurfsfehlers in einer bereits codierten Anwendung bis zu 100 (hundert!-) mal teurer ist, als wenn er noch in der Entwurfsphase in den entsprechenden Unterlagen berichtigt wird.
Daraus ergibt sich zwangsläufig die Forderung nach einer neuen Betrachtung des Testens. Ähnlich dem Dokumentieren muß auch das Testen nicht als Projektphase, sondern als projektbegleitende Funktion betrachtet werden. Es sollte nicht nur fertiger Code mit Hilfe des Rechners, sondern auch die Implementierungsvorgaben sollten durch Personen getestet werden. ("Structured Walk Through", "Inspection", "Review" heißen die entspreche den neuen Schlagworte.)
Dies erfordert aber, daß Dokumente und Unterlagen in "testfähiger Form" erstellt und auch projektbegleitend über die gesamte Dauer eine
Softwareprojektes geführt werden. Gerade das aber bereitet in der Praxis erhebliche Schwierigkeiten, wenn versucht wird, die projektbegleitende Dokumentation in gewohnter, manueller Weise durchzuführen.
Nur computergestützte Dokumentation wirtschaftlich
Die Anforderungen, die an testfähige, projektbegleitende Dokumentation gestellt werden, sind nur durch den Einsatz moderner, computergestützter Dokumentationsverfahren zu realisieren wirtschaftlich sinnvoll.
Die Dokumentation muß standardisiert und einheitlich sein, insbesondere damit Dokumente vergleichbar werden, aber auch, damit Personen, die nicht zum Projektteam gehören, zum Test der Dokumente mit herangezogen werden können (Fachabteilungsmitarbeiter, Revisoren, externe Berater).
Die Dokumentation muß ständig aktuell und verfügbar sein, damit die Tests einzelner Dokumente auch wirklich projektbegleitend durchgeführt werden können und umfangreiche Vorbereitungszeiten entfallen.
Dokumentationsdatenbank kontra Loseblattsammlung
Die zentrale Speicherung der Dokumentation in einer eigenen Datenbank verhindert zudem, daß Unterlagen erst mühsam aus verschiedenen Ordnern oder Schubladen zusammengesucht werden müssen.
Zentrale Speicherung zusammen mit ausgefeilten Abfrage- und Auswertungsmöglichkeiten fördern auch die Wiederverwendung von bereits Erarbeitetem. Neben den offensichtlichen Einsparungen durch Vermeidung von Doppelarbeiten reduziert das natürlich auch die Fehlermöglichkeiten.
Von ganz besonderer Bedeutung ist die Möglichkeit, Schnittstellen von neuen Anwendungen zu bestehenden Anwendungen maschinell zu analysieren. Hier lassen sich bereits im Entwurfsstadium Fehler lokalisieren, die zu spät bemerkt, oft eine Anwendung erheblich verzögern und verteuern, möglicherweise sogar zum Scheitern bringen.
Zum Thema "Test und Dokumentation" läßt sich leicht eine recht umfangreiche Bibliothek zusammenstellen. Viele wichtige Aspekte dieses Themas konnten in unserem kurzen Beitrag nicht angesprochen werden. Wir haben uns bewußt darauf beschränkt, die neue Betrachtung des Testens als projektbegleitende Funktion herauszustellen, die in der Praxis noch wenig verbreitet ist. Diese mangelnde Verbreitung liegt wohl in den Schwierigkeiten begründet, die sich beim Erstellen von testfähiger Dokumentation ergeben.