Das Wissensportal für IT-Professionals. Entdecke die Tiefe und Breite unseres IT-Contents in exklusiven Themenchannels und Magazinmarken.

SIGS DATACOM GmbH

Lindlaustraße 2c, 53842 Troisdorf

Tel: +49 (0)2241/2341-100

kundenservice@sigs-datacom.de
Anzeige

Versteht Ihre Firma den Wert des Testens?

Wir können leicht ausrechnen, wie viel unsere Tests kosten: In der Regel wissen wir, wie viel Zeit die Leute mit Testen verbringen, welche Kosten für die Anwerbung und Schulung dieser Tester anfallen und wie viel für die eingesetzten Werkzeuge und die benötigte Infrastruktur ausgegeben wird. Aber auch für andere Leute in der Firma ist es leicht, einen Blick auf diese Zahlen zu werfen und dann einzuwenden, dass die Kosten zu hoch erscheinen.

  • 23.04.2021
  • Lesezeit: 7 Minuten
  • 74 Views

Die meisten von uns, die schon einmal Tests verantwortet haben, wissen, wie es sich anfühlt, wenn ein Projektleiter, IT-Manager oder Geldgeber wünscht – oder sogar fordert –, dass wir diese Kosten reduzieren ... aber selbstverständlich ohne Beeinträchtigung der Produktqualität!

Wenn wir dem Vorwurf, dass unsere Tests zu teuer seien, nicht zustimmen können, sondern vielleicht sogar etwas mehr Geld dafür ausverhandeln möchten, stellt sich die Frage, wie wir den Kampf gegen diese „Erbsenzähler“ gewinnen können. Wir können nicht leugnen, dass Testen teuer ist. Jede Arbeit, die gut ausgebildete Leute sowie komplexe Hard- und Software erfordert, ist zwangsläufig nicht billig. Wenn allerdings jemand behauptet, dass Testen zu teuer sei, könnten wir die Diskussion folgendermaßen beginnen:

  • Testmanager: „Zu teuer? Im Vergleich zu welcher Alternative? Was würde es kosten, wenn wir gar nicht testen würden?“
  • Erbsenzähler: „Nun, natürlich nichts …“
  • Testmanager: „Ernsthaft? Wir würden also einfach alle Fehler, die im Produktivbetrieb auftauchen, ignorieren?“
  • Erbsenzähler: „Naja, das wohl nicht, die müssten wir selbstverständlich beheben.“
  • Testmanager: „Aha… und was würde das kosten?“
  • Erbsenzähler: „Äh, das kann ich nicht so genau sagen …“

Und jetzt sind wir beim kniffligen Teil angelangt: Es ist leicht, die Ausgaben für das Testen zu ermitteln, aber schwierig, die exakten Kosten eines Fehlers zu bestimmen, der im Betrieb auftritt. Das gelingt nur wenigen Organisationen, und die meisten versuchen es nicht einmal. Tom DeMarcos oft (falsch) zitierte Aussage: „Was wir nicht messen können, können wir auch nicht kontrollieren“ ist meistens wahr. Aber können wir denn die Kosten überhaupt messen? Yes, we can ...

Wie viel kostet ein Fehler?

Ein geeignetes Zeiterfassungssystem erlaubt es uns, die gesamte Zeit zu ermitteln, die für die Lokalisierung und Behebung des Fehlers, für Fehlernach- und Regressionstests und das Deployment der Korrektur aufgewendet wird. Hier muss natürlich auch die Zeit miteinberechnet werden, die benötigt wird für die Kommunikation mit Benutzern und Kunden, die Reparatur der korrumpierten Datenbank, die Aktualisierung der Schulungsunterlagen und was sonst noch alles nötig ist, um die Kunden wieder zufriedenzustellen.

Aber was ist mit den weniger offensichtlichen, den indirekten Kosten?

  • Wie viel Umsatzverlust bedeutet es, wenn ein Webshop eine Stunde außer Betrieb ist?
  • Wie viel zukünftiger Umsatz ist dadurch verloren gegangen, dass manche Kunden innerhalb dieser einen Stunde eine Alternative bei der Konkurrenz gefunden haben und nie wieder zurückkehren werden?
  • Wie viel Schaden ist durch die darauffolgende negative Berichterstattung für den guten Ruf des Unternehmens und den Aktienkurs entstanden? Welchen finanziellen Schaden hat dieser Kursverlust durch die Verringerung zukünftiger Investitionsmöglichkeiten verursacht?
  • Wenn der Fehler dazu geführt hat, dass wir unsere Lieferanten erst verspätet bezahlen konnten, und einige davon uns nicht mehr beliefern wollen – wie viel hat es gekostet, nach Alternativen zu suchen?

Die gute Nachricht ist, dass wir in der Firma vermutlich irgendeinen Business- oder Marketinganalytiker, Finanzbuchhalter, Direktor oder sonst jemanden finden, der eine Vorstellung von den verursachten Kosten hat. Es ist auch gar nicht nötig, dass sich diese Person auf eine exakte Summe festlegt (vermutlich würde sie dazu auch nur ungern bereit sein). Schon eine Schätzung, egal wie ungenau, ist für uns genug. Genug wofür? Genug um zu sagen: Jedes Mal, wenn wir solch einen Fehler finden, bevor er in Betrieb geht, sparen wir Euch ungefähr so viel Geld. Wenn ich mich zwischen einer Schätzung und völliger Unwissenheit entscheiden muss, wähle ich auf jeden Fall die Schätzung.

