Wann hat das Testen ein Ende?

Die entscheidende Frage während der Testphase eines Produkts lautet: Wann kann man mit dem Testen aufhören, so dass das Produkt freigegeben werden kann? Viele Softwarehersteller haben Schwierigkeiten damit, den «rechten» Moment zu bestimmen, zu dem sie ihre Softwareprodukte freigeben sollen. Es ist immer ein Kompromiss zwischen einer frühen Freigabe, um die Vorteile einer rechtzeitigen Markteinführung zu nutzen, und einem Hinausschieben der Freigabe, um die Funktionalität noch zu erweitern oder die Qualität zu verbessern. Es gibt zwar eine Reihe von Modellen zur Messung der Zuverlässigkeit von Software, um bei dieser Abwägung zu helfen, aber welchen praktischen Nutzen haben diese und werden sie überhaupt eingesetzt?

Testen: kein triviales Unterfangen

Obwohl Software anderen physischen Prozessen nicht unähnlich ist, bei denen Eingaben getätigt und Ausgaben erzeugt werden, so unterscheidet sie sich doch in der Art und Weise, wie Fehlfunktionen aussehen. Und dies hat Auswirkungen auf die Verifizierung und Validierung:



- Das Aufspüren und Beseitigen von Designfehlern in Software ist kompliziert, denn im Unterschied zu den meisten physischen Systemen wie z.B. Hardware beruhen Softwaredefekte nicht auf Herstellungs-, sondern auf Designfehlern, die schwieriger zu visualisieren, zu klassifizieren, aufzuspüren und zu korrigieren sind. Dies gilt gleichermassen hinsichtlich der Zuverlässigkeit.

- Das Aufspüren und Beseitigen von Designfehlern in der Software ist schwierig, weil die Kombinationsmöglichkeiten der Eingaben von Tausenden von Benutzern bei einer bestimmten Benutzeroberfläche einfach zu zahlreich sind, als dass Tester sie alle in Betracht ziehen könnten. Theoretisch müssten sämtliche möglichen Werte getestet und verifiziert werden. Ein vollständiges Testen ist allerdings nicht realistisch. In der Praxis gibt es bei Softwareprogrammen eine Vielzahl unterschiedlicher Eingabewerte, bei denen Timing, unvorhersehbare Umgebungseffekte sowie Benutzerinteraktionen für eine quasi unendliche Zahl von unterschiedlichen Input-Kombinationen sorgen. Tests können hier zwar auf effektive Weise das Vorhandensein von Fehlern aufdecken, aber kaum deren Abwesenheit belegen.



- Ein weiterer Faktor, der die Sache kompliziert macht, liegt in der dynamischen Natur von Software begründet. Falls ein Fehler beim Testen von Version n der Software auftritt und der Code geändert wird, kann es sein, dass die neue Softwareversion n+1 jetzt für die Testfälle funktioniert, an denen sie vorher gescheitert war. Aber ihr Verhalten für andere Testfälle, die vor dem Auftreten des Fehlers erfolgreich durchgeführt wurden, ist damit nicht notwendigerweise garantiert. Ein bestimmter Fix kann (a) immer nur das jeweilige erkannte Problem beheben, (b) beim Beheben des Problems scheitern, (c) das Problem beheben, aber etwas anderes beschädigen, was vorher funktionierte, oder (d) beim Beheben des Problems scheitern und gleichzeitig etwas anderes beschädigen. Um all diese Möglichkeiten in Betracht zu ziehen, sollten alle Tests noch einmal von Anfang an durchgeführt werden. Allerdings bedeutet dies häufig einen enormen Kostenaufwand. Daher stellt sich die Frage, in welchem Umfang Wiederholungstests (Regressionstests) von Version n+1 mit Tests von Version n erforderlich sind.




Unabhängig davon, wie der Testprozess organisiert ist und wie Testfälle ausgewählt werden: Irgendwann stellt sich die Frage, wie zuverlässig das Softwareprodukt ist, wie lange die Software laufen wird, ehe es zu einem Ausfall kommt, und wie teuer die Wartung der Software werden wird. Zuverlässigkeit, definiert als die Wahrscheinlichkeit, dass ein Produkt unter gegebenen Bedingungen für einen bestimmten Zeitraum ohne Ausfälle funktioniert, ist eine wichtige nicht funktionale Anforderung, die berücksichtigt werden muss, wenn man die oben erwähnte Abwägung zur Freigabe der Software durchführt. Falls man mit dem Testen als letzte Projektstufe zu früh aufhört, könnte die Software mit schweren Fehlern an die Benutzer ausgeliefert werden, was für den Softwarehersteller Kosten für die nachträgliche Fehlerbehebung mit sich bringt. Falls zu lange getestet wird, können die damit verbundenen Kosten sowie die Opportunitätskosten sehr hoch ausfallen.

