Nur wenige Unternehmen können es sich leisten, Software neu zu entwickeln, die den Forderungen der Anwender nicht mehr entspricht oder fehlerhafte Ergebnisse liefert. Allerdings sind Änderungen aus dem Blickwinkel des Softwareengineering nicht einfacher als Neuentwicklungen. Für den Bereich der SW-Produktion gilt hinsichtlich der Wartung immer noch die Aussage: Eine durchgeführte Änderung führt normalerweise zu zwei zusätzlichen Fehlern.

Gerade aufgrund der zu berücksichtigenden Abhängigkeiten und der Notwendigkeit des späteren Zusammenwirkens der geänderten oder neuentwickelten Programmteile mit den vorhandenen Komponenten sind zusätzliche Anforderungen an die Qualitätssicherung bei der Verfahrenssanierung gegeben. Der folgende Beitrag gibt eine Antwort auf die Frage, wie diese Lücke erfolgreich ausgefüllt werden kann.

Auch heute noch sind DV-Verfahren im praktischen Einsatz, die sich durch einen oder mehrere Aspekte charakterisieren lassen:

- Die Programmverarbeitung stimmt nicht mit den fachlichen Anforderungen beziehungsweise Erfordernissen überein.

- Keiner weiß, was das Programm fachlich tut.

- Die Beschreibung im Benutzerhandbuch stimmt nicht mit der Programmverarbeitung überein; das Benutzerhandbuch ist nicht aktualisiert beziehungsweise nicht vollständig.

- Es liegen Änderungswünsche beziehungsweise Fehlermeldungen vor.

- Programme sind unstrukturiert aufgebaut; es werden Konstrukte verwendet, die nur schwer änderbar sind.

- In Programmen ist "toter Code" enthalten.

- Der Entwickler des Programms ist nicht mehr im Haus oder nicht in dem gleichen Bereich tätig.

- Es existiert ein umfangreicher Testbestand; dieser umfaßt Produktionsdaten und Massendaten.

- Der Testbestand wird nicht (mehr) genutzt, Änderungen werden nicht durchgeführt.

- Der Testbestand wird höchstens ergänzt. Keiner weiß, welche Testdatensätze was bewirken sollen.

- Die fachliche Vollständigkeit des Testdatenbestands ist nicht bekannt; die Abdeckung bezogen auf die durchlaufenen Teile des Programms, was ja objektiv nachvollziehbar ist, beträgt zwischen 20 und 50 Prozent der Anweisungen. Wenn man schon keine vollständige Neuentwicklung eines Verfahrens durchsetzen kann, dann stellt sich die Frage, wie man im Rahmen der Verfahrens-Sanierung mit einem vertretbaren Aufwand dennoch zu einem zufriedenstellenden Ergebnis kommen kann.

Der Aufbau eines systematischen Testbestandes ist hierfür ein wesentlicher erster Schritt. Durch ihn läßt sich erfolgreich fachliches Anforderungsprofil und Verfahrensqualität der Programme abgleichen. Prioritäten für die konstruktive Verfahrenssanierung (Funktionsausbau, Fehlerbereinigung) lassen sich begründen. Gleichzeitig können durchgeführte Programmänderungen/-erweiterungen getestet werden.

In den nachfolgenden Ausführungen wird unter anderem auf folgende Fragen eingegangen:

- Wie muß ein systematischer Testdatenbestand aufgebaut sein?

- Wie kann man sicherstellen, daß der Testdatenbestand in zukünftigen Wartungsfällen weiterverwendet wird?

Daß der Testbestand nur eine - wenn auch sehr wichtige Komponente - bei der Verfahrens-Sanierung ist, bleibt unbestritten; zusätzlich sind Fragen der konstruktiven Qualitätssicherung und organisatorische Aspekte zu berücksichtigen.

Die wichtigste Voraussetzung für die Verfahrens-Sanierung ist die Kenntnis über den tatsächlichen Umfang des Softwaresystems. Hier sind aber teilweise mehr Vermutungen denn gesicherte Erkenntnisse über die tatsächlich realisierten Funktionen und deren Arbeitsweise im Detail vorhanden. Andererseits sind die Anforderungen, welche Funktionen von dem Softwaresystem zur Verfügung gestellt werden sollen, vielfach überhaupt nicht oder nur teilweise bekannt.

Daher ist die unbedingte Notwendigkeit gegeben, einen systematischen Testbestand aufzubauen, anhand dessen erkennbar wird, welche Leistungen (Geschäftsvorfälle und Funktionen) von dem Softwaresystem verlangt werden und welche Leistungen im vorhandenen System realisiert sind.

Ein systematischer Testbestand muß verschiedenen qualitativen Anforderungen genügen:

- Funktionsabdeckung

