News/Blog

21.07.2021

Risikobasiertes Testen – konkrete Umsetzung in der Praxis

Ein Ferrari 250 GTO als unser Beispiel aus der Praxis [Bildnachweis: iStock.com/falun]

In „Risikobasiertes Testen – nichts geht ohne strukturierte Risikoanalyse“ – haben wir den Risikomanagementprozess im Überblick vorgestellt.

Die Umsetzung in der Praxis, d.h. die Identifizierung konkreter Risiken, deren Analyse und Bewertung sowie die Festlegung konkreter Maßnahmen zur Risiko-Mitigation zeigen wir nachfolgend am Beispiel einer Software für das Management von Kfz-Versicherungen mit einer speziellen Versicherung für Oldtimer.

Phase 1 – Risiken identifizieren

Grundsätzlich muss das Versicherungs-Unternehmen zunächst für sich klären, welche Prozesse Werte für das Unternehmen generieren und welche weiteren Faktoren, wie z.B. gesetzliche Auflagen dabei zu berücksichtigen sind. Hierzu gehören zum einen direkt wertschöpfende Prozesse (das sind im weitesten Sinne alle Tätigkeiten eines Unternehmens, für die Kunden bereit sind, Geld zu bezahlen) sowie alle Prozesse, die Schaden vom Unternehmen abwenden, z.B. die Definition von geeigneten Regeln für die Kfz-Versicherung (von der Risikoeinstufung bis hin zur möglichen Ablehnung eines Antragstellers).

Der Abschluss von Kfz-Versicherungsverträgen inklusive der Risiko-Einstufung erfolgt in weiten Teilen automatisiert durch entsprechende Software. Die Risiken im Zusammenhang mit dem Einsatz der Software werden in Workshops ermittelt. Daran sollten mindestens Vertreter*innen des Nutzerkreises (z.B. Vertreter*innen der Fachabteilung oder Produktmanager*innen), der Betriebsorganisation bzw. der IT, der Projektleitung, der Software-Entwicklung und des Softwaretests teilnehmen.

Risiko-Workshops können auch weitere Themen wie Bedrohung der IT -Sicherheit oder Datenschutz-Verletzungen fokussieren. In diesem Fall sollte der Teilnehmerkreis um geeignete Fachpersonen erweitert werden. Es ist weiterhin sinnvoll, eine/n erfahrene/n Moderator*in mit in den Workshop zu nehmen, die/ der sicherstellt, dass die Risiken konkret und sprechend definiert werden. Die identifizierten Risiken müssen so konkret wie möglich definiert werden, damit in den weiteren Phasen mögliche Schäden bestmöglich bewertet werden können. Außerdem soll auf dieser Basis zugeordnet werden, wo in der Software ein entsprechender risikoverursachender Fehler auftreten kann.

Ein identifiziertes konkretes Risiko kann zum Beispiel lauten:

„Wenn ein Oldtimer der falschen Fahrzeugklasse zugeordnet wird, dann kann ein Vertrag im Hinblick auf die Auszahlung des Wiederbeschaffungswerts bei einem Totalschaden in einem viel zu günstigen Tarif abgeschlossen werden.“ (Risiko 1)

Ob dies prinzipiell im Prozess oder in der Software passieren kann, wird an dieser Stelle noch nicht geklärt. Dafür ist der nächste Schritt, die Risiko-Analyse da.

Phase 2: Risiken analysieren

Dazu wird das identifizierte Risiko auf Basis möglicher Ursachen in unterschiedliche Risikoarten unterteilt. In unserem konkreten Beispiel könnte dies so aussehen:

  1. Prozess-Risiken:
    1. 1.1 Falsche Zuordnung der Fahrzeugklasse auf Grund menschlichen Versagens beim Vertragsabschluss
    2. 1.2 Vorgabe fehlerhafter Regeln für die Zuordnung in eine Fahrzeugklasse
  2. Software-Risiken:
    1. 2.1 Fehler in der Implementierung der Zuordnungsregeln
    2. 2.2 Fehler bei der Auswertung der für die Zuordnungsregeln relevanten Benutzereingaben.