Modelle zur Zuverlässigkeit von Software

Welche Art von Modellen gibt es, um die Entscheidungsfindung zwischen «jetzt freigeben» und «weiter testen» zu unterstützen? Im Prinzip gibt es zwei Arten von Modellen zur Zuverlässigkeit von Software:



- Modelle zur Vorhersage der Zuverlässigkeit von Software kümmern sich schon früh im Lebenszyklus der Software um deren Zuverlässigkeit, nämlich auf der Anforderungs-, Design- und Implementierungsstufe, wobei auf historische Vergleichsdaten zurückgegriffen wird. Die Zuverlässigkeit wird beispielsweise mit Hilfe von Fehlerdichtemodellen prognostiziert, wobei bestimmte Code-Charakteristika wie die Anzahl der Codezeilen und das Verschachteln von Schleifen herangezogen werden, um die Zahl der Fehler der Software zu schätzen.

- Modelle zur Einschätzung der Zuverlässigkeit von Software berechnen die aktuelle und künftige Zuverlässigkeit aufgrund tatsächlicher Fehler, beginnend mit der Integrationsphase oder den
Systemtests der Software. Die Einschätzungen basieren dabei auf Testdaten. Diese Modelle versuchen, eine statistische Korrelation zwischen entdeckten Fehlern und bekannten Funktionen, beispielsweise einer Exponentialfunktion, herzustellen (vgl. Tabelle).




Unterschiede zwischen Vorhersage- und Einschätzungsmodellen

Vorhersage- versus Einschätzungsmodelle

Modelle zur Einschätzung der Zuverlässigkeit von Software prognostizieren die Kurve der Ausfallrate aufgrund statistischer Daten. Die Ausfallrate nimmt normalerweise ab, weil Fehler entdeckt und behoben werden. Zu jedem Zeitpunkt (aktueller Zeitpunkt) ist es möglich, die zugehörige Ausfallrate zu ermitteln (aktuelle Ausfallrate) (siehe Grafik).




Modell zur Zuverlässigkeitsschätzung

Grundlegendes Modell zur Zuverlässigkeitsschätzung

Theoretisch bieten die vorgestellten Modelle zur Einschätzung der Zuverlässigkeit von Software nicht nur die Möglichkeit, den optimalen Zeitpunkt für die Freigabe der Software zu bestimmen, sondern man kann damit auch die Auswirkungen von Einschränkungen hinsichtlich Zeit oder Budget ermitteln.


Wenn ein Softwarehersteller sich einer zeitlichen Beschränkung gegenübersieht (fester Liefertermin) oder einem begrenzten Budget (beschränkte Kosten), ist es möglich, basierend auf dem Grad an Zuverlässigkeit zum Zeitpunkt der Freigabe, Vorhersagen hinsichtlich der Betriebskosten zu treffen.
Ein Softwarehersteller kann es auch mit Vorgaben hinsichtlich der Zuverlässigkeit zu tun haben (Anforderungen hinsichtlich einer minimalen Zuverlässigkeit). Hier können ihm diese Modelle dabei helfen, den Zeitaufwand und die Testkosten für die Erfüllung dieser Anforderungen sowie die zu erwartenden Betriebskosten nach der Produktfreigabe zu ermitteln.
Allerdings sehen sich die Modelle zur Einschätzung der Zuverlässigkeit von Software auch schwerer Kritik ausgesetzt, die sich vor allem auf die beiden folgenden Aspekte bezieht:




- Erstens gehen die meisten Modelle von einer Funktionsweise aus, die mit der Realität nicht in Einklang steht, was bedeutet, dass die Grundannahmen nicht besonders zuverlässig sind. Daher können unterschiedliche Modelle zu drastisch abweichenden Ergebnissen für dieselben Ausgangsdaten führen, was die Gültigkeit der Prognosen erheblich einschränkt. Weil keine zwei Modelle zu exakt denselben Ergebnissen führen, sollte man sorgfältig darauf achten, für ein bestimmtes Projekt das Modell auszuwählen, das am besten geeignet ist, wobei den Ergebnissen nicht allzu viel Gewicht beigemessen werden sollte. Ausserdem sind die Modelle bei Software, die nur wenig verändert wurde, recht zuverlässig in ihren Aussagen, bei neuen, innovativen Softwareprodukten hingegen eher weniger aussagekräftig.



