computerwoche.de

Archiv

Gute Tests sind eine Frage des Projekt-Managements

Beim Softwaretest bleibt vieles dem Zufall überlassen

19.12.1997

"Wenn nichts mehr hilft, heißt es, den Projektleiter killen und selber übernehmen", schloß Meindert Munnik, Consultant bei Maintain Software Management aus dem niederländischen Zeist, kürzlich seinen Vortrag auf der Testing-Konferenz "Euro Star" in Edinburgh. Wie sich das Chaos lichten läßt, beschrieb Munnik anhand eines Nato-Projekts.

Scheint ein solches Projekt, an dem von 1994 bis Juni 1997 immerhin zehn Staaten teilnahmen, auf den ersten Blick exotisch, so gleichen die aufgetretenen Schwierigkeiten doch in erheblichem Maße den Problemen, mit denen sich Tester in nahezu allen Unternehmen herumschlagen müssen: Zeitdruck, knappe Ressourcen, unterschiedliche Auffassungen von Qualität, das Arbeiten mit verschiedenen Werkzeugen, das schnelle Altern neuer Technologien, unzureichende Standards, die Notwendigkeit, Softwarepakete einzubinden sowie Abstimmungs- und Kommunikationsprobleme, die sich im Zuge der Globalisierung noch verstärken und um kulturelle Unterschiede angereichert werden.

Ziel des Nato-Projekts, das von den europäischen Streitkräften getragen wurde, war es, die verschiedenen Informationssysteme, Kommandos und Steuerungsmechanismen so in Übereinstimmung zu bringen, daß sie miteinander kommunizieren können. Dabei sollte sowohl nationale Software eingebunden werden als auch viel Standardsoftware.

Organisatorisch wurde die Projektarbeit aufgeteilt in ein Steuerungsgremium und in vier international besetzte Arbeitsgruppen, die sich mit der Architektur, der Datenmodellierung, dem Daten-Management und der Präsenta- tion beschäftigten. Hinzu kamen eine Delegations- und Projekt-Management-Gruppe sowie ein Testteam. Dieses gliederte sich in eine Test-Management-Gruppe, die für die Teststrategien und die Koordination zuständig war, eine Gruppe, die damit beauftragt war, Testspezifikationen zu schreiben, sowie internationale und nationale Gruppen, die die Tests abwickelten. Anhand eines Kriterienkatalogs sollten die einzelnen Nationen zunächst jeweils Prototypen erstellen, die getrennt voneinander überprüft wurden.

Wie in heutigen DV-Projekten üblich, wurde bei der Spezifikation der Anforderungen an das Nato-Vorhaben hauptsächlich Wert auf die Funktionalität gelegt, andere Charakteristika wie Benutzerfreundlichkeit und Wartbarkeit jedoch vorerst vernachlässigt. Diese Priorisierung kann laut Munnik dazu führen, daß das Endprodukt zwar reichhaltig mit Funktionen und Features gespickt, aber dennoch unbrauchbar ist. Als Grundlage für die "weichen Kriterien" diente schließlich die ISO-Erweiterung "Modell 9126" mit seinen elf Attributen.

Erfolgreiches Testen und damit die Produktqualität hängen von der richtigen Einschätzung ab, welche Eigenschaften entscheidend für den Erfolg und welche vernachlässigbar sind.

Letztere brauchen nicht intensiv überprüft zu werden. Das Nato-Team kalkulierte auch Zeit für "Schönheitsoperationen" ein. "Doch um die Wahrheit zu sagen", so Munnik, " haben wir niemals auch nur eines dieser Qualitätsziele erreicht. Nie bleibt am Ende eines Projekts Zeit dazu."

In der Risikoanalyse mußten zunächst die zu testenden Subsysteme identifiziert und definiert werden. Diesen ließen sich Qualifikationsmerkmale und -indikatoren zuschreiben. Erst dann können die Tester die Prüfmethoden und -techniken festlegen.

Das Nato-Projekt startete mit zwei Brainstorming-Sitzungen. Das Ergebnis der mühsamen Debatten war eine Tabelle, die die Subsysteme benannte und festhielt, wo die entsprechenden Anforderungen dokumentiert waren. Darüber hinaus enthielt sie eine Wertung über die Wichtigkeit der Teilsysteme und benannte die Gruppe, die für dieses Segment zuständig war. Auf diese Weise ließen sich jedem Subsystem Qualitätsmerkmale zuordnen. Gleichzeitig plante man die Meilensteine für die Tests und legte den zeitlichen Rahmen fest.