Die den Risikoarten zuzuordnenden Risiken können tabellarisch erfasst werden. Sie sollten bei der Ermittlung mit konkreten Beispielen veranschaulicht werden: in unserem Anwendungsfall wird von der Versicherung mit dem aktuellen (zu testenden) Release eine neue Oldtimer-Versicherung gelauncht, die für bestimmte Oldtimer-Kategorien nicht die sonst übliche Vorlage eines Wertgutachtens vorsieht. „Exklusiv-Fahrzeuge“ (wie z.B. ein 1963 Ferrari 250 GTO oder ein Aston Martin Lagonda) müssen dabei ausgeschlossen werden, könnten aber beim Vertragsabschluss vom Vermittler versehentlich in dieser Kategorie versichert werden, weil in der Software eine entsprechende Plausibilitätsprüfung fehlerhaft ist oder ein entsprechender Hinweis den Sachbearbeiter*innen nicht angezeigt wird. Beide möglichen Fehler wären Risiken in den Kategorien 2.1 und 2.2.

Phase 3: Risiken bewerten

Zur Bewertung des identifizierten Risikos haben wir beispielhaft die folgenden Bewertungskategorien für Schaden und Wahrscheinlichkeit definiert. Dabei haben wir uns auf die Bewertung des Softwarerisikos konzentriert; die Bewertung von Prozessrisiken kann analog gestaltet werden.

Schadenskategorien:

Kategorie S0: Ein finanzieller Schaden wird nicht erwartet oder ein möglicher Schaden liegt in Summe pro Jahr unter € 10.000.

Kategorie S1: Der mögliche Schaden beträgt in Summe pro Jahr zwischen € 10.000
und € 100.000.

Kategorie S2: Der mögliche Schaden beträgt in Summe pro Jahr zwischen € 100.000 und
1 Million Euro.

Kategorie S3: Der mögliche Schaden beträgt in Summe pro Jahr mehr als 1 Million Euro.

Kategorien für die Wahrscheinlichkeit eines Softwarefehlers:

Kategorie W0: Zugehörige Software im Betrieb, keine Änderungen in der Komponente vorgesehen, keine Änderungen in aufrufenden oder aufgerufenen Komponenten vorgesehen, keine Fehler aus dem Betrieb bekannt.

Kategorie W1: Zugehörige Software in Betrieb, keine Änderungen in der Komponente vorgesehen, keine Änderungen in aufrufenden oder aufgerufenen Komponenten vorgesehen, aber Fehler aus dem Betrieb innerhalb des letzten Jahres bekannt.

Kategorie W2: Zugehörige Software in Betrieb, keine Änderungen in der Komponente vorgesehen, aber Änderungen in aufrufenden oder aufgerufenen Komponenten vorgesehen, keine Fehler aus dem Betrieb bekannt.

Kategorie W3: Software neu
oder
zugehörige Software in Betrieb, aber Änderungen in der Komponente vorgesehen
oder
zugehörige Software in Betrieb, keine Änderungen in der Komponente vorgesehen,
aber Änderungen in aufrufenden oder aufgerufenen Komponenten vorgesehen und Fehler aus dem Betrieb bekannt.

