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.

20.12.1996 - 

Thema der Woche

Das ungeliebte Stiefkind der DV: Testing muß besser werden

Seit 15 Jahren ist die Fehlerrate pro Software-Anwendung nahezu konstant. Daraus zieht der englische Unternehmensberater Les Hatton den Schluß, daß sich auch die Qualität von Softwaretests nicht wesentlich gebessert habe.

Bleibt die Fehlerquote weiterhin unverändert, wird sich die Anzahl der Fehler alle 18 Monate verdoppeln, so Hatton. Denn in diesem Zeitraum wachse auch der Software-Anteil in Produkten auf das Doppelte an. Bereits heute steckten etwa 80000 Zeilen Code in der Autoelektronik und 150000 Zeilen C-Code in Fernsehgeräten.

Trotz der rapide zunehmenden Programmzeilen nimmt nicht die Test- und damit die Produktqualität zu, sondern die Leidensfähigkeit der Anwender. In einem Unix-System treten nach Messungen von Hatton einmal pro Jahr Fehler auf, in 25 Prozent der Fälle ist dabei ein Reboot notwendig. Alle 188 Minuten produziert ein Mac-OS/Office-System Fehler, wobei zu 56 Prozent ein Neustart notwendig wird. Ein Windows-95-System, auf dem "Office" installiert ist, leistet sich alle 42 Minuten einen Fehler und muß dabei zu 28 Prozent neu aufgerufen werden.

PC-Anwender gewöhnen sich an die Bugs

Weil die Anwender, vor allem wohl PC-Benutzer, die miese Qualität inzwischen gewöhnt sind, haben Softwaretester schlechte Karten: Sie stehen unter Zeitdruck, ihnen wird das Budget gekürzt, zumeist kurz vor dem Projektende, es mangelt an Akzeptanz bei den Managern. Übergeben die Prüfer das Produkt termingerecht, werden sie gefeuert, weil die Software miserabel ist wenn das Ergebnis zufriedenstellt, aber zu spät kommt, verlieren sie ebenfalls ihren Job. Laut Hans Schaefer, Unternehmensberater und Gastdozent an verschiedenen norwegischen Universitäten, gibt es nur einen Weg aus dieser Zwickmühle: die Spielregeln ändern.

Manager müßten anders als bisher mit in die Verantwortung einbezogen werden. Dazu gehört es, festzustellen, ob die Anwender innerhalb oder außerhalb des Unternehmens bereit sind, für hochwertige Produkte zu zahlen. Wenn nicht, müssen Abstriche erlaubt sein. Dann heißt es: Nicht flächendeckend testen, sondern nur die Funktionen, die für den Anwender sichtbar sind und für die Akzeptanz der Software sorgen, empfiehlt Schaefer. Die schwersten Fehler sind sofort zu beheben, andere Mängel vielleicht erst im nachfolgenden Release. Außerdem sei zu überlegen, ob nicht sogar Anwender selbst bereit sind, Programmteile zu testen.

Ein solches Denken ist für Klaus Grimm, Senior Manager Correct Systems bei der Daimler-Benz-Forschung Systemtechnik, völlig inakzeptabel. Auch Fritz Langell, Prokurist Konzernstab Organisation IT-Infrastruktur bei der Dresdner Bank, betont, daß in seinem Unternehmen seit langem bessere Verfahren existieren, die die Qualität ihrer Software sichern. Zwar könnten durchaus auch Teilfunktionen freigegeben werden, die nicht im Gesamtkontext und flächendeckend getestet worden seien. Die Voraussetzung dafür aber schafften Tests der Einzelkomponenten sowie eine Anforderung seitens der Kunden.

Es komme darauf an, den Entwicklungsprozeß von einem möglichst frühen Zeitpunkt an zu begleiten. Fehler, die im fast fertigen Produkt oder gar nach Übergabe oder Auslieferung entdeckt und ausgebügelt werden, verursachen Verzögerungen, erhöhte Kosten sowie Image- und Akzeptanzprobleme.

