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.

03.04.1987 - 

Kontrollmechanismen müssen schon im Entwurfsstadium greifen:

Test Systematik hilft Design-Fehler vermeiden

Design-Fehler lassen sich oft schon im Vorfeld der SW-Entwicklung abfangen. Voraussetzung dafür ist allerdings, daß die Grundlagen für spätere Softwaretests von Anfang an festgelegt sind und entsprechende Kontrollmechanismen den Entwurf begleiten. Edgar Lange beschreibt die methodischen Werkzeuge, die innerhalb eines solchen Konzepts verwendet werden können.

Ein Großteil des Software-Entwicklungsaufwandes entfällt derzeit noch auf Test und Qualitätssicherung. Personelle Engpässe und konkurrenzbedingter Kostendruck zwingen sowohl Hersteller als auch Anwender, den Software-Entwicklungsprozeß in ihren DV-Abteilungen rationeller und effizienter zu gestalten. Insbesondere muß unsystematisches Testvorgehen durch zukunftsweisende Qualitätssicherungskonzepte ersetzt werden.

Die dabei zum Einsatz kommenden Mechanismen stellen gleichzeitig eine projektbegleitende Selbstkontrolle dar, die durch erhöhte Transparenz auch die übrigen Tätigkeiten der konzeptionellen Entwurfsphase positiv beeinflußt. Denn nach formellen Regeln gestaltete Prozesse schließen zufallsbedingte Einflußfaktoren weitgehend aus. Die Brauchbarkeit geeigneter Instrumente bedingt letztlich weitgehend die notwendige Akzeptanz durch den programmierenden Softwarehersteller sowie die Integrationsfähigkeit solcher Systeme in bestehende Arbeitsabläufe der Org./DV-Abteilungen.

Schwachstellenanalyse ist die wichtigste Basis

Daß während der Realisierung eines Softwareproduktes von verschiedenen Seiten Fehler einfließen können, gilt als unbestreitbar. In erster Linie wären hier Kommunikationsprobleme zwischen den Beteiligten sowie Verständnisschwierigkeiten bei dokumentativen Sachverhalten anzuführen. Hinzu kommen Interpretationsfehler bei Problem- oder Systemanalyse und mangelndes Abstraktionsvermögen bei der Auslegung von Pflichten- und Lastenheften durch die Realisierer.

Gelingt es, die skizzierten Einflußgrößen zu kanalisieren und anschließend durch gezielt eingesetzte Strategien zu eliminieren, so wird dadurch eine deutliche Effizienzsteigerung in den Softwareabteilungen möglich. Wesentliche Voraussetzung der angestrebten Ziele ist jedoch das Erkennen der vorhandenen Schwachstellen in den jeweiligen Bereichen, um damit Ansatzpunkte für die Einführung von Qualitätssteigerungsmaßnahmen zu schaffen.

Das Vorliegen eines Fehlers ist durch eine Abweichung des Ist-Zustandes vom vorgegebenen Soll charakterisiert. Das heißt, die Soll-Vorgaben auf der Basis der fachlichen Erfordernisse müssen hinreichend lückenlos dokumentiert sein, um einen signifikanten Vergleich zwischen Soll und Ist (also die Fehlersuche) zuzulassen. Von ausschlaggebender Tragweite ist auch der Detaillierungsgrad der oben skizzierten Unterlagen; er muß Rückschlüsse auf die zu erwartenden Ergebnisse des Endproduktes während jedes Projektstadiums gestatten und Abweichungsanalysen zur Erstellung eines nachvollziehbaren Testkonzeptes ermöglichen.

Die Praxis zeigt fortwährend, wie unscharf formulierte Vorgaben und fehlende Methoden zur Darstellung von Problemzusammenhängen zu negativen Ergebnissen führen. In der Konsequenz bedeutet dies aber, daß Sie erforderlichen Testvorbereitungen bereits in der Konzeptionsphase - während des Designs - getroffen werden müssen. Denn Fehler, die im Ansatz gemacht werden, schlagen mit einem Vielfachen der Kosten zu Buche, die spätere Fehler verursachen. Designfehler werden nämlich oftmals erst im nachhinein offenkundig: Meist erst dann, wenn die Anwendung in die Produktion geht oder den Vertriebsweg erreicht, während reine Programmier- oder Codierfehler verhältnismäßig schnell entlarvt werden können.

Ein nicht unerheblicher Anteil der bei Abnahmen beziehungsweise nach Systemeinführung gefundenen Fehler läßt sich auf unsauberes Design, widersprüchliche Formulierungen und unzureichende konzeptionelle Präzisierung zurückführen, die dem Systementwickler einen zu großen Interpretationsspielraum läßt. Dies trifft besonders auf umfangreiche DV-Projekte zu, deren Realisierung abschnittsweise in den Händen mehrerer Teams liegt und deren Erfolg in exorbitanter Weise vom reibungslosen Zusammenspiel und dem transparenten Informationsfluß zwischen allen Beteiligten abhängt.

