Konventionen können die Erfahrung des Systementwicklers nicht ersetzen

Test-Tools: So verbessern Sie die Softwarequalität

01.04.1983

Wer auf die Verbesserung des Testens innerhalb der Softwareentwicklung/-wartung hinweist, hört in Seminaren oder Kundengesprächen vielfach folgende Reaktionen: Wir müssen Tools haben! Es gibt jedoch keine vernünftigen Tools am Markt und selber wollen wir keine entwickeln (lassen)! Ist damit die Frage nach den Möglichkeiten zur Verbesserung des Testens beantwortet? Oder gibt es neben der Beschaffung von Tools - die ohne Zweifel insbesondere hinsichtlich der Akzeptanz der Vorgehensweise beim Testen wichtig sind - andere/zusätzliche Möglichkeiten? Antworten auf diese Fragen geben Rudolf van Megen und Heinz Bons*.

Die Erkenntnis, daß der Testprozeß rationalisiert werden muß, resultiert nicht zuletzt daraus, daß jeder Leiter der Softwareentwicklung, Projektleiter und auch jeder einzelne Softwareentwickler ein ungutes Gefühl haben muß, wenn trotz des 50- bis 70prozentigen Anteils für das Testen am Gesamtaufwand der Softwareentwicklung die Ergebnisse hinsichtlich der erreichten Qualität immer noch zu wünschen übrig lassen. Allein die Feststellung, daß dieser Zustand unbefriedigend ist, bringt jedoch noch nicht die Lösung. Vielfach tauchen noch andere Probleme auf, die "zunächst einmal gelost werden müßten". Dies ist teilweise sogar richtig, obwohl die hiermit erzielten Verbesserungen der Wirtschaftlichkeit der Softwareentwicklung/-wartung unter Umständen geringer sind als die mit der Verbesserung des Testens zu erzielenden Produktivitätszuwächse. Insbesondere unter Berücksichtigung der steigenden Qualität sollte man gerade bei der Einführung/Realisierung der anderen "dringlichen und vorrangigen Dinge" durchaus die Aspekte des Testens nicht außer acht eines Data-Dictionaries gleichzeitig die gegebenen Möglichkeiten zur Verbesserung des Testens mitberücksichtigt, hat "zwei Fliegen mit einer Klappe geschlagen".

Daß Test-Tools nicht die einzige Möglichkeit zur Verbesserung der Vorgehensweise beim Testen sind, hat sich inzwischen als nahezu allgemeine Erfahrung herausgestellt, allein die Verfügbarkeit von Test-Tools ist noch keine Garantie für deren Akzeptanz und Anwendung sowie insbesondere nicht für die eigentlich zu erwartende Verbesserung der beim Testen erzielten Ergebnisse. Richtiger wäre - um auf die einleitend aufgestellten Forderungen zurückzukommen - die Formulierung "Wir müssen auch Test-Tools haben!" Test-Tools sind nur ein Glied in der Kette, denn:

- Wozu braucht man zunächst Tools, wenn es darum geht, das Testen vom Big-Bang-Testen auf phasen- beziehungsweise stufenweises Testen mit vorgegebenen Testzielen und Kontrolle deren Einhaltung umzustellen? Sicherlich sind Tools zum Messen der Testabdeckung oder zur Bereitstellung von Testumgebungen wichtig, aber es geht auch ohne diese Hilfsmittel - wie in eine Reihe von Praxisfällen inzwischen nachgewiesen worden ist.

- Wozu braucht man Tools bei der verbindlichen Einführung des systematischen Testens von Dokumenten, das heißt, nicht Abstimmungsgesprächen? Sicherlich wäre es wünschenswert, wenn man Tools zum Beispiel für Prototyping hätte, aber es geht (zunächst) auch ohne.

Hier ließen sich eine Reihe weiterer Beispiele finden, anhand derer deutlich gemacht werden kann, daß Tools nur eine Komponente im Rahmen der Verbesserung des Testens sind.

Das (primäre) Verlangen nach Tools ist sicherlich auch darauf zurückzuführen, daß vielfach Werkzeuge angeboten werden, bei deren Einsatz eine drastische Reduzierung des Testaufwands bei gleichzeitiger Verbesserung der Softwarequalität versprochen wird. Da die Systematisierung der anderen, für die Verbesserung der Vorgehensweise beim Testen ebenso wichtigen Komponenten - nämlich Antworten auf die Fragen:" was, wann, wie, wer" mit den Werkzeugen zu tun hat -, bisher kaum als fertiges Produkt angeboten wird, ist die vielfach geäußerte alleinige Forderung nach Test-Tools verständlich und in gewisser Weise auch berechtigt.