In beiden Unternehmen setzt die Testplanung deshalb bereits mit der Spezifikation (siehe Kasten) ein, parallel zur Programmentwicklung. Ein gutes Pflichtenheft ist eine der besten Präventivmaßnahmen. Es ermöglicht ein Prototyping, das den Ab-gleich mit den Vorstellungen der Anwender erlaubt. Änderungswünsche lassen sich in diesem Stadium eines Projekts noch ohne größere Krisen unter den Programmierern berücksichtigen.

Bereits für Softwaredesign und Systemmodellierung empfehlen sich sogenannte Funktionstests. Bei diesem "Black-box-Testing" sind in jeder Entwicklungsphase vom Beginn bis zur Implementierung und Systemintegration jeweils die einzelnen Module, die Schnittstellen, die Anwendung und das System zu prüfen.

Dabei ist es eine der schwierigsten Aufgaben, auszuwählen, welche Funktionen in welchen Fällen getestet werden müssen, um bei möglichst geringem Aufwand beste Softwarequalität zu erreichen. Daimler-Benz-Cheftester Grimm stellte auf der Konferenz Eurostar, Software Testing Analysis and Review, die kürzlich in Amsterdam stattfand, das Vorgehen in seinem Hause vor. In einer ersten Analyse, in der die Anwendung gewissermaßen von außen betrachtet wird, muß der Tester die funktionalen Komponenten und Gesichtspunkte identifizieren (siehe Abbildung). Die Zuordnung von grundlegenden Eigenschaften und Abhängigkeiten ergibt eine Beziehungsmatrix. Jede Zeile dieser Matrix steht für einen möglichen Testfall. Welcher Fall schließlich durchgespielt wird, hängt davon, ab in welchem Umfang die Teilaspekte voneinander abhängig sind und welche Testtiefe erreicht werden soll. Mit seinem Verfahren erreicht Grimm im Test eine Abdeckung der Programmzweige von 80 bis 100 Prozent.

Testtiefe und -breite ermitteln

Um anderweitig eine Gewichtung der testrelevanten Funktionen vorzunehmen, bieten etwa Punktesysteme Entscheidungshilfen. So lassen sich Punkte für die Komplexität, für die Häufigkeit des Gebrauchs, für Sicherheit oder Benutzerfreundlichkeit eines Systems sowie seine Wettbewerbsrelevanz vergeben.

Daimler-Benz-Experte Grimm begnügt sich nicht mit Funktionstests. Er kombiniert sie mit dynamischen, strukturellen Kontrollen. Dieses "White-box-Testing" reicht bis zur Code-Ebene der Applikation, in die Tester hineinschauen.

Wie Berater Hatton ausführt, finden sich die meisten Bugs in Modulen, die weniger als 50 Codezeilen haben, und in Komponenten, die aus mehr als 250 Zeilen bestehen. Außerdem steige die Fehlerdichte jeweils am Anfang und Ende eines Moduls. Das Phänomen tritt, so Hatton, bei jeder Programmiersprache auf, sowohl in Assembler-Programmen als auch in Ada-, C-, C++-, Fortran-, PL/M- und Cobol- Anwendungen.

Grimms Vorgehen ist universal und nicht nur begrenzt auf technische Lösungen anwendbar. Neben der Klappdach-Steuerung des Mercedes SLK oder einer 2000 C-Module umfassenden Beleuchtungsanlage für die Landebahnen eines internationalen Flughafens testet sein Team auch Verwaltungssoftware für Schulungseinrichtungen. Falls erforderlich, läßt sich das Testverfahren um anwendungsspezifische Prüfungen wie durch Echtzeit- oder Belastungstests ergänzen.

Die Daimler-Benz-Forschung beschäftigt etwa 300 Mitarbeiter im Bereich IT-Forschung. Grimm steht ein 20köpfiges Team zur Verfügung, das sich mit Testen und Spezifizieren befaßt. Damit dürfte das Verhältnis von Testern und Entwicklern besser sein als in den meisten deutschen Unternehmen, in denen häufig überhaupt keine Testabteilung existiert.