Das Ziel, wartungsfreie, den Anfordernissen genügende Software mit hohem Zuverlässigkeitsgrad zu erhalten, läßt sich nur durch methodische Vorgehensweise erreichen. Wirksame Kontrollstrukturen müssen von vornherein, zum frühestmöglichen Zeitpunkt, in den Entwicklungsprozeß einbezogen werden und eine Lenkungsfunktion über die gesamte Projektdauer erfüllen.

Nachdem auf die Zielsetzung eingegangen wurde, stellt sich nun die Frage, welche maßgeblichen Kriterien vor diesem Hintergrund bei der Festlegung der Testbedingungen und des Testrahmens konkret zu berücksichtigen sind.

Aus inhaltlicher Sicht müssen hierbei die zu erwartenden Testergebnisse auf der Basis aller Testfälle und -daten, aber auch ein definierter Zeitrahmen in einem Testplan manifestiert werden. Die Vorsorgebemühungen sind dabei auf Vollständigkeit, Reproduzierbarkeit- und Exaktheit der Testresultate gerichtet. Ein besonderes - Augenmerk sollte dem frühzeitigen entwurfsbegleitenden Einsatz der Kontrollmechanismen gelten.

Datenstrukturen testgerecht planen

Die Gestaltung und Ausführung strukturierter Entwicklungsdokumentationen ist für die spätere Durchführung der Softwaretests von ebenso essentieller Wichtigkeit wie die Planung testgerechter Datenstrukturen und die arbeitsteilige Abwicklung der Realisierungs- und Testarbeiten innerhalb eines Teams bei komplexen Aufgabenstellungen. Standardisierte Ist-Aufnahmen stellen ein weiteres Hilfsmittel dar, Systemanalyse und Ausführungsvorgaben nach einem einheitlichen Schema zu gestalten und dadurch die Handhabung anschließender Qualitätsprüfungen zu verbessern.

Sollten im letztgenannten Fall quantitätsmäßige Einschränkungen des Testumfanges unumgänglich sein, so lassen sich einzelne Testinstrumente auch anhand folgender Kriterien gezielt einsetzen und schwerpunktmäßig anwenden:

- Nach Maßgaben des möglicherweise auftretenden Schadens bei eventuellen Programmfehlern werden speziell diese sensitiven Funktionen ausgetestet (zum Beispiel Update-Funktionen).

- Es sollten die Programmteile intensiv getestet werden, die sich bereits während des Designs als kritisch herausgestellt haben.

- Bei der repräsentativen Vorgehensweise werden möglichst gut gewichtete Testfälle auf repräsentativ ausgewählte Programmfunktionen angewandt.

Software muß lückenlos durchleuchtet werden

Im nächsten Schritt sollte die konventionelle Testmethodik durch professionelle Hilfsmittel abgelöst werden, die eine lückenlose Durchleuchtung der Software gestatten.

Zu diesen Instrumenten ist der "Structured Walk-through" zu zählen, bei dem Anschluß an ein zeitlich begrenztes Gespräch zwischen den Software-Entwicklern und fachlich versierten Testern eine Detailbegutachtung des Produktergebnisses durch letztere erfolgt. Zwangsläufig wird dadurch der Wissens- und Erfahrungsfundus eines oder mehrerer - möglichst gleichermaßen qualifizierter - Kollegen nutzbringend herangezogen. Sinnvollerweise findet der geschilderte "Walk-through" immer nach Abschluß eines definierten Meilensteinpunktes statt und setzt nach dem Überwinden anfänglicher Widerstände, was Beurteilung und Fehlererkennung durch Kollegen betrifft, offene Argumentation und sachliche Diskussionsführung voraus.

Führt man sich dies vor Augen, so wird klar, daß ein derartiger Lösungsweg die notwendige Akzeptanz seitens der betroffenen Mitarbeiter erfordert und nur im Anschluß an einen prinzipiellen Wandel der Arbeitsphilosophie zu vollziehen ist. Die Durchführungsverantwortung in Händen der Projektleitung schafft dabei die Voraussetzungen für eine erfolgreiche Eingliederung des Walk-through-Verfahrens in den ablauforganisatorischen Software-Herstellungsprozeß.

Angesichts der Tatsache, daß der Walk-through einen relativ hohen Einsatz an personellen Ressourcen erfordert, erscheint der Problemlösungsaufwand verhältnismäßig hoch. Er ist jedoch gerechtfertigt, wenn man bedenkt, daß rechtzeitige Fehleraufdeckung eine positive Kostenentwicklung erzielt und eine deutliche Verbesserung der Fehlererkennungsquote mit sich bringt.

Testverfahren bleiben oft an der Oberfläche

