Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

23.10.1998 - 

DV-Kosten/Management-Ansatz in der Projektpraxis

Kostenkontrolle mit automatischem Testen von Software

Systematisches Testen kann die Qualität verbessern, die Risiken mindern und damit Kosten senken. Es unterscheidet sich stark vom klassischen Ansatz: Getestet wird nicht erst, wenn die Software fertig ist und vom Lieferanten zum Integrationstest übergeben wurde, sondern gleich zu Beginn des Projekts.

Der Auftraggeber kann zum einen dem Systemlieferanten konkretere, also bessere Vorgaben liefern, zum anderen die Systemabnahme und -einführung sicherer und kostentransparenter erledigen. Auch die Realisierungsaktivitäten zwischen der Spezifizierung der Anforderungen und der Systemabnahme werden durch das ständige Feedback konstruktiv begleitet. Derartiges Testen ist somit ein Management-Ansatz, der den Auftraggeber in die Lage versetzt, das eigene Softwareprojekt über den gesamten Verlauf hinweg - auch in schwierigen Phasen - entscheidend mitzugestalten.

Wer sich auf den Standpunkt zurückzieht: "Ich bezahle meinen Generallieferanten dafür, daß er das IT-Projekt für mich erledigt", der läuft Gefahr, daß die abgelieferte Software am Ende wesentlich von der Interpretation der Vorgaben durch den Lieferanten abhängt. Da dieser während der Laufzeit nur wenige Rückmeldungen erhält, kann er nur ei- nen Bruchteil der häufig vagen Erwartungen und Hoffnungen erfüllen. Wenn die Budgets ausreichen, wird dann versucht, über weitere Softwareversionen die Fehler und Defizite auszu- gleichen. Ein Vorgehen, das in die Kostenspirale, aber nicht zum betriebswirtschaftlichen Erfolg führt.

Warum aber verzichten Unternehmen trotz dieser Vorteile in der Praxis zu oft auf das Testen? Es sind im wesentlichen drei Argumente, mit denen sich Auftraggeber häufig selbst im Wege stehen:

- "Testen ist nicht notwendig". Diese Meinung nennt der Auftraggeber gerne bei der Einführung einer Standardsoftware, in der Regel für ERP-Anwendungen. Aber auch die muß zunächst immer in eine vorhandene Umgebung integriert werden.

Durch diese Anpassungen zum Beispiel Transaktionen, Benutzerzahlen oder Systemverfügbarkeit bewegt sich eine Installation häufig weg vom Idealstandard. Das konkrete Verhalten kann also durchaus Risiken mit sich bringen. Diese abzuschätzen und auszuschließen ist Ziel des systematischen Testens.

- "Testen ist zu teuer." Die Gründe für dieses Argument relativieren sich meistens schon sehr bald. Kosten, die durch den Verzicht auf Tests eingespart werden, fallen spätestens bei der Systemeinführung an. Zu diesem Zeitpunkt sind sie dann fast zwangsläufig wesentlich höher, da der Zyklus der gesamten Software-Erstellung oder Bereitstellung, beginnend bei der Spezifikation, nochmals zu durchlaufen ist.

- "Die organisatorischen Voraussetzungen für systematische Tests sind bei uns nicht gegeben." Schon bei der Vertragsgestaltung können Art und Weise sowie Dokumentation von Systemtests vereinbart werden. Dies gilt zunächst für die Systemumgebung des Lieferanten, denn dort ist das Know-how für alle Details der Entwicklung konzentriert. Für den Nachweis der Systemfunktionalität nach der Integration der Software im Betrieb sind eigene Integrationstests notwendig, ebenso ein Abnahmetest, der zum Beispiel für den Betrieb besonders wichtige Systemeigenschaften prüft. Bei diesen Tests liegt das Know-how und damit die Zuständigkeit beim Auftraggeber. Diese Arbeitsteilung ermöglicht es, Systemeigenschaften mit den eigenen Anforderungen rationell in Einklang zu bringen.

Der erste Schritt ist die Erstellung der Testbeschreibung während der Systemspezifikation, die dadurch selbst an Qualität gewinnt. Sie kann ohne großen Zusatzaufwand beispielsweise als "Use Cases" (typische Anwendungsfälle) oder als Aktions-Reaktionsmatrix parallel vorgenommen werden. Sie besteht mindestens aus Testfallbenennung: "Welche Tests soll es geben?" und Testfallbeschreibung: "Was wird getestet, in welchen Schritten, welche Ergebnisse erwarten wir?"