"Wir bauchen kein Testing, wir haben Mainframe-Software", bekam die COMPUTERWOCHE auf Nachfrage zu hören, oder "Unsere Entwickler verstehen ihr Geschäft." Oftmals sind noch immer sogenannte "Genies" die bestbezahlten Programmierer. Sie codieren eine Anwendung ohne Design, ohne Dokumentation, ohne Teamsupport und ohne Anwenderbezug. Ein solches Szenario verbannt das Software-Testing ans Ende des Entwicklungszyklus, degradiert es zum kreativitäts- und nervtötenden, lästigen Fehlersuchen. Entwickler langweilen sich dabei, können Testen nicht ausstehen und dürften zugleich betriebsblind sein.

Trotzdem übernehmen auch bei Daimler-Benz Entwickler Testaufgaben, insbesondere bei der dynamischen Analyse. Die Manager-Schelte, die allenthalben auf der Eurostar zu hören war, scheint partiell berechtigt. Während Testen bei technischen Anlagen noch unabdingbar erscheint, glauben Manager offenbar, bei kommerziellen, administrativen Anwendungen sparen zu können.

Testen kostet - zumindest müssen die Unternehmen Vorleistungen erbringen. Analysten wie Dorothy Graham von der englischen Unternehmensberatung Grove Consultants glauben allerdings an einen Return on Investment von bis zu 300 Prozent. DV-Experte Grimm von Daimler-Benz mutmaßt, daß lediglich eine Umverteilung der Kosten stattfindet - vom späten Fehler-Fixing zur Vorbeugung. Das aber würde bedeuten: Eine bessere Software muß nicht zwangsläufig teurer sein.

Für Herbert Dening, Prokurist und Leiter des Referats Testunterstützung bei der West LB, Düsseldorf, muß das Testen von der Entwicklung strikt getrennt und mit einem eigenen Budget ausgestattet sein: "Das Testen ist Qualitätssicherung, die zum Ziel hat, möglichst viele Fehler zu vermeiden und aufzudecken. Sie ist ein kooperativer Prozeß im Zusammenspiel zwischen Test- und Entwicklungsteam." Mit der Testplanung und -vorbereitung, die immerhin 70 Prozent eines Softwaretests ausmachen, beginnt auch Dening, "sobald das Konzept steht". Seine Devise lautet: "Je früher ich damit beginne, desto weniger Fehler werden programmiert, um so früher ist das Produkt fertig."

Vor etwa zweieinhalb Jahren habe er mit diesem Konzept in einem Pilotprojekt den Durchbruch erreicht. Seither bestehe eine größere Nachfrage, als sein Team bewältigen könne. Dening hat derzeit vier Mitarbeiter und arbeitet zusätzlich mit bis zu 20 externen Kräften zusammen, die von der Software Qualitätssicherungs GmbH, Köln, kommen. Den Datumswechsel zum Jahr 2000 und die Euro-Umstellung sieht er als Te- sting-Spezialfälle, die unter anderem einen Mehrbedarf an Softwareprüfern erfordern.

Spätestens wenn die Reform des europäischen Währungssystems und die Rechenoperationen im Zusammenhang mit dem Milleniumswechsel ins Blickfeld rücken, dürfte klar werden, daß Testen auch mit Legacy-Systemen, Mainframe-Programmen, Wartung und Pflege zu tun hat.

Unternehmensberater Harry Sneed schlüsselte diesen Bereich für die Eurostar-Besucher etwas auf. Rund 82 Prozent der Software, die weltweit in Unternehmen eingesetzt wird, ist Host-basiert. Sie hinkt demnach zwei bis drei Generationen dem aktuellen Stand hinterher. Typischerweise sind die Anwendungen in Cobol programmiert, manchmal strukturiert, in den meisten Fällen jedoch monolithisch aufgebaut und mit einer hierarchischen Datenbank wie IMS verbunden. Sie umfassen in der Regel 20 bis 80 Programme und laufen mit Online-Transaktionsmonitoren oder im Batch-Betrieb mit Hilfe von Job-Control-Prozeduren.