Die von dem Softwaresystem erwarteten Leistungen (Geschäftsvorfälle oder Funktionen) müssen im Testbestand realisiert sein.

- Vollständigkeit

Die Vollständigkeit beziehungsweise der erreichte Vollständigkeitsgrad des Testbestands muß erkennbar und nachweisbar sein (zum Beispiel Abdeckungsgrad hinsichtlich Funktionskombinationen oder hinsichtlich des Prozentsatzes der abgedeckten Strukturelemente des Programms).

- Transparenz und Nachvollziehbarkeit

Die Zuordnung der Testfälle für (fachliche) Leistungen zu Programmteilen muß eindeutig möglich sein. Gleichzeitig müssen den Testfällen beziehungsweise Testfallgruppen die jeweils zugehörigen Testprozeduren und Datensätze zugeordnet werden können.

- Handhabbarkeit

Alle an der Verfahrensentwicklung Beteiligten müssen an dem Testbestand arbeiten können. Jede einzelne Komponente (zum Beispiel ein konkreter Testdatensatz) muß verständlich sein (dokumentiert; weitgehend selbsterklärend). Die gezielte Testausführung für selektierte fachliche Leistungen muß ebenso möglich sein, wie der Gesamttest für ein Programm.

- Änderbarkeit

Anpassungen des Testbestands im Wartungsfall (zukünftige Pflege und Anpassung des Verfahrens) muß sichergestellt werden; der Aufbau eines Testbestandes ist eine Investition, die langfristig verwendet werden muß. Daher ist die Pflege in jedem Wartungsfall unabdingbare Voraussetzung für das Überleben des Investitionsguts.

Wenn man diese Kriterien zugrunde legt, ergibt sich im Normalfall relativ schnell, ob der vorhandene Testbestand genutzt werden kann ñ möglicherweise durch Umstrukturierung oder Ergänzung. Vielfach erkennt man dann allerdings, daß die gestellten Anforderungen entweder überhaupt nicht oder nur unbefriedigend erfüllt sind.

Wenn keine (detaillierten) Informationen über die fachlichen Leistungen des Softwaresystems vorliegen - weder in Form eines Benutzerhandbuchs noch durch Personen ñ ist es unabdingbar, zunächst eine Informationsbasis aufzubauen. Dies kann nur durch kombinierte Bearbeitung folgender Aspekte erfolgreich sein:

- Gespräche mit fachlich kompetenten Anwendern (Fachabteilung),

- Analyse des Quellcodes,

- Analyse der vorhandenen Dokumentation.

Anhand dieser Unterlagen und Informationen besteht dann die Möglichkeit, die fachlichen Leistungen zu strukturieren. Die Strukturierung nach Vorgängen (Geschäftsvorfällen) orientiert sich an den Leistungen, die das System dem Benutzer zur Verfügung stellt, ohne die interne Realisierung durch (DV-technische) Funktionen zu berücksichtigen. Darauf aufbauend können die Funktionen zusammengestellt werden, die die Leistungen DV-technisch realisieren.

Um der Anforderung nach gezielter Ausführung von Teilen des Testbestands gerecht werden zu können, ist die Strukturierung des Testbestands erforderlich. Kriterien für die Strukturierung sind unter anderem von der späteren Nutzung des Testbestands abhängig:

- Da bei zukünftiger Pflege und Anpassung vielfach einzelne Funktionen geändert werden, ist es zweckmäßig, den Testdatenbestand unter Berücksichtigung dieses Sachverhalts aufzubauen, um gezielt selektieren zu können.

- Nach dem Test der einzelnen Funktionen sind alle davon direkt abhängigen Funktionen als Kombinationen mindestens einmal zu testen; dementsprechend sollte die Möglichkeit bestehen, Testfälle für abhängige Funktionen zu erkennen.

- Um gezielt einzelne Vorgänge (Funktionsketten) testen zu können, ist dieses Strukturierungskriterium ebenfalls einzubeziehen.

Anhand dieser Kriterien besteht die Möglichkeit, für die Teststufen Funktionstest und Vorgangstest gezielt Daten bereitzustellen. Eine Planung des Testbestands umfaßt aber auch:

- Festlegen von Testreihen

In einer Testreihe werden eine oder mehrere Funktionen beziehungsweise Vorgänge zusammengefaßt; hierbei sind fachliche als auch DV-technische Kriterien heranzuziehen.

- Festlegen der Ziele der Testfallermittlung

Operationale Zielvorgaben für den Grad der Vollständigkeit, etwa hinsichtlich der Kombinationen von Funktionen oder Vorgängen, sind notwendig für die Bearbeitung.

- Festlegen der Ziele für die Testdaten