Die Verbesserung der Vorgehensweise beim Testen macht es aber insgesamt erforderlich, Antworten unter anderem auf folgende Fragen zu geben:

- Welche Zwischen-/Endprodukte sind zu testen, um Fehler so früh wie möglich zu finden?

- In welchen Testphasen soll der Testprozeß eingeteilt werden - um überschaubare Abschnitte zu erhalten, deren Komplexität handhabbar bleibt?

- Welche Testarten beziehungsweise Testaktivitäten sind hinsichtlich der Fehlererkennung am effektivsten?

- Welche Personen sind beim Testen wofür zuständig - nach dem Motto "Der richtige Mann an den richtigen Platz" !

- Welche Testtechniken (Verfahren und Tools) sind einzusetzen?

Insgesamt sind also mehr Antworten erforderlich als diejenige auf die Frage nach den Test-Tools. Daß diese Fragen heute vielfach nicht beantwortet sind, zeigt sich zum Beispiel in der Praxis darin, daß häufig das Testen aus der Sicht der Fachabteilung (zum Beispiel Abnahmetest) ausschließlich in Form von Paralleltests erfolgt. Dabei ist hierdurch nur eine Möglichkeit gegeben, die zugegebenermaßen nicht die effektivste ist, da durch eine Vielzahl von Originalzahlen häufig gleiche Dinge getestet werden, wobei es jedoch ausreichen wurde, diese Aspekte einmal einzubeziehen.

Gibt es wirklich keine Test-Tools?

Wenn schon festgestellt werden muß, daß die Beschaffung/Verfügbarkeit von Test-Tools allein noch keine Verbesserung der Vorgehensweise beim Testen sicherstellen kann, sondern nur eine Komponente darstellt, stellt sich dennoch die Frage, ob es wirklich keine "vernünftigen Test-Tools am Markt gibt" . Ohne hier den Begriff "vernünftig" näher eingrenzen zu wollen, sollte man zunächst einmal die verfügbaren Test-Tools hinsichtlich ihrer Einordnung differenzieren. Test-Tools sind verfügbar als:

- Betriebssystem-Komponenten,

- Stand-alone-Tools,

- Bestandteile von Tool-Systemen ("Werkzeugkästen"),

- Bestandteile von Software-Engineering-Environments.

Hinsichtlich derjenigen Test-Tools die als Betriebssystemkomponenten zur Verfügung stehen beziehungsweise relativ einfach beschafft werden können, sind durchaus wirkungsvolle Unterstützungen bestimmter Testaktivitäten gegeben.

Ein Beispiel hierfür ist etwa die COUNT-Option (Messung der Ausführungshäufigkeit von Anweisungen), die - zwar nicht kumulierend über mehrere Testläufe, aber dennoch wirkungsvoll - die Vollständigkeit des Testens beurteilen hilft.

Ein weiteres Beispiel sind DEBUG-Anweisungen, die für das Erstellen von Testumgebungen, die Simulation in einer Testumgebung sowie die manuelle Instrumentierung zur Ermittlung von Ausführungshäufigkeiten durchaus verwendet werden können.

Dies sind zwar nur einfache Werkzeuge für das Testen innerhalb der Softwareproduktion, und die in Betriebssystemkomponenten verfügbaren Tools beziehen sich größtenteils auf das Testen und die Fehlerlokalisierung, die aber dennoch durchaus wirkungsvoll sind, wenn sie "optimal" eingesetzt werden.

Hinsichtlich der Stand-alone-Tools, das heißt solcher Tools, die nur eine oder nur eine geringe Anzahl von Funktionen umfassen, stellt sich die Situation etwas anders dar.