Das wäre soweit noch kein Problem, wenn die Programme auf diesem Stand gewissermaßen eingefroren wären. Doch das sind sie nicht. Jedes Legacy-System erfährt jährlich Änderungen von fünf bis zehn Prozent des gesamten Umfangs. Alle sechs Monate, laut Sneed in manchen Unternehmen sogar jedes Vierteljahr, nehmen die Betriebe einen entsprechenden Release-Wechsel vor. Demnach müßten sie mindestens zwei- bis viermal pro Jahr auch entsprechende Tests fahren. Sta- tistiken zeigten, daß auf diese Weise mindestens 40 Prozent des Aufwands für Software-Main- tenance-Leistungen, die durchschnittlich etwa 50 bis 75 Prozent des IT-Budgets verschlängen, ins Testen flössen.

Leider sind in der Praxis die Bedingungen für ein effizienteres Testen insbesondere für Legacy-Systeme schlecht. Es fehlen Dokumentationen und häufig sogar der Sourcecode der Applikationen. Doch mit dem Prüfen der geänderten Module ist es nicht getan. Wie die Jahr-2000-Problematik zeigt, sind viele Teilprogramme, Speicheradressen, Ein- und Ausgabeparameter sowie Algorithmen nicht einmal unmittelbar einsehbar miteinander verknüpft. Die Verbindungen werden häufig erst im Echtbetrieb oder beim Testen sichtbar.

Potentiale, die Tests effektiver zu machen, liegen nach Meinung von Experten dagegen in guten organisatorischen Voraussetzungen, Methoden und in der Automatisierung. Wie Dening erläutert, gehen seine Tester immer gleich vor. Dabei sei es unerheblich, ob es sich um Prüfungen von Neuentwicklungen oder von Legacy-Anpassungen handle. Auf diese Weise müßten lediglich 20 Prozent eines Tests gänzlich neu erstellt werden, da sich Bestandteile früherer Prüfungen wiederverwenden lassen.

Testautomatisierung spart Kosten

Der Einsatz von Tools, von denen es mittlerweile eine breite Vielfalt gibt (siehe Kasten "Tips für Test-Tools"), trägt zur Transparenz von Tests und zur Automatisierung bei. Allerdings gibt es weder ein Werkzeug, das sämtliche Testphasen abdeckt, noch genormte Schnittstellen, so daß sich die verschiedenen Tools von unterschiedlichen Anbietern nicht problemlos miteinander verknüpfen lassen.

Außerdem sind die Werkzeuge mittlerweile selbst komplex. Die Unternehmensberatung und Marktforschungsorganisation Standish Group setzt die Einarbeitungszeit so hoch an wie bei einem Tool für das Rapid Application Development (siehe Abbildung).

Der Einsatz von Tools muß vorbereitet sein

Wie sehr der Einsatz von Testing-Tools danebengehen kann, wenn die Testorganisation nicht stimmt, dokumentierte Stîle Amland vom Softwarehaus Avenir A.S., Oslo, das dem norwegischen Softwarehaus Provida beim Test einer neuen Bankensoftware half. Zwar habe sich Provida schon früh für eine partielle Automatisierung entschieden, das Tool jedoch zu spät eingekauft. Außerdem mußten alle Tester dieselbe Datenbank benutzen, so daß sie sich zum Teil ihre Ergebnisse gegenseitig überschrieben.

Rund 25 Prozent der Ressourcen für das Online-Testing wurden für Tool-gesteuerte Kontrollen benötigt. Dabei ließen sich jedoch nur 15 Prozent der Online-Transaktionen überprüfen. Entdeckt hat das Team lediglich 2,5 Prozent der Fehler.

Allzu Menschliches

Der Alptraum eines jeden IT-Managers: Erst geht alles glatt. Dann plötzlich, beim Testen, bricht das Chaos aus. Nichts läuft mehr so, wie es soll. Tom DeMarco, der im kommenden Jahr den IEEE-Award for Services bekommen soll, machte der Testing-Gemeinde auf der Eurostar einmal mehr deutlich: Testen allein garantiert den Projekterfolg nicht. Auch Organisation und zwischenmenschliches Klima müssen stimmen.

Jedesmal, wenn ein IT-Projekt aufgesetzt wird, gewinnt und verliert jemand Macht zum Beispiel wird eine zentrale Struktur zugunsten einer dezentralen aufgelöst. Diejenigen, die Einfluß einbüßen, sind prädestinierte Gegner des neuen Systems.