Vintage-Cars wie ein 1963 Ferrari 250 GTO können einen Wiederbeschaffungswert von bis zu $70 Millionen haben (vgl. https://americancollectors.com/articles/most-expensive-classic-cars/ ). Solange es keine weiteren Einschränkungen in den allgemeinen Versicherungsbedingungen gibt, können unsere beiden Beispiel-Risiken für die Oldtimerversicherung damit in die Kategorie S3 eingestuft werden. Da das aktuell zu testende Software-Release wesentliche Änderungen enthält, wird die Wahrscheinlichkeit ebenfalls mit der höchsten Kategorie W3 bewertet.

Phase 4: Maßnahmen festlegen und implementieren

Um eine übersichtliche Strategie zum Umgang mit den Risiken definieren zu können, werden Gesamtrisikostufen eingeführt, die sowohl die Einschätzung der Schadenshöhe als auch die Einschätzung der Eintrittswahrscheinlichkeit kombinieren. Eine gängige Methode ist, diese Risikostufen anhand einer Matrix zu definieren (vgl. Abbildung).

Abbildung 1 Eine Risikomatrix.

Abbildung 1 Eine Risikomatrix. Anhand der Risikostufen wird die Testvorgehensweise festgelegt.

Bei der Festlegung der Matrix sollte darauf geachtet werden, dass diese nicht symmetrisch aufgebaut ist. Schäden werden in der Regel von Stufe zu Stufe exponentiell größer werden. Ein Risiko, dass mit W0 und S3 eingestuft wurde, sollte nicht genauso gewichtet werden wie ein Risiko mit der Einstufung W3 und S0.

Auf Basis der Risikostufen kann eine generische Teststrategie definiert werden, die festlegt, wie die zu einem identifizierten und bewerteten Risiko gehörenden Softwareteile getestet werden.
Z.B.

  • R3:
    • Formaler Test auf allen Teststufen mit unterschiedlichen Testmethoden
    • Durchführung automatisierter Regressionstests auf Systemebene
    • Verpflichtende Unit-Tests
  • R2:
    • Formaler Test auf mindestens zwei Teststufen
    • Verpflichtende Unit- und System-Tests
    • Durchführung automatisierter Regressionstests
  • R1:
    • Durchführung vorhandener Regressionstests
    • Verpflichtende Unit-Tests
    • Gibt es bislang keine Tests auf Systemebene, werden diese erstellt
  • R0:
    • Durchführung vorhandener Regressionstests auf Systemebene
    • Verpflichtende Unit-Tests

Unsere Beispielrisiken fallen in Kategorie R3; als mitigierende Maßnahme muss daher sehr sorgfältig auf allen Teststufen getestet werden.

Ergänzend zu den Softwaretests können weitere Maßnahmen zur Behandlung eines Risikos ergriffen werden. So könnten die AGB angepasst werden, um finanzielle Folgen eines fehlerhaften Vertragsabschlusses abzufedern oder ganz zu vermeiden. Auch können zusätzliche Sichtprüfungen und Freigabe-Regelungen in den Vertragsabschlussprozess aufgenommen werden.

Fazit

Der risikobasierte Ansatz liefert den Testverantwortlichen wertvolle zusätzliche Informationen über Testanforderungen, die oftmals nicht direkt aus den Software-Anforderungen hervorgehen. Außerdem liefert er Indikatoren für weitere risiko-beherrschende Maßnahmen, z.B. Vorschläge für Prozessverbesserungen in allen Unternehmensbereichen.

Damit dient risikobasiertes Testen nicht, wie oftmals fälschlicherweise behauptet, der Einsparung von Testaufwänden. Es dient vielmehr dazu, Testaufwände gezielt zu allokieren und zu begründen und den Fokus auf die „richtigen“ Testmaßnahmen zu legen. Gegenüber jedem nicht durchgeführten Test stehen mögliche, teilweise extrem hohe Fehlerfolgekosten, die in den Risikokategorien mit abgebildet sind.

Risikobasiertes Testen spart nicht dadurch Geld, dass weniger getestet wird, sondern dass gezielter getestet wird, und zwar dort, wo viel Geld verloren geht, wenn Fehler auftreten! Und das ist nicht zwangsläufig der häufigste Use-Case. Erst das Zusammenspiel aus einer gezielten Analyse der eigenen Business-Cases, ihrer Abbildung in der Software und der Bewertung der Folgen von Fehlern lässt den risikobasierten Ansatz seine Wirksamkeit entfalten. So trägt dieses Vorgehen wesentlich dazu bei, die Softwarequalität zu verbessern, ROI in Softwareprojekten zu steigern und ‚Hypercare‘ zu reduzieren, weil das Testbudget auf die als riskant erkannten Bereiche fokussiert wird.

Autor:
Christian Alexander Graf berät Unternehmen zu Teststrategien, Datenanalysen und IT-Sicherheit. Zusätzlich unterrichtet er Statistik und IT-Sicherheit u.a. an der DHBW in Mannheim.
Er ist außerdem Buchautor und hat etliche Fachartikel zu unterschiedlichen Themen rund um die Qualitätssicherung verfasst.

Co-Autorin:
Isabella Rieger ist bei FMC GmbH Head of Sales and Business Development für den Bereich succest. In diesem Zusammenhang beschäftigt sie sich intensiv mit den Themen Testdatenmanagement und Testautomatisierung.


‹ zurück