Indem Testfälle und spezifizierte Systemeigenschaften verknüpft werden, ist während der späteren Tests eine Statistik zum Abdeckungsgrad der Softwarerealisierung oder -einführung zu jedem Zeitpunkt zu ermitteln - eine nicht unwesentliche Information für das Management.

Nach der Spezifikation müssen die Reihenfolge der Tests festgelegt und Termine und Personalressourcen zugeordnet werden. Damit ergibt sich ein fließender Übergang von der Planung zur Ausführung: Testfallbeschreibung komplettieren, Reihenfolge definieren und Organisation festlegen. Diese Schritte sollten in jedem Fall vor der ersten Softwarelieferung erfolgen, damit unmittelbar danach mit dem Test beim Auftraggeber begonnen werden kann. Dazu muß eine Testumgebung bereitstehen, die der späteren Produktionsumgebung zumindest sehr ähnlich ist. Vor der ersten Softwarelieferung sollte natürlich der Lieferant auch den Systemtest bereits erledigt haben.

Während des systematischen Testens beim Auftraggeber tauchen oft Softwarefehler auf, die der Lieferant durch den Systemtest nicht erfaßt hat. Diese in der frühen Phase möglichst vollständig zu erkennen und zu bereinigen ist das Ziel.

Die Klassifikation und Behandlung von Problemen sollte schon im Vertrag enthalten sein. So ist es beispielsweise üblich, Schwierigkeiten in vier Klassen zu unterteilen. So können die Vertragspartner etwa durch die Einstufungen von "sehr schwerwiegend" bis lediglich "störend" vorab festlegen, in welcher Zeitspanne die Fehler zu beheben sind.

Damit der Status eines Problems jederzeit kontrollierbar ist, wird vorher dessen "Lifecycle" vereinbart, etwa "open", "working", "fixed" oder "closed".

Wenn beispielsweise der Auftraggeber einen Fehler entdeckt, öffnet sich ein Problemreport, der Status des Problems ist also "open". Danach meldet dieser den Fehler dem Lieferanten und erhält beim Auftraggeber den Status "working". Der Lieferant behebt den Fehler, und die zugehörigen Tests laufen nach der nächsten Softwarelieferung beim Auftraggeber mit einem "Regressionstest" zur Kontrolle nochmals. Wenn die Tests keine Fehler mehr aufweisen, wird der gelöste Problemfall geschlossen; er bekommt den Status "closed". Wichtig sind klare Verantwortlichkeiten für die Statusvergabe. Sie sollten im Qualitätssicherungverfahren des Auftraggebers vorgegeben sein.

Derart einfach ist der Problem-Lifecycle in der Praxis allerdings meist nicht aufgebaut, da alle Details und Ausnahmen abzubilden sind. Eine Ausnahme ist der "Change Request": Eine vermeintliche Fehlerursache muß möglicherweise auf unvollständige Systemspezifikationen zurückgeführt werden, wenn der Auftraggeber zum Beispiel Funktionen schlichtweg vergessen hat und dieses Defizit sich jetzt als Fehler bemerkbar macht. Der Tester muß natürlich trotzdem einen Problemreport eröffnen. Im weiteren Verlauf wird geklärt, ob der Lieferant durch einen Ergänzungs- oder Änderungsauftrag den Fehler beheben soll. In diesem Fall erhält der Problemreport den Status Change Request und wird gleichzeitig Bestandteil des neuen Auftrags.

Der Testablauf bedarf der engen Kommunikation mit eigenen Organisationseinheiten aus QS und Betrieb sowie dem Lieferanten. Bestimmte Tests werden in Zyklen wiederholt. Ist dies häufiger notwendig, spricht man von "Regressionstests". Sinnvoll wäre es natürlich, solche Regressionstests zu "konservieren", damit sie bei späterem Bedarf "automatisch" laufen. Auf dem Markt sind dafür Tools von verschiedenen Anbietern erhältlich, mit denen Ereignisse und Eingaben auf der GUI-Oberfläche aufgezeichnet, das heißt in einem Testscript abgelegt werden. Sie können Maskeninhalte, den Status von Funktions-Buttons (aktiv oder inaktiv), Layouts etc. auf das identische Verhalten in einer neuen Version beziehungsweise einem Update prüfen. Die Vorteile:

