Das 37. Jahr

Die einfachste Metrik ergibt sich noch immer aus dem PTR. Das steht für Problem Tracking Report. Dabei werden die gefundenen Probleme mit einigen Zusatzinformationen in einer Datenbank erfasst. Welche Zusatzinformationen hier nötig sind, wird in einem späteren Artikel erläutert.

Heute interessiert uns nur das Auftreten des Problems, das Datum und der Schweregrad. Natürlich sind Projektidentifikation und nähere Problembeschreibung der eigentliche Hinweis darauf, was mit dem Problem zu geschehen hat. Doch im Sinne der Metrik ist das Datum und der Schweregrad ausreichend.

Erfassen wir die auftretenden Probleme kumulativ, was sich leicht bewerkstelligen läßt, so lassen sich die kumulierten Probleme über einer Zeitachse auftragen. Eine Skalierung in Wochen erscheint zweckmäßig. Bei dieser Erfassung werden weder Feiertage noch unterschiedliche Testbelegschaften berücksichtigt.

Aus der Kurve lässt sich ziemlich viel über die Güte eines Projektverlaufes aussagen. Sie wird umso wichtiger, je größer die Projekte sind. Wenn wir von einer Programmgröße von 2000 Function Points ausgehen (das könnten 100 000 C++ Lines of Code sein) , so dürfen wir für n_geschätzt durchaus mit 700 – 1000 auftauchenden Problemen rechnen.

Das sind nur die, welche auf den endgültigen Entwickler-unabhängigen Funktionstest und Betreibbarkeitstest warten. Im Programm selbst steckt insgesamt in etwas die vierfache Problemmenge. Die wurden allerdings hoffnungsvollerweise schon in früheren Phasen des Projekts gefunden und behoben.

In der Kurve gibt es einen Wendepunkt. Der ist idealerweise ungefähr im Bereich der Hälfte der geschätzten Fehler. Das muss nicht unbedingt so sein. Doch die Hälfte der geschätzten Fehler sollten wir in der Hälfte der Zeit gefunden haben, die für den Testbetrieb geplant war. Erreichen wir dieses Ziel nicht, so dürfen wir davon ausgehen, dass wir entweder

1. mehr Fehler in der Lebensphase des Programmes zulassen müssen – oder
2. zusätzliche Testzeit bereitstellen müssen.

Beide Möglichkeiten sind mit Kosten verbunden.

Probleme, sowohl gefundene als auch nicht gefundene, lassen sich in € umrechnen und bewerten.

Anmerkung: In der Praxis ist es oft der Fall, dass die Kosten für Test und die Folgekosten von nicht gefundenen Fehlern von verschiedenen Gruppen, Abteilungen, ja auch Firmen getragen wird. Dies verhindert in der Regel eine integrale Sicht auf die Kostensituation und führt dazu, dass Test nicht ausreichend budgetiert wird. Diesem Umstand wird durch eine neue Strategie, dem „economic testing“ Rechnung getragen.

Während die Probleme die kleine Münze darstellen, kann ein weiterer Begriff aus dem Testbereich als Banknote gedacht werden: es handelt sich um den Testfall.

Ein notwendiger Testfall stellt eine Schuld dar, solange er noch nicht zufriedenstellend betestet wurde. Dies ergibt sich aus dem Begriff notwendig. Es gibt verschiedene Möglichkeiten Testfälle zu definieren. Man kann sie aus den Anforderungen herausdestillieren. Man kann sie analytisch bilden, in dem man eine möglichst große Menge von Programm-Möglichkeiten damit abdecken kann. Die bis jetzt als sparsamste Variante erkannte Art, Testfälle zu bilden, leitet sich von einer Risikobetrachtung ab.

Welche Fehler passieren am häufigsten? Welche Fehler richten den größten Schaden an? Das Produkt aus Häufigkeit mal Schadenswirkung gibt eine Kenngröße an, welche die Programmszenarien auszeichnet, welche unbedingt getestet werden müssen.

Ein derartiger Testfall läßt sich daher relativ einfach in € bewerten. Schadenswirkung mal Häufigkeit läßt sich in €/Jahr errechnen. (Wie oft wird das Szenario pro Jahr im normalen Betrieb durchgeführt? Jährliche Läufe, Monatliche Läufe, 10 000 Requests/Tag) Dieser Betrag wird mit der durchschnittlichen Fehlerhäufigkeit multipliziert. Das ist eine Prozentzahl, die sich aus den Kennwerten des Testbetriebes ergibt. Ob man hier nun von Reliability oder Error Prevention oder Error Removal Rate spricht, ist nur eine Geschmacksfrage. In jedem Fall geht man von einer verbleibenden Restfehlermenge aus, welche je nach Anwendung zwischen mehreren Prozent- und Promillebereichen liegt. Bei einem durchschnittlichen Lebenszyklus von 4 Jahren und unter Berücksichtigung der Kompression (eine Linearisierung des Fehlerfindungsverlaufes) lässt sich der Restfehleranteil noch durch 4 dividieren.

Nehmen wir also im obigen Beispiel an, dass ein Fehler, welcher einmal im Jahr schlagend werden kann, 100 000 € Schaden bewirkt, und wir von einer Restfehlermenge von 3% ausgehen, so rechnen wir:

Erwartete Fehler in Test: 1000

Gesamtfehler im Programm: 4000

Restfehlermenge: 3% Zielvorstellung

Fehlerschaden/Jahr: 100 000 €

Wahrscheinlichkeit: 0,75%

Fehlerrisiko 1. Jahr: 750 €

Fehlerrisiko insgesamt: 3000 €

In dieser Rechnung sind allerdings keine Folgekosten hinsichtlich der Berichtigung des Fehlers enthalten. Um den Fehler nicht zu wiederholen, sind entsprechende Testläufe und ein neues Deployment notwendig. Das bedeutet, dass das Fehlerrisiko brutto für netto angenommen werden muss und allfällige Kosten des Testes nicht berücksichtigt werden müssen.

Das obige Beispiel klingt vergleichsweise harmlos, trotz der großen Schadenssumme scheint es sich nur um eine Art Versicherungszocke zu handeln. Interessanterweise geht die Gesamtzahl der Fehler auch gar nicht in die Rechung ein.

Schlimmer sieht die Risikofrage bei Abläufen aus, die im Tag mehrere Male durchlaufen werden. Hier sind es vor allem diejenigen Probleme, um die man herumarbeiten kann, welche große Kosten verursachen. Der Work-Around verschlingt vielleicht 2 Minuten mehr Arbeitszeit, die nicht registriert wird. Durch den Work-Around wird aber die Dringlichkeit der Fehlerbehebung in den Hintergrund gedrängt und es entstehen schleichende Kosten, welche weit über die oben angesetzte Summe von 100 000 € hinausgehen.

An dieser Stelle sollen keine weiteren Berechnungshinweise mehr gegeben werden. Es reicht, wenn man sich bewusst wird, dass Probleme und Testfälle ihre unmittelbare Entsprechung in € haben. Auch wenn es oft sehr schwer ist, diesen Zusammenhang einem Projektleiter zu vermitteln, so hilft es sehr, wenn es darum geht, die durchzuführenden Testmassnahmen zu planen.