Natürlich ist es nicht ganz so einfach. Um eine realistische Zahl für die Ersparnis zu bekommen, müssen wir die Kosten für die Auffindung und Behebung des Fehlers vor der Auslieferung berücksichtigen. Und wir müssen klar festlegen, wie „solch ein Fehler“ aussieht, weil es viele verschiedene Arten von Fehlern gibt, jede mit ihrem eigenen Kostenprofil. Daher benötigen wir noch ein Modell zur Kostenschätzung.

Aber das sind lösbare und eher unwichtige Details. Den wichtigsten Schritt, um den Wert des Testens für das Unternehmen zu zeigen, haben wir bereits gemacht, und zwar auf eine (oder sogar beide) der folgenden Arten:

  • Return on Investment (ROI) und
  • Qualitätskosten (Cost of Quality, COQ).

Return on Investment

Es ist so einfach, Fallstudien zu finden, die zeigen, dass es billiger ist, einen Fehler vor der Inbetriebnahme zu finden und zu beheben als danach, dass ich hier nicht Ihre Zeit mit Zitaten verschwenden möchte. Die Frage ist:
Wie kann ich meiner Organisation klarmachen, welchen Wert das für sie hat? Und da Daten aus anderen Unternehmen vielleicht mit Skepsis aufgenommen werden, ergibt sich die weitere Frage: Wie komme ich zu eigenen Daten?
Nun, wir wissen, wie viel das Testen des ersten Release des aktuellen Produkts gekostet hat, oder? Und wir wissen auch, wie viele Fehler dabei gefunden wurden und wie diese auf die einzelnen Schweregrade (z. B. Blocker, Critical, Major, Minor, Trivial) verteilt waren. Und wir haben eine Schätzung, wie viel die Behebung „solch eines Fehlers“ erst im Betrieb kostet. Um die Sache einfach zu halten, bewerten wir den Fehler zunächst nur nach seinem Schweregrad und erhalten so die grob geschätzten durchschnittlichen Kosten für seine Behebung, wenn er bis in den Betrieb gelangt ist (siehe das Beispiel in Tabelle 1). Diese Vorgehensweise ist vielleicht zu simpel für die reale Welt, reicht aber vollkommen aus, um eine Vorstellung vom Grundprinzip zu vermitteln.

Tabelle 1: Von Fehlern im ausgelieferten Produkt verursachte Kosten
Schweregrad Durchschnittliche
Behebungskosten
im Betrieb (€)
Anzahl der
im Betrieb
gefundenen Fehler
Ersparnis (€)
Blocker 2 000 4 8 000
Critical 1 800 15 27 000
Major 1 200 30 36 000
Minor 300 45 13 500
Trivial 100 25 2 500
Summe 87 000

Die Kosten, um diese Fehler rechtzeitig vor Inbetriebnahme des Produkts zu finden und zu beheben, betrugen hingegen nur 42 000€. Die Ersparnis ist also

87 000 - 42 000 = 45 000 EUR. Der ROI ist daher = (45 000/42 000) * 100 = 107 %

Die meisten Manager werden mit einem Business Case, der nach zwei oder drei Jahren Gewinn abwirft, zufrieden sein. Studien haben gezeigt, dass die meisten Fehler innerhalb von sechs Monaten nach der ersten Produktauslieferung entdeckt werden. Wir sprechen hier also von einer Investition, die sich innerhalb von sechs Monaten rentiert. Ich habe in letzter Zeit keine Bank gefunden, die mit einem ähnlich guten Zinssatz wirbt.

Bei Projekten mit einem wasserfallartigen Lebenszyklus können wir hier die Kosten für alle unabhängigen Tests einsetzen, die ab der Systemtestebene aufwärts durchgeführt werden. Bei agilen Projekten können wie für jedes Release alle Testtätigkeiten, die Fehlerberichte generieren könnten, sowie alle Arbeiten, die zur Behebung der gefundenen Fehler erforderlich sind, einberechnen. Dies umfasst üblicherweise alle Tests ab jenem Zeitpunkt, zu dem die einzelnen User-Storys den Status „Done“ erreicht haben (die meisten agilen Teams melden davor keine Fehler).

Die Schwäche der beschriebenen Methode liegt darin, dass allein der Schweregrad zur Schätzung der Kosten für die Behebung eines Fehlers im Produktivsystem verwendet wurde. Das war gut genug, um darstellen zu können, wie die Berechnung funktioniert, ist aber für die reale Welt zu ungenau. Um ein besseres Verständnis zu erhalten, müssen wir die tatsächlichen Kosten für die Behebung verschiedener Fehlertypen ermitteln, die wiederum abhängig von der Menge und Größe der Artefakte sind, die korrigiert, nochmals getestet und ausgeliefert werden müssen. Das erfordert einigen Aufwand und würde den Rahmen dieses Artikels sprengen, wird sich aber auf jeden Fall lohnen, wenn sich die Stakeholder durch einen realistischen ROI-Wert vom Wert des Testens überzeugen lassen.

title
Tesena
subtitle
SMART TESTING
introduction
Tesena ist ein Software-Testunternehmen mit Sitz in Prag, das mit angesehenen Kunden in einer Vielzahl von Geschäftsbereichen zusammenarbeitet. Wir sind ein akkreditierter ISTQB-Schulungsanbieter, der spezielle interne Schulungen anbietet und kundenspezifische Anforderungen erfüllen kann. Tesena bietet Konferenzen, Meet-ups und Web-Seminare an und unterstützt die Testing-Community. Test-Dienstleistungen: Systemintegration, Funktionstest, Leistungstest, Testberatung, Testmanagement, Automatisiertes Testen … Info unter: https://www.tesena.com/
image
Logo-Tesena
. . .


Artikel teilen

Nächster Artikel
3, 2, 1 Data-Driven