Leidtragender ist beispielsweise derjenige, der die Anwendungsspezifikation zu verfassen hat. Er steht zwischen rivalisierenden Parteien, von denen jede möglichst viel Einfluß haben will: Wer erhält die Aufsicht über welches System, wer kontrolliert den Drucker, wem gehören die Daten? Werden diese Konflikte nicht im Vorfeld gelöst, gerät die intendierte Spezifikation zum Geschwafel, das die Probleme lediglich zukleistert. Softwaredesigner kritisieren das häufig umfassende Werk deshalb nicht, weil sie es nicht verstehen und sich nicht trauen, dieses zuzugeben. "Seien Sie doch mal ehrlich. Ganz tief in unserem Inneren sitzt die Angst, daß wir leider nur mit normaler Intelligenz ausgestattet sind", sagte DeMarco.

Doch auch beim Design werden Organisationsfehler gemacht. Einer der häufigsten besteht darin, zu viele Mitarbeiter mit der Aufgabe zu betrauen. Der Grund dafür: übergroßer Zeitdruck. Allerdings denken Menschen unter Zeitdruck weder schneller, noch denken viele automatisch besser. Maximal fünf Personen sollten sich laut DeMarco der Aufgabe widmen.

Auch Mutmachen und Schulterklopfen bringen ein Projekt nicht vorwärts. Wenn nur noch der Chef von dem Projekt begeistert ist, läuft etwas falsch. Um den Fortschritt zu messen, gibt es laut DeMarco nur eine Möglichkeit: die Metrik, die sich aus dem Bauplan der Anwendung ableiten läßt.

Tips für Test-Tools

Allein die Vergleichsstudie der britischen Ovum Ltd., London, zu Testing-Tools, Stand November 1996, stellt mehr als 20 verschiedene Produkte vor. Die Bloor Research Group, Bletchley, bietet unter dem Titel "Cast Tools, An Evaluation and Comparison" ebenfalls eine Studie an, die 19 Produkte miteinander vergleicht. Sie ist zirka ein Jahr alt. Weniger ausführlich, doch breiter in der Streuung ist der "Computer Aided Software Testing Report" (Cast) von der Londoner CMI Ltd. Der mittlerweile elektronisch abrufbare Katalog (salescmi.co.uk) enthält Beschreibungen 150 verschiedener Produkte.

Dorothy Graham, mittlerweile Chefin von Grove Consults im britischen Macclesfield, initiierte den ersten Cast-Katalog vor etwa drei Jahren. Der COMPUTERWOCHE erläuterte sie, in welche Kategorien sie die Testprodukte einteilt: Zunächst gibt es Tools, die das Test-Management unterstützen, dann welche für das logische Testdesign sowie für das physikalische, zum Beispiel für Testimplementierungen in der Datenbank. Außerdem lassen sich Hilfen sowohl für die statische als auch für die dynamische Analyse finden, sowie Werkzeuge, mit denen die Prüfer die Testabdeckung messen können. Der Debugger dürfte das am besten akzeptierte Tool sein. Daneben stehen heute aber auch Produkte für Workflow-, Performance- und Auslastungstests zur Verfügung sowie solche zur Simulation und Testdatenerstellung. Schließlich muß jeweils die Ausführung der Tests überwacht werden, und es gibt Hilfsmittel, die die Tests untereinander und mit der Anwendung vergleichen können. Tools zum sogenannten Defect Tracking, dem Aufzeichnen von Fehlerfällen und ihrer Behebung, runden das Bild ab.

Im Kommen sind derzeit Capture-Replay-Werkzeuge. Sie finden in Client-Tests Verwendung. Die Aktionen eines simulierten oder "echten" Users werden festgehalten. Daraus entsteht ein Testskript, das jederzeit als Test ausgeführt werden kann.

Testskripts lassen sich aber auch manuell erstellen. Der Nachteil besteht darin, daß dieses Vorgehen umständlicher ist und leicht etwas übersehen werden kann. Allerdings lassen sich die Skripts bereits schreiben, wenn die Anwendung noch gar nicht steht. Das ist der Vorteil.