- Zweitens haben Forschungsergebnisse zu den Modellen, die am häufigsten verwendet werden, viele Unzulänglichkeiten aufgedeckt. Daher bieten diese Modelle wenig Hilfestellung, die Zuverlässigkeit eines Softwareprodukts zu ermitteln. Diese Studien zeigen auch, dass die Zahl der vor der Freigabe aufgespürten Fehler kein zuverlässiger Indikator für die Anzahl der Fehler ist, die erst nach der Freigabe entdeckt werden. Das Problem besteht darin, dass viele Softwarehersteller die Zahl der Fehler, die vor der Freigabe aufgespürt werden, als Massstab für die Anzahl der Fehler nehmen, die erst nach der Freigabe entdeckt werden, also für die Zuverlässigkeit des fertigen Produkts.

Gesamt-Lebenszyklus-Kosten

Darüber hinaus bestehen noch zwei Einschränkungen höherer Ordnung hinsichtlich solcher Modelle:




- Der Fokus liegt auf den Kosten, nicht auf dem Gewinn. Die Modelle berücksichtigen nur Kosten, wobei sie davon ausgehen, dass die Minimierung der Gesamtkosten das Hauptziel ist. Aber in gewinnorientierten Umgebungen, beispielsweise dort, wo Softwarehersteller Produkte an ihre Kunden verkaufen, sollten die zu erwartenden Einnahmen ebenfalls Berücksichtigung finden. In diesem Fall würde der optimale Zeitpunkt für die Markteinführung nicht durch die Minimierung der Gesamtkosten bestimmt werden, sondern durch die Maximierung der Differenz zwischen Einnahmen und Ausgaben, also der Maximierung des wirtschaftlichen Ergebnisses. Und nur wenige dieser Modelle berücksichtigen, dass auch Zeit Geld ist.



- Der Fokus liegt auf den Kosten für die Tests vor der Freigabe ver­glichen mit den Kosten für nachträgliche Korrekturen nach der Freigabe anstatt auf den Gesamtkosten. Wenn man die Gesamt-Lebenszyklus-Kosten eines Softwareprodukts in Betracht zieht, sollte der Fokus nicht nur auf den kurzfristigen Betriebskosten für die Behebung von Fehlern liegen (Kosten für korrigierende Wartung), sondern auch auf den zu erwartenden künftigen Kosten für die Erweiterung des Produkts um zusätzliche Funktionalität (Kosten für adaptive und perfektionierende Wartung). Wichtige Faktoren, welche die langfristigen Wartungskosten beeinflussen, sind etwa die Qualität des Produktdesigns (in welchem Masse bereits auf eine gute Wartbarkeit geachtet wurde), die Qualität der Produktrealisierung (in welchem Masse diese Wartbarkeitsanforderungen auch korrekt implementiert wurden) sowie die Qualität der zugehörigen Produktdokumentation (in welchem Masse das Produkt ausreichend dokumentiert ist, z.B. Spezifikationen, Design, Code, Testfälle, Build-Prozeduren).




Der Löwenanteil der Ressourcen bei vielen Softwareherstellern wird für die Wartung der Software in Anspruch genommen. Studien zeigen, dass die Wartungskosten zwei- bis viermal so hoch sein können wie die ursprünglichen Entwicklungskosten des Systems, wobei dieser Faktor sogar noch zunimmt. Der hohe Anteil der Lebenszykluskosten, der für die Wartung aufgewendet werden muss, hebt noch einmal hervor, wie wichtig die Wartbarkeit eines Softwareprodukts ist (wobei diese definiert ist als die Wahrscheinlichkeit, dass für einen bestimmten Anwendungsfall eine Wartungsaktivität innerhalb eines festgelegten Zeitraums ausgeführt werden kann, unter Verwendung festgelegter Prozeduren und Ressourcen), besonders bei der Erstentwicklung und -freigabe. Die Freigabe von Software, die schwierig zu warten ist, kann zu unerwartet hohen nachträglichen Kosten für korrigierende Wartung sowie für adaptive und perfektionierende Wartung führen, wobei die Software bald an ihre Grenzen stossen wird. Dies ist eine weitere nicht funktionale Anforderung, die in Betracht gezogen werden muss, wenn man abwägt, ob eine Software freigegeben werden kann.

Fallstudien

Wie ermittelt man nun in der Praxis geschätzte Werte hinsichtlich der Zuverlässigkeit und Wartbarkeit einer Software? Hierzu wurden sieben Fallstudien durchgeführt, um herauszufinden, wie Softwarehersteller ihre Entscheidungen bezüglich der Freigabe strategischer Softwareanwendungen treffen. Die ausgewählten Umgebungen unterschieden sich hinsichtlich der Art des Softwareherstellers (individuelle, intern entwickelte Systeme im Vergleich zu kommerzieller Software), der entwickelten Produktversion (neues Produkt im Vergleich zu neuer Version eines bestehenden Produkts) sowie der Ausgereiftheit der Prozesse (von CMMI-Grad 1 bis 3).