Jeder Durchlauf begann mit nationalen Tests, schloß internationale koordinierte Ferntests an, gefolgt von "On-site"-Tests, in denen auch vor Ort alle Systeme integriert überprüft wurden. In einer Evaluationsphase wurde der Projektfortschritt festgehalten. Obwohl jedem Subsystem das ISO-Modell zugrunde lag, brauchte das Nato-Projekt allein drei Monate, bis die Teilergebnisse verknüpft waren.

Nicht nur die Erfahrungen aus dem durch politische und kulturelle Differenzen erschwerten Nato-Projekt zeigen, daß das Testen von Software bis zu 50 Prozent des gesamten Entwicklungsaufwands ausmachen kann. Watts Humphrey vom Software Engineering Institute der Carnegie Mellon University, Pittsburgh in Pennsylvania, verwies etwa auf die Entwicklung des Microsoft-Betriebssystems Windows NT, die rund fünf Jahre in Anspruch nahm. Der Auslieferungstermin mußte gleich mehrmals verschoben werden. In einem Jahr während der Testperiode fanden und behoben 250 Software-Ingenieure zirka 30 000 Fehler. Somit dauerte es im Durchschnitt 16 Stunden, bis ein Softwarefehler beseitigt war. Humphreys Fazit lautet: Neu schreiben wäre billiger gewesen - vorausgesetzt, die Entwickler hätten seine Engineering-Methode* eingesetzt. Der Hochschullehrer behauptet, daß damit bereits beim Entwickeln bis zu 80 Prozent aller Fehler gefunden und vermieden werden können.

Testen, so seine These, könne niemals die effektivste Methode sein, Software fehlerarm zu bekommen. Dafür müßten sämtliche Kombinationsmöglichkeiten eines Programms durchgespielt werden. In seinem Rechenbeispiel, dem 59 Lines of Code (Loc) zugrunde liegen, würden entsprechende Tests 67 logische Fälle abdecken müssen, 368 logische Pfade und 65538 Variablen. Man stelle sich das mit 10000 Loc, 100 Modulen und 10 Konditionen pro Modul vor, so Humphrey. 10100 mögliche Kombinationen machten nachvollziehbares Testen unmöglich.

Dabei erscheinen die meisten Softwarefehler vergleichsweise harmlos. Von 38 Fehlern, die Anwender eines Chikagoer Telekommunikationsgeräteherstellers fanden, waren lediglich fünf logischen Ursprungs und auf Mängel im Produktdesign zurückzuführen. Sechs beruhten darauf, daß Anforderungen übersehen worden waren, und 27 entpuppten sich als schlichte Implementierungs-Bugs.

Testen konzentriert sich in den meisten Unternehmen noch immer auf diese Codierungsfehler und fängt erst mit dem Kompilieren an. Der Compiler jedoch ist kein Testwerkzeug. Um semantische Codefehler aufzuspüren, müßten etwa Debugger eingesetzt werden.

Der effiziente Einsatz von Testwerkzeugen setzt aber voraus, daß Testroutinen als feste Bestandteile der Entwicklung im Unternehmen implementiert sind. Erst dann werden Aufgaben des Testprozesses wiederholbar und automatisierbar. Zwar nimmt in den vergangenen Jahren die Zahl der Unternehmen zu, die das Testen in diesem Sinn systematisieren wollen, doch scheint sich kein Konsens über Vorgehensweise und Organisation einzustellen. Im Endergebnis unterscheidet sich beispielsweise das Nato-Projekt allerdings kaum von Testverfahren für kommerzielle Software-Entwicklung in der Wirtschaft.

Die Erfahrung, daß sich Testteile wiederverwenden lassen und übertragbar sind, nutzt etwa die Rolls-Royce-Tochter Seas, Derby. Sie bietet Testing als Dienstleistung zum Festpreis an. Doch mit einem der am meisten unterschätzten Probleme hat laut Paul Raistrick, Senior Software Engineer bei Seas, auch das Outsourcing-Unternehmen zu kämpfen. 90 Prozent aller Probleme beim Aufbau des Testplans und -designs entstammen Defiziten in der Projektdokumentation. Fachbereiche sprechen eine andere Sprache als Entwickler und die eine andere als Tester.