Es ist festzulegen, wie viele Test-Datensätze pro Testfall zu erstellen sind. Die minimale Anforderung ist sicherlich, daß ein Testdatensatz pro Testfall erstellt wird; dies kann in Verbindung mit Normal- und Grenzwerten beliebig kombiniert werden.

Zunächst ist einmal von Bedeutung, daß die Testfälle deutlich von den Testdaten unterschieden werden. Es ist notwendig, "qualitative" Testdaten zu erstellen. Ziel ist es, mit möglichst wenig Daten die notwendige Überprüfung von Soll und Ist zu ermöglichen.

Testdaten sind nur Mittel zum Zweck; sie sind Mittel zur Überprüfung, ob alle Vorgänge, Funktionen oder Ausgaben vorhanden und richtig realisiert sind. Zur Vermeidung von Redundanzen bei den Testdaten ist es notwendig, zunächst den Zweck zu analysieren.

Die Testfallermittlung hat zum Ziel, die Menge der möglichen Eingaben systematisch zu differenzieren und das "Was" für das Testen zusammenzustellen. Durch die Differenzierung von Testfällen und Testdaten erübrigt sich der ansonsten mühselige Versuch, Testdatensätze direkt anzupassen. Vielmehr werden im Rahmen der Wartung zunächst die relevanten Testfälle selektiert.

Anhand der eindeutigen Beziehung zwischen Testfällen und Testdaten über entsprechende Schlüssel besteht dann auf einfach Art und Weise die Möglichkeit, die von einer Änderung betroffenen Testdatensätze zu identifizieren. Dadurch wird die zukünftige Wartung der Investition "Testbestand" sichergestellt. In Verbindung mit der Testfallermittlung und Testdatenerstellung werden die Soll-Ergebnisse ermittelt.

Sind die Testfälle und Testdaten ermittelt, erfolgt der erste Teil der Testausführung: Die Testdaten werden auf das vorhandene System angewendet. Ergebnisse dieser Arbeiten sind:

- Bestätigung der bereits bekannten Mängel beziehungsweise fehlenden Funktionen.

- Eindeutige Antworten auf zahlreiche Fragen (zum Beispiel "Was passiert eigentlich, wenn . . .?").

-Erkennen zusätzlicher Fehler, die bisher nicht einmal erahnt wurden.

Aufbauend auf den Ergebnissen der Testausführungen haben nun die notwendigen Arbeiten zur Konzeption und Realisierung der Änderungen zu erfolgen, worauf in diesem Beitrag allerdings nicht eingegangen werden soll.

Der Testbestand findet seine weitere Verwendung, nachdem die konstruktiven Elemente der Sanierung (fachlicher Entwurf der Änderung, DV-technischer Entwurf und Codierung) abgeschlossen sind. Aufgrund der sorgfältigen Dokumentation der Testfälle beziehungsweise Testdaten bestehen normalerweise keine Schwierigkeiten, die erforderlichen Testläufe durchzuführen.

Aufgrund der Struktur sollte es möglich sein, Testfälle für einzelne Funktionen oder Kombinationen von Funktionen (Funktionstest) ebenso zu selektieren wie Testfälle für Vorgänge und Vorgangskombinationen (Vorgangstest).

Jeder Test ist nur so gut, wie die dabei erzielten Ergebnisse systematisch überprüft werden. Diese vielfach bei Verwendung von Massendaten überhaupt nicht - wirtschaftlich - zu vertretende Forderung ist bei einem systematischen Testfallbestand und Testdatenbestand unproblematisch.

Allerdings sei darauf hingewiesen, daß die nicht-automatisierte Ergebnisprüfung, das heißt der manuelle Vergleich von vorher definierten Soll-Ergebnissen mit den tatsächlich erzielten Ergebnissen relativ aufwendig und personalintensiv ist. Die Erfahrungen haben gezeigt, daß - gerade bei der im allgemeinen gegebenen Zeitknappheit - die wiederholte Prüfung vieler Einzelergebnisse hinsichtlich der Akzeptanz zu Schwierigkeiten führt.

Eine manuelle Ergebnisprüfung ist jedoch einmal erforderlich. Daher sollte man die heute vorhandenen Möglichkeiten des automatisierten Soll/Ist-Vergleichs soweit wie möglich nutzen. Einfache Hilfsmittel wie Datenvergleichsprogramme helfen hier weiter. Erfahrungen zeigen, daß die früher kaum durchgeführte Wiederholung von Testläufen in späteren Wartungsfällen zur Selbstverständlichkeit werden kann, wenn eine entsprechende Unterstützung vorhanden ist.

*Rudolf van Megen und Heiner Diesteldorf sind Mitarbeiter der SQS, Gesellschaft für Software-Qualitätssicherung mbH, Köln.