In allen Fällen wurde die Zuverlässigkeit vor der Freigabeentscheidung beurteilt. Modelle zur Vorhersage und Einschätzung der Zuverlässigkeit von Software wurden nicht verwendet, und in keinem Fall konnte die erzielte Zuverlässigkeit quantifiziert werden. In keinem Fall wurde die Wartbarkeit des Produkts vor der Freigabeentscheidung beurteilt. Diese fand überhaupt keine Berücksichtigung und wurde auch nicht quantitativ ausgedrückt. Nur in einem Fall wurde belegt, dass die detaillierten Design- und Programmierrichtlinien befolgt wurden, was implizit zu einer hohen Wartbarkeit des Produkts beitrug.



Dies führt zu zwei wichtigen Schlussfolgerungen: Zum einen ist die Schätzung der nachträglichen Betriebskosten für kurzfristige korrigierende Aktivitäten sowie für langfristige Produkterweiterungen vor der Freigabeentscheidung eine schwierige Aufgabe, vor allem, weil es problematisch ist, den Grad der erreichten Zuverlässigkeit sowie der Wartbarkeit des Softwareprodukts exakt zu bestimmen. Zum zweiten konnten in keinem der betrachteten Fälle der zu erwartende nachträgliche Wartungsaufwand und/oder die entsprechenden Betriebskosten quantifiziert werden:



- Der Grad der Zuverlässigkeit war ungewiss, was es schwierig machte, die zu erwartende Zahl der erst nachträglich entdeckten Fehler (präzise) zu schätzen.



- Durchschnittsaufwand und entsprechende Kosten für die Korrektur eines Fehlers waren kaum bekannt. Das bedeutet, dass selbst bei einem quantifizierbaren Grad der Zuverlässigkeit die korrigierende Wartung schwer zu beziffern sein würde.



- Die Wartbarkeit des Produkts war im Prinzip unbekannt, was es schwierig oder gar unmöglich machte, zu bestimmen, in welchem Masse und zu welchen Kosten ein Produkt in Zukunft weiter angepasst oder perfektioniert werden kann.
Dies führt häufig zu Situationen, in denen Software in unausgereiftem Zustand ausgeliefert wird, was schwere nachträgliche Probleme mit sich bringen kann. Die Fallstudien ergaben, dass die folgenden nicht analytischen Methoden (oder eine Kombination aus ihnen) zum Einsatz kamen, wenn es darum ging, zu entscheiden, ob ein Softwareprodukt «gut genug» für die Freigabe ist:



- Ein «ausreichender» Prozentsatz von Testfällen wurde erfolgreich absolviert.


- Statistische Daten werden darüber erhoben, welcher Code während der Durchführung einer Test-Suite ausgeführt wird.


- Defekte werden klassifiziert und Zahlen und Trends werden analysiert.


- Tatsächliche Benutzer führen Betatests durch und melden Probleme, die dann analysiert werden.


- Entwickler analysieren die Anzahl der gemeldeten Probleme in einem bestimmten Zeitraum. Sobald sich diese Zahl stabilisiert oder unter einen bestimmten Schwellenwert fällt, gilt die Software als «gut genug».

Fazit

Bei der Entscheidung über die Freigabe einer Software geht es um ein Abwägen, wobei das Ziel (theoretisch) die Maximierung des wirtschaftlichen Gewinns ist. Faktoren bei einer solchen Frei­gabeentscheidung sind die zu erwartenden Kosten und Einnahmen in Verbindung mit der Produktfreigabe. Wann sollte ein Produkt freigegeben werden? Welches Marktfenster gibt es? Welches sind die Erwartungen von Verbrauchern und Endbenutzern? Diese Reihe von Fallstudien hat ergeben, dass in den meisten Fällen die Intuition vorherrscht, während eigentlich ökonomischer Verstand und stichhaltige Informationen vonnöten wären. Denn die Intuition allein reicht nicht aus, um zu entscheiden, wann eine Software freigegeben werden kann, besonders in Fällen, bei denen die Gefahr grosser finanzieller Verluste für den Softwarehersteller sowie für Kunden und Benutzer besteht.

Der Autor

Hans Sassenburg ist Geschäfts-
führer der Software Improvement Group AG (h.sassenburg@sig.eu).