Betrachtet man die Regelstatistik bei Entscheidungstabellen-Vorübersetzern, dann ist hierdurch sicherlich ein relativ gutes Hilfsmittel zur Teststatistik-Erstellung auf Anweisungs- oder Verzweigungsebene, das heißt Werkzeuge, die die Ausführungshäufigkeit von Anweisungen beziehungsweise Verzweigungsausgängen messen und - sofern komfortabel - kumulieren, können hier ebenfalls genannt werden; auch wenn sie teilweise erst per "Tool Transfer" aus den USA beschafft werden müssen. Ein Negativbeispiel hier sind allerdings die ungeliebten Testdatengeneratoren (besser: Testdateigeneratoren), die zwar ein Vielzahl von Testdaten produzieren (ohne genaue Kenntnis der Inhalte), wobei die Effizienz - global einmal als Wunsch verstanden, mit möglichst wenigen Daten möglichst viele unterschiedliche Aspekte zu testen - dieser Art von Testdaten mehr als zu wünschen übrig läßt. Für Testdateigeneratoren ist der Einsatzbereich sehr deutlich abzugrenzen; und dann können auch derartige Werkzeuge durchaus - etwa beim Massentest innerhalb des Systemtests - sinnvoll eingesetzt werden.

Auch innerhalb von Tool-Systemen, die über eine einheitliche Benutzerschnittstelle angesprochen werden können, sind Testfunktionen in mehr oder weniger großem Umfang realisiert. Hierbei handelt es sich um Funktionen zur Bereitstellung der Testumgebung beziehungsweise zur Erstellung von Ablauf-/ Teststatistiken. Wenn auch das Tasten innerhalb dieser Tool-Systeme nur einen gewissen Teil ausmacht und aufgrund dessen der mögliche Funktionsumfang der Test-Tools eingeschränkt ist, weisen derartige Toolsysteme dennoch gewisse Vorteile gegenüber Stand-alone-Tools auf, da sie dem Benutzer nun mehrere Funktionen für unterschiedliche Testaufgaben und Testaktivitäten zur Verfügung stellen (können). Dadurch entfällt das Einarbeiten in neue Werkzeuge und das damit meist verbundene Erlernen einer Werkzeugsprache.

Software-Engineering-Environments sind in gewisser Weise hinsichtlich des Umfangs einbezogener Testaktivitäten vergleichbar mit Tool-Systemen; sie beinhalten neben den Werkzeugfunktionen allerdings auch organisatorische Festlegungen die einen wesentlichen Beitrag zur organisatorischen Einbettung der Test-Tools leisten.

Testwerkzeuge in Software-Engineering-Environments sind dadurch charakterisiert, daß:

- für die unterschiedlichen Testobjekte,

- für die einzelnen Testphasen,

- für die jeweiligen Testarten/ Testaktivitäten und

- für die unterschiedlichen Testträger

jeweils geeignete Komponenten (Testverfahren/-werkzeuge) zur Verfügung gestellt werden. Bedeutender Vorteil derartiger integrierter Systeme ist, daß neben der einheitlichen Benutzeroberfläche gleichzeitig der organisatorische Rahmen für den Testprozeß zur Verfügung gestellt wird.

Dies bedeutet natürlich nicht, daß die übrigen Test-Tools nicht ebenso ergänzt oder ausgebaut oder letztlich die gleichen Effekte erzielt werden können.

Daß Tools vielfach zwar vorhanden, aber nicht angewendet werden, ist nicht immer auf Mängel im Funktionsumfang beziehungsweise der Handhabbarkeit zurückzuführen. Ebenso wichtige Ursachen für den Nichteinsatz sind die Unkenntnis hinsichtlich der Verfügbarkeit und insbesondere der Einsatzmöglichkeiten entsprechender Werkzeuge.

Bei den Test-Tools als Komponenten von Betriebssystemen wird dies besonders deutlich. Ein Grund für den Nichteinsatz der COUNT-Option, wie er sich immer wieder in der Praxis zeigt, ist die nicht vorhandene Kenntnis über die Verfügbarkeit, die Einsatzmöglichkeit und Mächtigkeit dieser Option.

Bezüglich der DEBUG-Anweisung ist die Situation nicht sehr viel anders; auch hier sind vielfach der Nutzen und die Einsatzmöglichkeiten dieser Option (einfaches Aktivieren beziehungsweise Deaktivieren von Testanweisungen) nicht bekannt, oder sie wird für die Ergebnisprüfung während des Ablaufs nicht systematisch genutzt.

Bei den Betriebssystemkomponenten ist im wesentlichen ein Mangel in bezug auf die Kenntnis über die Anwendungsmöglichkeiten gegeben.