Die anderen eingesetzten Verfahren, wie Design-review und Code-inspection sind zwar weniger zeitaufwendig, aber, was die effektive Eindringtiefe in das zu prüfende Erzeugnis anbelangt, durch ihre relative Oberfläche charakterisiert. Design-review beinhaltet die konstruktive Durchsicht der Entwurfsunterlagen mittels eines breit gestreuten Kreises von Reviewern. Code-inspection findet hingegen ihre Ausprägung in einer implementierungsnahen Analyse des Sourcecodes, wobei die resultierenden Anregungen und Hinweise der Prüfer gegebenenfalls ein korrigierendes Redesign erforderlich machen.

SW-Prüfung verifiziert keine Fehlerfreiheit

Kernidee aller oben skizzierten Methoden ist, daß der oder die Entwickler auf der Basis einer allgemeinen Erläuterung ihres Systems zum Nachdenken über die formelle Korrektheit der von ihnen erarbeiteten Lösung gebracht werden. Das entbindet allerdings nicht von der Notwendigkeit, die Funktionsfähigkeit des erstellten Codes anschließend mit Hilfe von Test- beziehungsweise Originaldaten zu verifizieren. Dabei sollte anhand einer Testmatrix gewährleistet sein, daß jeder Strukturblock, jeder Zweig, jede Anweisung des Programms auf Modulebene mindestens einmal durchlaufen wird.

Daraus ist jedoch keine hinreichende Garantie für die Lauffähigkeit des Programms abzuleiten, da die aus der Kombination von Textmatrix und Wertebereichen der Testdaten entstehenden Ablaufmöglichkeiten der Algorithmen sehr schnell astronomische Größen annehmen und somit die 100prozentige Korrektheit eines Systems niemals nachzuweisen wäre. Ein Softwaretest verifiziert ohnehin keinesfalls die Fehlerfreiheit, sondern nur die Mangelhaftigkeit des Systems. Vielfach können die erzielten Ergebnisse einer solchen Analyse, die aufgrund vorgegebener Testdaten gewonnen wurden, auch nur mit fachlicher Unterstützung der zuständigen Fachabteilung und deren sachverständigen Bewertungskriterien oder Urteilsmaßstäben effizient ausgewertet werden.

Ablaufgerechte Simulation sollte Modultests prägen

Kennzeichnendes Prinzip von Modultests ist die ablaufgerechte Simulation der über Daten- und Aufrufschnittstellen verknüpften Systemumgebung. Erst wenn alle Einzelbausteine des Gesamtkomplexes auf diese Weise hinreichend durchgecheckt sind, kann sich das weitere Vorgehen auf den Integrationstests, also das Verhalten aller Routinen in der eigentlichen Ablaufumgebung, konzentrieren. Im Gegensatz zur top-down verlaufenden Realisierung beginnt die Testphase hier auf Modulebene und erstreckt sich in zeitlich abgestufter Folge auf immer komplexere Einheiten bis hin zum übergreifenden Anwendungssystem. Allerdings ist es grundlegend notwendig, beim Testen nicht bereits nach einigen vermeintlichen Erfolgserlebnissen abzubrechen, sondern den nach den oben skizzierten Maßstäben gesteckten Testrahmen in vollem Umfange zu bearbeiten.

Vor dem Hintergrund der oben dargestellten Probleme stellt sich die Frage, inwiefern man sich vermeintliche Last und Aufwand der geschilderten Verfahren für jedes Projekt aufs neue aufbürden muß. Kurzum: Warum überhaupt Softwaretests? Sollte dieser kritische, belastende Prozeß während der Realisierungsphase nicht soweit als möglich minimiert werden?

Unter diesem Gesichtspunkt bietet der Einsatz von Standardprogrammbausteinen und -modulen für immer wiederkehrende, vorab einmalig ausgetestete Basisfunktionen (zum Beispiel Dateneingabe, -ausgabe und Bildschirmmaskenhandling), die anschließend lediglich noch um die anwendungsspezifischen Gegebenheiten ergänzt zu werden brauchen, einen nutzbringenden Lösungsweg - zumal die Verwendung von Softwarestandards auch die übrige Realisierungszeit wesentlich vermindert.

Qualitativer Wandel führt zu mehr Produktivität

Nur auf diese Weise können die gezeigten Instrumentarien einen qualitativen Wandel der Entwicklungsergebnisse herbeiführen, der in einem merklichen Durchgriff auf den Produktivitätsfortschritt mit positiver Kostenwirkung sowie in einer nach haltigen Verbesserung der Qualität resultiert.

Vor diesem Hintergrund sei nochmals klargemacht, daß die angeführten Mechanismen lediglich als Denkansatz für derartige Maßnahmen dienen, aber trotzdem eine praxisbezogene Orientierungshilfe darstellen sollen. Die verstärkte Wettbewerbssituation zwingt Softwarehäuser, -anbieter und -produzenten, jeden sich bietenden effektivitätsorientierten Wirtschaftlichkeitsvorteil für die Bewältigung ihrer Unternehmensaufgabe zu nutzen. Eventualmaßnahmen müssen dabei endgültig einem ausgereiften und durchführbaren Konzept zur Qualitätssicherung weichen.