Viele Manager mussten spätestens mit der Jahr-2000-Problematik lernen, wie eigenwillig und unkontrolliert erstellte unternehmenskritische Systeme dem Geschäft und dem Image beim Kunden schaden können. Firmen der Finanz- und Telekommunikationsbranche wissen zudem längst, dass ihnen durch Störungen ihrer Systeme Einnahmen entgehen, die sich schnell auf Tausende von Mark pro Minute belaufen. Anbieter, die sich erfolgreich im E-Commerce etablieren wollen, brauchen leistungsfähige und ausfallsichere Systeme, um Kunden auch weiterhin auf ihre Website zu locken. "Es ist nicht länger hinzunehmen, wenn Kunden und Endanwender als unbezahlte Tester neuer Anwendungen missbraucht werden", warnen die Analysten beim britischen Marktforscher Ovum in ihrer Studie "Ovum Evaluates: Software Testing Tools".
Zugleich steigt bei immer kürzeren Produktzyklen die Komplexität heutiger Systeme. Stichworte sind hier die Implementierung von Multitier-Anwendungen, der finanzielle und unternehmenspolitische Zwang zur Integration bestehender Applikationen einschließlich Internet-Anbindung sowie Komponenten- und Objekttechniken à la Java und Corba. Eine bloße Begutachtung oder manuelle Tests von Software greifen für eine Überprüfung der genannten Szenarien zu kurz oder sind laut einhelliger Meinung von Experten schlicht unmöglich. IT-Abteilungen müssen deshalb nach Wegen suchen, wie sie die unumgänglichen Tests bei der Anwendungsentwicklung und Produkteinführung weitgehend automatisieren und iterative Verfahren zur Qualitätskontrolle etablieren können.
Allerdings klaffen Anspruch und Wirklichkeit beim Thema Testen weit auseinander. So existieren in vielen Unternehmen keine Testumgebungen, geschweige denn ein umfassendes Qualitäts-Management (QM). Diese Erfahrung bestätigt Rüdiger Dehn, Geschäftsführer der DIS Informationssysteme GmbH in Osnabrück. "Tests spielen bisher nur vereinzelt in Projekten eine Rolle." Statt dessen, so Dehn, wird auf Teufel komm raus entwickelt und gehofft, dass die Anwendung am Ende läuft. Als Grund wird dann zum Beispiel angegeben, dass die neue Software angeblich problemlos läuft. Auch meinen Firmenchefs, kurzfristig Geld sparen zu können, da Testen sich erst mittelfristig auszahlt, oder sie stecken das IT-Personal in ihrer Meinung nach marktwirksamere Aktivitäten. Wo nicht getestet wird, ist oft zu beobachten, dass im Laufe der Projekte die Anforderungen heruntergeschraubt werden, weil die Programme sonst nicht laufen. Doch selbst wo Testwerkzeuge angeschafft wurden, verstauben sie oft in den Regalen, weil gehetzte Entwickler wenig Interesse verspürten.
Um dem zu begegnen, muss ein umfassender Testzyklus in der Projektarbeit implementiert werden. Dieser benötigt, vergleichbar guter Software-Entwicklung, klar definierte Anforderungen, um begrenzte Ressourcen und Zeit besser auszunutzen und qualitative Ergebnisse erzielen zu können.
In keinem Fall wird es hierbei möglich sein, alle nur erdenklichen Tests tatsächlich zu realisieren. Die aus den Anforderungen abgeleiteten Prüffälle müssen vielmehr einem eindeutig definierten Testszenario dienen, vorausgesetzt, für einen Testfall sind hochwertige und schnell verfügbare Daten erhältlich.
Da die Möglichkeiten zur Testfallgenerierung unüberschaubar, die Ressourcen knapp und Testmethoden zahlreich sind, muss von vornherein versucht werden, eine pragmatische Lösung zu finden. Dabei können Aspekte wie Anwendungstyp, Architektur, Programmiersprache, Entwicklungswerkzeuge, strategische Bedeutung einer Applikation, Know-how des Teams sowie funktionelle Eigenheiten die Auswahl bestimmen. Sinnvoll ist es, sich beim Test zunächst auf vermutlich unternehmenskritische und fehleranfällige Prozesse zu konzentrieren. Für Vergleiche zwischen den Testdurchläufen muss sich zudem die getestete Anwendung in ihren alten Zustand zurückversetzen lassen.
Alle diese Aufgaben können Test-Tools nicht allein oder gar nicht erledigen, sondern sie sind Teil eines umfassenderen Test-Managements. Dieses umfasst Aspekte wie die Anforderungsanalyse, Designkontrolle, Codeanalyse, Inspektionen und Reviews sowie modellbasierte Überprüfungen. Zentraler Bestandteil einer Testumgebung muss auch Software für das Konfigurations-Management sein. Sie verknüpft und vergleicht die Testergebnisse mit den Testskripts, den Datenquellen, Angaben zur getesteten Anwendung bis hin zu Build-Informationen (Build=Entwicklungsabschnitt) aus der Softwareentwicklung.
Bei den eigentlichen Tests werden je nach Projektphase Unit-, Modul-, Integrations- und Systemtests (Kontrolle der Spezifikationen) sowie Tests zur Überprüfung der Benutzerfreundlichkeit unterschieden. Diese Einteilung sagt jedoch noch nichts über die sich dahinter verbergenden Testverfahren aus. So dominieren zu Beginn des Entwicklungsprozesses die noch weitgehend manuellen Verfahren Inspektion und Analyse. Im weiteren Verlauf des Projektes steht dann die Codeausführung im Mittelpunkt. Dabei ist es notwendig, Veränderungen und Korrekturen durch einzelne Teammitglieder, den Übergang von einem Build zum nächsten sowie schließlich die fertigen Anwendungen immer wieder zu überprüfen.
Dieser iterative Prozess bei der Entwicklung ist inzwischen eines der wichtigsten Einsatzgebiete für Testwerkzeuge. Diese nehmen häufig Regressionstests vor, die die Überprüfungen automatisieren und beschleunigen helfen. Sie ermöglichen eine Wiederholung der durchgeführten Tests nach Änderungen des Programms zu einer beliebigen Zeit. Meist sind diese Tests wiederum mit sogenannten Funktionstests verbandelt. Diese leiten zum einen ihre Testfälle und Testdaten aus der Spezifikation der zu prüfenden Software ab, ohne die Programmstruktur des Prüfgegenstands auszuwerten. Zum anderen bewerten sie die Vollständigkeit der Prüfung anhand der Spezifikation.
Funktionstests verlangen vorab eine aufwendige Generierung von Testfällen, die die in einer Anwendung stattfindenden Prozessverläufe präzise und in unterschiedlicher Weise abbilden sowie Vorhersagen über die zu erwartenden Ergebnisse erlauben. Bei Regressionstests kann üblicherweise aus bereits bestehenden Testfällen ausgewählt werden, was den Testaufwand senkt. Ein dritter, zunehmend anzutreffender Typ sind die Lasttests. Mit ihnen wird das Antwortzeitverhalten des Systems geprüft, wenn zum Beispiel 50 oder 5000 User gleichzeitig arbeiten. Da dies manuell nicht oder nur mit erheblichem Aufwand zu realisieren ist, sind derartige Test-Tools die einzige Möglichkeit, vorab mehr über die Leistungsfähigkeit einer Anwendung zu erfahren.
Die Kosten beziehungsweise Ersparnisse des Tool-Einsatzes können nur projektbezogen beziffert werden. Anwender sollten aber die durch Tests vermiedenen Fehler, Qualitätsprobleme und Kundenproteste bei ihren Betrachtungen nicht vergessen. Als Richtwert läßt sich vorsichtig formulieren, dass bei Last- und Performance-Tests der Break even sich innerhalb weniger Wochen erreichen läßt. Automatisierten Verfahren gemein ist zudem, dass die Aufzeichnung und Pflege der Testskripts einen Overhead erzeugen, der bei Funktionstest laut Untersuchungen von Ovum nur dann gerechtfertigt ist, wenn ein Skript mindestens viermal zum Einsatz kommt. Bei Funktionstests dauert der Payback laut Manfred Eierle, Geschäftsführer bei Mercury Interactive, länger, weil deren Implementierung und Automatisierung aufwendiger ist, mehr Arbeitsplätze mit Tools ausgestattet werden müssen und die Überprüfung über das ganze System geht.
Firmen müssen sich zudem stets darüber im Klaren sein, dass Test-Tools nicht die intellektuelle Arbeit eines Anwendungsspezialisten ersetzen können. Das Werkzeug hilft dem Fachmann lediglich, bestimmte Aufgaben schneller und effizienter auszuführen, und verschafft ihm Schnappschüsse über den Zustand einer Anwendung. Das Ergebnis sind vor allem Übersichten über die Zahl der bekannten und neuentdeckten Fehler, historisierte Daten je Testzyklus sowie Angaben darüber, in welchem Umfang Code geprüft und wie viele der Anforderungen erfüllt wurden. Werkzeuge für Lasttests registrieren zudem Verbesserungen bei den Antwortzeiten und der Maximallast einer Applikation.
Eine Eigenheit des heutigen Marktes für Werkzeuge ist, dass die Produkte den Software-Release-Zyklen und Techniken immer etwas hinterherhinken und die Hersteller stark vom Feedback ihrer Kunden leben. Diese waren zu Beginn schwer für die Produkte zu gewinnen, da sie mit der Integration des Testprozesses nicht zurechtkamen oder glaubten, dass die Tools den Aufbau von Testumgebungen überflüssig machen würden. Hinzu kam, dass die Testergebnisse oftmals nicht die Anforderungen der IT erfüllten. Zudem beschränkten sich Anbieter bis vor kurzem auf Capture-Replay-Tools für Client-Server-Umgebungen und GUIs.
In letzter Zeit ist nun eine erhebliche Weiterentwicklung und Ausdehnung des Portfolios zu erkennen (siehe Grafik). So bietet beispielsweise Mercury Interactive jetzt auch Tools für das Testen von Standardsoftware wie SAP R/3. Konkurrenten wie Rational oder Compuware verfolgen eine weitergefasste Produktstrategie, in der es um die Abdeckung des gesamten Test- und Entwicklungprozesses durch diverse Tools geht. Segue Software aus Lexington, Massachusetts, will sich stark auf den Markt für E-Commerce-Anwendungen fokussieren und liefert als erster Anbieter etwa Monitoring-Tools für den Test komplexer Architekturen wie Corba. Die Hersteller werden bei ihren Strategien aber auch künftig auf das Feedback ihrer Kunden angewiesen sein, um zumindest die häufigsten Anwendungen und Standards abdecken zu können. Methoden für den Bau von Testumgebungen sind bisher nicht in Sicht. Immerhin hat Segue jetzt unter dem Titel "The E-Business Reliability Survival Guide" eine lesenswerte Zusammenfassung von Best Practices diverser Testszenarien für verteilte Systemarchitekturen publiziert.
Anwendungsszenarien
Client-Server-Anwendungen: Aufgrund der Simultaneität vieler Transaktionen sind Funktionstests schwer aufzubauen und kaum zu automatisieren. Diese Tests versuchen, Transaktionen zu isolieren, indem Einträge in Datenbanksystemen modifiziert werden. Nur wenige Tools können indes die Funktionsfähigkeit von Updates direkt überprüfen, so dass Anwender aus dem Verhalten des Systems selber Schlüsse ziehen müssen. Häufiger sind Lasttests, bei denen Fat-Clients mit Rechnern gekoppelt sind, die die Netzlast, sprich das Verhalten von "virtuellen" Benutzer, simulieren. Die am Client gemessenen Antwortzeiten erlauben Rückschlüsse auf die Performance. Problem ist, dass die simulierten Benutzer eventuell nicht den realen Anwendern entsprechen und die Leistungsfähigkeit des Netzes nicht berücksichtigt wird.
Web-basierte Anwendungen: Die Performance und Qualität von Websites muss laufend automatisch per Link- und Lasttests geprüft werden. Letztere müssen sich verfeinern lassen, um nicht nur Resultate wie "Server is busy" zu generieren. Bei Web-Seiten gilt es, deren statische, interaktive und dynamische Bestandteile auf ihre Ausführbarkeit hin zu überprüfen.
Standardsoftware: Bei speziellen Konfigurationen, nach Modifizierungen sowie vor der Integration in die DV-Landschaft sollte getestet werden. Lasttests sind unbedingt erforderlich, um das Laufzeitverhalten zu prüfen.
Objektorientierte Systeme: Kenntnisse über die Beziehungen zwischen den oft zahlreichen Klassen einer Anwendung sowie Aspekte wie Vererbung, Polymorphismus und Kapselung müssen in die Testfälle eingehen.
Wünschenswert, aber kaum machbar ist es, jede Objektklasse durch Inspektionen und Reviews im Entwicklungsprozess zu prüfen. Ein integriertes Konfigurationsmanagement ist ein Muss. Tests in der Entwurfsphase sollten das Use-Case-Modell und das Objektmodell als Grundlage nutzen.
Da der OO-Entwicklungsprozess iterativ und inkrementell ist, lässt sich früh mit dem Testen von Code (Klassen, Cluster) beginnen. Bei jeder Erweiterung (Inkrement) müssen das aktuelle "Build" und sein Vorgänger nochmals per Regressionstest geprüft werden. Auf Systemebene kommen Tools für Last- und Funktionstests zum Einsatz.