Hinsichtlich der Stand-alone-Tools stellt sich die Situation geringfügig anders dar. Betrachtet man Testdateigeneratoren, dann wird gerade anhand derartiger Werkzeuge deutlich, warum sie nicht eingesetzt werden. Es fehlt die organisatorische Einbettung, das heißt die Festlegung, wann diese Werkzeuge - in welchen Testphasen - einzusetzen sind. So kann man für einen Massentest innerhalb des Systemtests einen Testdateigenerator sinnvoll einsetzen; die Schwierigkeiten mit derartigen Werkzeugen und die daraus im allgemeinen resultierende Ablehnung in einzelnen Unternehmungen ergaben sich primär dadurch, daß die sinnvollen Einsatzmöglichkeiten derartiger Dateigeneratoren nicht festgelegt waren. Zunächst ging jeder Systementwickler von der Vermutung aus, daß hierdurch seine - erfahrungsgemäß nicht geringen Schwierigkeiten bei der Testdatenerstellung - wenn nicht gelöst, so doch zumindest in erheblichem Maße verringert würden; dies war aber nun gerade nicht der Fall für die Gesamtheit der im Bausteintest beziehungsweise Verfahrenstest durchzuführenden Analysen.

Insgesamt sind bei Stand-AloneTools vielfach Schwierigkeiten dadurch gegeben, daß ein Mangel bezüglich der Abstimmung mit anderen Werkzeugen besteht und die Einsatzmöglichkeiten während der Softwareproduktion nicht im ausreichenden Maße definiert, beschrieben und auch reglementiert sind.

Bei Tool-Systemen fehlt zunächst die organisatorische Einführung in den Testprozeß. Dies wird dadurch deutlich, daß jede Testfunktion innerhalb des "Werkzeugkastens" von jedem Entwickler in jeder Testphase beliebig aufgerufen werden kann. Das Fehlen ist kein Mangel; denn es ist nicht Ziel dieser Werkzeuge, die individuelle Einbettung mit vorzuschreiben. Die Festlegung, welche Testwerkzeuge in welchen Testphasen für welche Testarten und Testaktivitäten, von welchen Testträgern zu benutzen sind, ist nicht standardisiert.

Durch die sogenannten "Werkzeugkästen" können zwar vorhandene Schwierigkeiten auf der technischen Ebene vermindert werden; die eigentlich angestrebte Integration der Test-Tools in den Testprozeß wird aber noch nicht erreicht. Um eine bestimmte Qualität der Produkte zur erreichen, ist es erforderlich, eine gewisse Personenunabhängigkeit durch Vereinheitlichung oder Standardisierung der Vorgehensweise sicherzustellen.

Betrachtet man nun die Software-Engineering-Enviroments, die auch die organisatorischen Festlegungen mitberücksichtigen, wodurch die Anwendung der Tools zur Zwangsläufigkeit wird, dann würde man im Normalfall derartige Systeme als "optimal" betrachten.

Hier stellt sich allerdings die Frage, ob beziehungsweise wie die übrigen Klassen von Test-Tools ergänzt oder ausgebaut werden können, um letztlich die gleichen Effekte zu erzielen.

Eine relativ einfache, aber dennoch wirkungsvolle Möglichkeit ist durch Bereitstellung und Anwendung von Test-Konventionen gegeben; hierdurch wird festgelegt, "wann" die entsprechenden Tools, "wie, wer" einzusetzen hat. Erst dadurch wird die Voraussetzung zur systematischen Anwendung der Test-Tools geschaffen.

Sie sind eine gute Möglichkeit, auch beim Testen der grundsätzlichen Forderung, das Richtige zum richtigen Zeitpunkt, von den richtigen Personen mit den richtigen Hilfsmitteln durchzuführen, gerecht zu werden. Herauszustellen ist noch einmal, daß die Organisation des Testprozesses mehr ist als das Abstimmen von Werkzeugfunktionen. Durch Test-Konventionen soll und kann die Erfahrung einzelner Softwareentwickler nicht ersetzt werden; vielmehr wird die Möglichkeit geschaffen, anderen die vorhandenen Erfahrungen um zusätzliche Aspekte zu ergänzen. Dies ist die Grundlage für die Verbesserung der Vorgehensweise beim Testen.

*Geschäfsführer der SQS Gesellschaft fur Software-Qualitätssicherung mbH, Köln