Immer noch vernachlässigen viele Unternehmen im Interesse einer kurzen Implementierungszeit das Testing ihrer E-Busi- ess-Anwendungen und missbrauchen ihre Kunden als Versuchskaninchen. Die testwilligen Anwender stehen allerdings zunächst vor einer Reihe von Fragen. Sie müssen zum einen geeignete Werkzeuge, zum anderen aber auch eine passende Aufteilung der Aufgaben zwischen den eigenen Kräften und externen Dienstleistern finden. Die beste Lösung fällt hier je nach Unternehmensgröße, Art der Anwendung und technischen Voraussetzungen recht unterschiedlich aus.
Die Santander Direkt Bank in Frankfurt überlässt beispielsweise das Testen ihres Internet-Portals einem externen Testlabor. Die Deutsche Bank hingegen hat für die Integration der Großrechner in die Welt des großen "E" eine umfangreiche eigene Testinfrastruktur geschaffen. Beide Geldinstitute sind mit ihrer Strategie erfolgreich.
Dabei umfasst Qualitätssicherung Benutzbarkeit, Leistungsfähigkeit, Wartbarkeit und fachliche Korrektheit. Da der Aufwand für die Qualitätssicherung bei Web-Anwendungen in der Regel denjenigen klassischer IT-Projekte übertrifft und 35 bis 45 Prozent des Gesamtkosten erreicht, suchen Unternehmen nach Wegen, um ihn in Grenzen zu halten. Diese Wege können je nach Geschäftsfeld und Unternehmensgröße in völlig verschiedene Richtungen führen.
Machen oder machen lassen?
Nutzer von Performance-Testtools beispielsweise haben heute die Wahl: selbst machen oder machen lassen. Alle großen Werkzeuganbieter wie Cyrano, Mercury oder Radview bieten den Performance-Test heute auch als Service an. Beratungs- und Servicehäuser wie die Kölner SQS Software Quality Systems AG oder die Imbus AG in Erlangen haben gleich ein ganzes Dienstleistungspaket um das externe Testen geschnürt. Andere Anbieter wie die Ulmer Tescom GmbH konzentrieren sich ebenfalls auf Spezial-Services zur Software-Qualitätssicherung, bieten jedoch keine Möglichkeit zum Test-Outsourcing. Bei den großen IT-Beratungshäusern ist das Testen Teil des Gesamtangebots zur Softwareentwicklung.
Mark Green von der Santander Direkt Bank in Frankfurt/Main hat beim Testen des Internet-Portals seines Unternehmens einen neuen Weg gewählt: "Bislang führte jeder seine Softwaretests selbst durch. In Deutschland möchten wir uns aber auf unser Kerngeschäft konzentrieren. Da passt das Testen nicht in die Landschaft", erklärt er. "Unsere IT-Projekte sind vergleichsweise klein, deshalb wollen wir weder Infrastruktur noch Know-how für das Testen aufbauen." Green nutzte deshalb die Möglichkeit, den Test extern durchführen zu lassen.
Anpassung braucht Zeit
Die Santander Direkt Bank setzte dabei auf das "SQS Test Lab", das unabhängig von einem bestimmten Werkzeuganbieter testet und berät. Vorab lieferten die Kölner Dienstleister auf Merkmale und Ziel des Projekts abgestimmte Empfehlungen zur Vorgehensweise und zum Tooleinsatz.
Das Testprogramm umfasste alle wichtigen Aufgaben der Qualitätssicherung für E-Business-Anwendungen: den fachlichen Funktionstest, einen Integrationstest, einen Link-Test, einen Usability-Test, einen Sicherheitstest sowie Last- und Performance-Tests. Der zugrunde liegende Testplan wurde von Bank und Dienstleister gemeinsam entwickelt. Anhand der Dokumentation von Santander bildeten die Externen einzelne Versuchsabläufe wie etwa die Erfassung einer Wertpapierbestellung. Als Ergebnis lag schließlich eine Liste aller fachlichen Funktionen des Internet-Portals vor. So konnte man für jeden Ablauf mittels ABC-Analyse das Testvorgehen, die "Testtiefe" und damit den jeweils notwendigen Aufwand festlegen.
Die räumliche Trennung der Qualitätssicherung von den Backend-Systemen der Bank erforderte eine eigene Testumgebung im Labor. Sie ist dort zwar grundsätzlich vorhanden, inklusive aller wichtigen Werkzeuge. Es blieb aber die Aufgabe, die Umgebung an die individuellen Gegebenheiten bei Santander anzupassen sowie mit Frankfurt und der Entwicklungsumgebung des Dortmunder IT-Zulieferers zu verbinden.
Besonders diese Anpassung erforderte viel Zeit. Dennoch hat sich das Outsourcing gelohnt, da die Bank keine Mitarbeiter einarbeiten und keine eigene Infrastruktur für die Qualitätssicherung ihrer Software aufbauen musste, was bei insgesamt knapp 300 Santander-Mitarbeitern in Deutschland unwirtschaftlich wäre. Auch den Erwerb eigener Testsoftware konnte sich das Unternehmen sparen. Sie ist in den Leistungen der Anbieter von Testing Services bereits berücksichtigt.
Testen als Kernaufgabe
Ganz anders fiel die Entscheidung der Deutschen Bank aus, als es darum ging, das Testen ihrer E-Business-Anwendungen neu zu organisieren. Für das Geldinstitut gehört die Softwareentwicklung und mit ihr das Testen zu den Kernaufgaben, die man nicht aus der Hand gibt. Ein Beispiel für die Bedeutung der Softwarequalität für Finanzdienstleister liefert der "DB Trader", mit dem Kunden der Deutschen Bank Wertpapiere vom heimischen PC aus bestellen können: Der gesamte Prozess von der Kundenorder bis zur Bestätigung per E-Mail dauert zumeist nur Augenblicke und ist vollautomatisiert.
Automation ist aufwändig
Im Jahr 1998 gab es durch maßgebliche Erweiterungen der Depotverwaltungsfunktionen und die bevorstehende Einführung des Euro in DB Trader rund 6000 Programmänderungen. Die Verantwortlichen für dieses Projekt waren in einem ständigen Zugzwang. Einerseits mussten sie nach jeder Änderung im System Regressionstests durchführen, damit die Qualität der Anwendung sichergestellt blieb und keine unerwünschten Überraschungen im Betrieb auftraten. Andererseits sollte man wegen der Forderung nach einem kurzen "Time-to-Market" zeitnah neue Softwareversionen bereitstellen. Diesen Interessenskonflikt zwischen Schnelligkeit und Zuverlässigkeit lösten die Banker, indem sie ihr Testen standardisierten und automatisierten. Wegen der Komplexität der Anwendungen war diese Automatisierung erst nach einer längeren und aufwändigen Vorbereitung möglich. Der heutige Leistungsumfang des vorliegenden Systems zeigt jedoch, dass mit den Investitionen die angestrebten Ziele erreicht wurden.
"Bei uns sind derzeit rund 20 Testumgebungen gleichzeitig aufgebaut", umreißt Jan Winter von der Deutschen Bank den Umfang der Qualitätssicherung. "Da geht es nicht anders, als dass Sie intensiv in das Know-how der Mitarbeiter, in Werkzeuge für die Automatisierung vieler Testaufgaben und in andere Technologien investieren."
Wer selbst Geld für Testwerkzeuge ausgibt, sollte sich vorher systematisch Gedanken darüber machen, wofür und wie intensiv er diese Tools einsetzen will. Denn in kleineren, weniger komplexen Entwicklungsprojekten etwa machen sich Werkzeuge nicht immer bezahlt. Vor allem ist zu unterscheiden, welche Testaufgaben durchzuführen sind. Während Performance- und Link-Tests ohne Werkzeuge keinen Sinn machen, kommen bei den fachlichen Funktionstests Tools erst dann ins Spiel, wenn man das Softwaretesten automatisieren will.
Testautomatisierung ist aber nur dann wirtschaftlich, wenn die grundlegende Struktur einer Anwendung bereits stabil ist. Erst dann werden Tests "regressionsfähig", das heißt, bei kleineren Änderungen im Programmcode lassen sich die Tests wiederholen, ohne dass man sie immer wieder ganz neu aufsetzen muss. Voraussetzung für einen wirtschaftlichen Tooleinsatz ist also auch, dass eine größere Zahl an Testwiederholungen anfällt. In der Regel macht sich ein Werkzeug ab einer Zahl von sechs bis sieben solcher Re-Tests bezahlt.
Hier greifen Capture/Replay-Tools. Vor allem vier große Anbieter teilen sich den betreffenden Markt: Mercury, Compuware, Rational und Segue Software. Speziell für den Test von E-Business-Anwendungen hat sich bei diesen Produkten viel getan: War bis vor kurzem "Winrunner" von Mercury das einzige Werkzeug, das sich auch für Java-Applikationen eignete, haben die anderen Anbieter mittlerweile nachgezogen, so dass jetzt alle Werkzeuge gute Funktionen für den Test von E-Business-Systemen bieten.
Es geht auch ohne Tools
"Die Entscheidung über Werkzeuge sollte in keinem Fall am Anfang stehen", meint Andreas Golze, Testspezialist bei SQS. "Nur wer sich vorab detailliert Gedanken über seine Testaufgaben macht, kann entscheiden, welches Tool für ihn geeignet ist. Mitunter stellen die Verantwortlichen dann fest, dass sie gar kein Werkzeug brauchen." Golze veranschaulicht seine These: "Wir haben Web-Anwendungen getestet, die waren hervorragend zu automatisieren. Das Problem war nur: Wenn eine Transaktion ausgeführt wurde, ließ sich der Start-Zustand der Daten nicht mehr herstellen. Und dann hilft eine Automation auch nicht mehr. Vielmehr ist in jedem Fall zu prüfen: Was lassen die vorhandene IT-Infrastruktur und die jeweiligen Geschäftsprozesse überhaupt zu?"
Beim Performance-Test kommt im Unterschied zum fachlichen Funktionstest niemand ohne Tools aus. Nur ein Werkzeug kann die gewünschte Last für die Anwendung erzeugen, und nur ein Tool kann während des Tests das System umfassend überwachen und die Ereignisse protokollieren. Dies ist die Voraussetzung dafür, dass sich eventuelle Engpässe, etwa in der Datenbank, lokalisieren und anschließend beseitigen lassen. Die größeren Tool-Hersteller - Rational, Radview, Segue Software, Mercury, Empirix und Compuware - bieten die dafür notwendigen Funktionen inzwischen alle an.
Das Angebot an Werkzeugen für den Link-Test ist fast unüberschaubar groß. Eine Liste mit Tools finden Interessenten unter www.elsop.com/wrc/comp_ls.htm.
* Matthias Schmidt ist freier Journalist in Berlin.
Performance-Testtools
Produkte / Anbieter (Auswahl) / URL
AutoTester AutoController / AutoTester / www.autotester.com
TPNS / BM / www.tpns.com
Web Application Stress / Microsoft / www.microsoft.com
Cyrano ImpactopenSTA / Cyrano / www.cyrano.com
QA Silk Performer / Segue Software / www.segue.com
QALoad / Compuware / www.compuware.de
TestSuite Enterprise LoadRunner / Mercury Interactive / www.mercuryinteractive.de
TestViewWebLoad / Rad View / www.radview.com
eTest Suite / Empirix / www.empirix.com
Preise
Für Performance-Testtools gibt es zumeist keine festen Preise. Neben dem Basispreis richten sich die Kosten nach der Anzahl der User, mit denen man die Performance der jeweiligen Anwendung testen will. So gibt es Anbieter mit einem vergleichsweise hohen Basispreis, aber dafür günstigen Lizenzgebühren. Andere Hersteller verfahren umgekehrt. Für den Preis eines Werkzeugs ist also ausschlaggebend, wie hoch die Last ist, die für den Performance-Test erzeugt werden soll.
Auswahlkriterien
- Genügt Share- oder Freeware, weil nur Tests reiner HTML-Seiten durchgeführt werden?
- Wie kompliziert ist das Skripting? Lassen sich die Testskripts leicht anpassen?
- Erkennt das Tool die Anwendungsoberfläche auf Anhieb?
- Welche Art von "Performance" soll überhaupt getestet werden: Antwortzeiten beim Kunden? Die Belastungsfähigkeit einer Datenbank? Die Konfiguration der verschiedenen Komponenten wie Applikations- und Webserver, Datenbank oder Firewalls?
- Für wie viele virtuelle Nutzer will man das Tool einsetzen?
- Gibt es Mitarbeiter, welche die vom Tool gelieferten Ergebnisse fachmännisch interpretieren können? Oder soll dies durch externe Dienstleister geschehen? Die letzte Frage stellt sich vor allem bei mittelständischen Unternehmen.
Hinweis: Die Liste hat keinen Anspruch auf Vollständigkeit
Capture/Replay-Tools
Produkte / Anbieter (Auswahl) / URL
AutoTester / AutoTester / www.autotester.com
Cyrano Webtester / Cyrano / www.cyrano.com
QA Hiperstation/ QA Run / Compuware / www.compuware.de
SilkTest / Segue Software / www.segue.com
TPNS / IBM / www.tpns.com
TransCentury Enterprise Tester / Emerald Software / www.emeraldsoft.com
WinRunner, X Runner / Mercury Interactive / www.mercuryinteractive.de
Preise
Die Preise der Capture/Replay-Tools liegen bei einer Einzellizenz zwischen rund 8000 und 15 000 Mark, bei einer Floatinglizenz zwischen rund 9000 und 17 000 Mark. Hinzu kommen Wartungskosten, die zwischen 16 und 18 Prozent des Lizenzpreises jährlich betragen.
Auswahlkriterien
- Wie leicht lassen sich die Testskripte anpassen und parametrisieren?
- Arbeitet das Werkzeug mit anderen Tools (zum Beispiel für das Test-Management) zusammen?
- Nach welchen Kriterien erkennt das Tool Objekte auf der Anwendungsoberfläche? Nach den Control-Namen, die während der Programmierung vergeben werden, oder beispielsweise nach der objektinternen Windows-ID, dem Objektindex oder nur nach gröberen Kriterien?
- Unterstützen die im Werkzeug automatisierten Schritte die eigenen Testaufgaben?
- Welche Objektfunktionen (Methoden) stellt das Tool zur Verfügung und welche werden für den Test überhaupt benötigt?
- Wer soll das Tool bedienen? Soll es intuitiv durch Nicht-Informatiker bedient werden? Oder ist eine breite Funktionalität für IT-Spezialisten gewünscht?
Hinweis: Die Liste hat keinen Anspruch auf Vollständigkeit