- Nach einem Break-even spart das Unternehmen bei jedem weiteren Regressionstest Zeit und Geld.

- Die Qualität der Tests wird verbessert, weil der Ausführende nicht ständig denselben Test manuell wiederholen muß.

- Es wird systematischer und ausführlicher getestet, da mit dem Tool beliebige Eingabekombinationen kreiert und vorgenommen werden können, die ansonsten nicht oder nur durch stichpunktartige Tests abgehandelt würden.

- Mit verbesserter Testqualität werden Kosten eingespart, die sonst zu spät erkannte Fehler verursachen.

Grundsätzlich werden bei der Testautomatisierung drei Kategorien unterschieden:

- Regressionstests: Testfälle werden in der aktuellen Version erstellt (aufgezeichnet) und müssen in der neuen Version dasselbe Ergebnis liefern.

- Streßtests: Ein bestimmter Testfall läuft mehrfach. Damit ist beispielsweise ein bestimmter Datenbankzustand herbeizuführen oder sind Systemgrenzen auszuloten.

- Lasttests: Damit wird das Antwortzeitverhalten des Systems geprüft, wenn zum Beispiel fünf, 50, 500 oder mehr User parallel arbeiten. Da dies manuell nicht oder nur mit erheblichem Aufwand zu realisieren ist, schaffen Test-Tools Abhilfe.

Break-even nach dem dritten Release erreicht

Der Einsatz von Regressionstesttools lohnt sich natürlich erst bei Projekten ab einer bestimmten Größe oder solchen, die häufige Softwareversionswechsel erwarten lassen. Der Break-even ist ungefähr nach dem dritten Release oder Update erreicht. Ein besonderer Vorteil automatisierter Tests: Da sie zum großen Teil unbeaufsichtigt außerhalb der normalen Arbeitszeiten, zum Beispiel an Wochenenden und in der Nacht, laufen, erhält der verantwortliche Mitarbeiter zusätzliche Zeit für die restlichen manuellen (freien) Tests.

Tools für den Lasttest rechnen sich bei größeren Softwareprojekten immer, da ohne sie ein Funktionsnachweis mit mehreren parallelen Usern unter normalen Bedingungen nicht möglich ist.

Integration der Testschritte durch Testwerkzeuge

Die Schritte Testplanung, -ausführung und Problem-Management werden durch geeignete Werkzeuge integriert. Die meisten Tools am Markt bilden allerdings nur einen Ausschnitt des gesamten Testprozesses ab. So gibt es für das Problem-Management besonders viele Werkzeuge.

Allerdings sagt eine bestimmte Anzahl von x gefundenen und bereinigten Fehlern letztlich wenig aus. Man kann daraus weder erkennen, ob der bestellte Lieferumfang abgedeckt wird, noch ob alle Funktionsbereiche getestet wurden und das System auch größerer Belastung durch mehr Daten und Benutzer gewachsen ist. Dies sind Fragen, die nur mit einem systematischen Testverfahren zu beantworten sind. Werkzeuge für die Planung sollten deshalb in Verbindung mit solchen der manuellen und automatisierten Testausführung und des Problem-Managements für ein durchgängig werkzeugunterstütztes Test-Management eingesetzt werden.

ANGEKLICKT

Ein wichtiges Mittel zur Kostenkontrolle und -senkung ist systematisches Testen von Software. Die Unternehmen können damit schon vor der Nutzung Risiken stark verringern oder ganz vermeiden. Der Test ermittelt den aktuellen Projektstatus zu jedem beliebigen Zeitpunkt, wodurch auch eine transparente Kosten- situation für das Management entsteht. Systematisches Testen ist letztlich ein effizientes Controlling-Instrument für den Auftraggeber, mit dem er den Prozeß der Softwarerealisierung und -einführung entscheidend mitgestalten kann. Automati- sierungswerkzeuge können die Testqualität verbessern und auch die Kosten für den Test selbst langfristig senken.

Klaus Dudda ist Berater für Testautomatisierung bei der PSI AG in Berlin. Dr. Rüdiger Dehn ist Geschäftsführer der DIS Informationssysteme GmbH in Osnabrück.