News/Blog

19.02.2021

Risikobasiertes Testen – nichts geht ohne strukturierte Risikoanalyse

Risikobasiertes Testen – nichts geht ohne strukturierte Risikoanalyse [Bildnachweis: iStock.com/Sitthiphong]

Risikobasiertes Testen richtig und konsequent zu implementieren ist alles andere als trivial. Weil das Wort „Testen“ darin vorkommt, ist der häufigste Umsetzungsfehler, dass mit dem risikobasierten Test auch erst im Test begonnen wird. Risiko-basiertes Testen beginnt aber schon weit vor dem eigentlichen Test. Worauf man beim risikobasierten Testen außerdem unbedingt achten muss, um erfolgreich zu sein, beschreibt der folgende Beitrag.

Was ist überhaupt ein Risiko?

Ein Risiko ist die „Auswirkung von Unwägbarkeiten auf ein erwünschtes Ziel bzw. Ergebnis („effect of uncertainty on objectives“)“ – vgl. *). Ein Risiko lässt sich durch 3 Kategorienklassen charakterisieren:

  • Quellen des Risikos – wie z.B. fehlerhafte Anforderungen oder abgefahrene Winterreifen.
  • Auslösende Ereignisse – eine unerwartete Programm-Eingabe in einem bestimmten Prozessschritt oder Fahren bei Schneeglätte.
  • Auswirkungen wie Programmabstürze oder der unfreiwillige Umweg in den Straßengraben.

Eine weitere kontextabhängige Unterteilung der Kategorienklassen wie z.B. eine Trennung nach organisatorischen oder sicherheitsbezogenen Aspekten ist hilfreich und sinnvoll.

Wie Risiken gemanagt werden

Die Hauptaufgabe des Risikomanagements ist es, mögliche Auswirkungen, deren Auslöser und Quellen frühzeitig zu erkennen und Maßnahmen zu ergreifen, die bereits dem Entstehen (oder dem größer werden) der Probleme entgegenwirken.

Bevor der eigentliche Risikomanagementprozess beginnen kann, muss für alle Prozessbeteiligten transparent sein, was einen Schaden für das Unternehmen darstellt. Schäden, die aus Risiken beim Einsatz von Unternehmenssoftware durch nicht entdeckte Softwarefehler entstehen können, betreffen insbesondere Wertschöpfungsketten oder bußgeldbewehrte Regelverstöße. Deshalb müssen die jeweiligen Stakeholder zu diesen Themen auf jeden Fall am Risikomanagement beteiligt sein.

Die Abbildung zeigt einen typischen Risikomanagementprozess sowie die für dessen Implementierung erforderlichen begleitenden Managementaktivitäten. Essenziell ist dabei, alle für das jeweilige Projekt relevanten Stakeholder zu involvieren.

Die Phasen im Risikomanagament

Die Phasen im Einzelnen:

  • Risiken identifizieren: Unabhängig von der Software muss im Vorfeld geklärt sein, mit welchen relevanten Prozessen die Werte für das Unternehmen generiert werden und welche gesetzlichen Auflagen das Unternehmen erfüllen muss – dazu gehören z.B. der Datenschutz oder branchenbezogene Sicherheitsbestimmungen. Im nächsten Schritt wird identifiziert, wo die zu testende Software Einfluss auf die Wertschöpfungskette oder Auswirkungen auf regulatorische Anforderungen hat.
    Die Identifizierung von Risiken erfolgt meist in der Form von gezielten Brainstorming Sessions. Eine bewährte Vorgehensweise ist dabei, Risiken als “Wenn (Ereignis)… dann … (Auswirkung)“-Aussagen zu formulieren. Also z.B. „wenn die Zahlungslauffunktion nicht funktioniert, dann müssen die Überweisungen manuell getätigt werden“.
  • Risiken zu analysieren bedeutet, zu jedem identifizierten Risiko systematisch weitere Informationen zu ergänzen. Sinnvoll ist dabei die Verwendung von Risikotemplates, in denen relevante Risikokategorien festgelegt sind, wie z.B. betroffene Funktion, erwartete Fehlerart, mögliche Ursache, möglicher Auslöser, Verursacher, Art des Risikos. Typischerweise wächst dabei die Risikoliste, weil im Rahmen der Analyse weitere Risiken identifiziert werden.
  • Die Phase „Risiken bewerten“ legt den Fokus auf die Priorisierung der identifizierten und analysierten Risiken. Den Schlüssel dazu bilden nachvollziehbare Bewertungskategorien für die Wahrscheinlichkeit des Eintretens eines unerwünschten Ereignisses und den möglichen daraus resultierenden Schäden. Diese können z.B. nach der Relevanz von Prozessen für die Wertschöpfung des Unternehmens in Kategorien wie hoch-kritisch, kritisch, leicht kritisch und irrelevant eingestuft werden.
    Die größte Herausforderung bereitet in der Praxis die Einstufung der Wahrscheinlichkeit des Eintretens einer Schadensauswirkung. Im Falle von Software spielen hier zwei Quell-Faktoren des Risikos eine entscheidende Rolle. Der erste relevante Faktor basiert auf dem Quellcode oder den Konfigurationseinstellungen der Software, die zu einer negativen Auswirkung führen können. Dies wird als Fehlerzustand bezeichnet. Der zweite Faktor betrachtet die Grundursachen, aus denen Fehlerzustände resultieren können. Solche Grundursachen sind z.B. technische oder fachliche Komplexität und organisatorische Aspekte in Form von häufigen Änderungen von Anforderungen oder der Implementierung.
    Auf Basis der Grundursachen wird bewertet, wie wahrscheinlich das Vorliegen kritischer Fehlerzustände in der betreffenden Software bzw. der konkreten Funktion oder einer Schnittstelle ist. Für diese Bewertung ist die aktive Einbindung von Vertretern der IT bzw. der Software-Entwicklung erforderlich.
  • Maßnahmen implementieren. Hier liegt die Betonung auf dem Wort “implementieren“. Es reicht nicht, eine Maßnahme festzulegen, sie muss auch durchgeführt werden. Erst dann kann beurteilt werden, ob sie wirksam ist. Sonst wird die Beherrschung von Risiken eine reine Milchmädchenrechnung: „Wenn ich die Milch auf dem Markt verkaufen kann, dann … “.
  • Verbleibende Risiken (neu) bewerten dient dazu, die Wirksamkeit der zuvor festgelegten Maßnahmen zu bewerten – z.B. „Haben wir genug getestet und die gefundenen relevanten Fehler behoben?“ Aber auch: „Haben sich seit der letzten Bewertung entscheidende Bewertungsfaktoren geändert?“ Entscheidend ist dabei eine Schaden-Nutzen-Abwägung: „Ist ein hoher Schaden mit den getroffenen Maßnahmen noch plausibel?“ Wenn ja, sind weitere Maßnahmen, z.B. weitere Tests erforderlich.

Typische Fallstricke beim risikobasierten Testen

Beim risikobasierten Testen orientiert sich das Testmanagement bei der Entscheidung „was, wie umfangreich, wo getestet wird“ an der zuvor getätigten Risikobewertung. Fehlentscheidungen im Testmanagement resultieren typischerweise aus einem lückenhaft umgesetzten Risikomanagementprozess.
Folgende Haupt-Irrtümer lassen sich in der Praxis immer wieder finden:

  1. „Risikobasiertes Testen ist allein die Aufgabe des Testteams.“
    Dieses Muster ist vor allem dann zu finden, wenn Risiko- und Qualitätsmanagement keine Schnittstellen haben, z.B. weil im Risikomanagement nur Projektzeit- und -budget verfolgt werden. In der Folge werden Produktrisiken nur im Test betrachtet. Die Risikoidentifikation, -analyse und -bewertung ist dann lückenhaft, weil das Testteam in der Regel nur einen Teil der Informationen kennt (und oftmals auch erst sehr spät im Projektverlauf erhält), die für eine angemessene Risikobewertung notwendig sind. In der Folge werden wichtige zu testende Aspekte nicht berücksichtigt und vorhandene Fehler daher nicht entdeckt. Diese zeigen sich dann erst nach der Inbetriebnahme der Software mit ggf. folgenschwerer Auswirkung und dann wird oftmals (zu Recht) die Frage gestellt: „Warum wurde genau das nicht getestet?“.
  2. „Risikobasiertes Testen führt zu relevanten Einsparungen beim Test.“
    Diese Einschätzung rührt von einer falschen Interpretation des Pareto-Prinzips her. In Bezug auf Softwarequalität besagt dieses Prinzip, dass die Mehrzahl der Fehler (z.B. 80%) in einem kleinen Teil (z.B. 20%) der Softwarekomponenten steckt. Daraus wird geschlossen, dass es beispielsweise ausreicht, die obersten 30% der Risiken zu testen und die restlichen Risiken zu vernachlässigen und durch einen reduzierten Testumfang Budget einzusparen. In den nicht getesteten 70% können sich aber noch gravierende Fehler verbergen, die im Produktivbetrieb zu bösen Überraschungen führen können. Risikoanalyse und -bewertung ist keine Empirie, sondern beruht auf Annahmen und Erfahrungswerten. Eine gute Teststrategie folgt deshalb nicht stur der Risikostufe, sondern berücksichtigt auch die Art des Risikos und sieht stichprobenartiges Testen auch von mittleren oder niedrigen Risiken vor. Aspekte, die in Risikoidentifikation und -analyse eventuell übersehen wurden, können somit noch im Test entdeckt und aufgefangen werden.
  3. „Es ist ausreichend, die am häufigsten genutzten Funktionen oder Prozesse einer Risikoanalyse zu unterziehen.“
    Dahinter verbergen sich gleich zwei fehlerhafte Annahmen. Zum einen die Mutmaßung, dass eine häufige Nutzung etwas mit der Wahrscheinlichkeit des Vorhandenseins von Softwarefehlern zu tun hat. Zum anderen der viel schwerwiegendere Irrtum, dass durch Betrachtung der häufig genutzten Prozesse und Daten alle schwerwiegenden Risiken bereits gefunden sind. Mit dieser Herangehensweise wird gleich zu Beginn der Risikoanalyse die Software in den Vordergrund gerückt und nicht die Wertschöpfungskette des Unternehmens, die durch ein gutes Risikomanagement geschützt werden soll. Die Folge ist eine stark verzerrte Risiko-Betrachtung, da ein Teil der wertschöpfenden oder regulatorisch relevanten Unternehmensprozesse aus der Risikoanalyse ausgeblendet werden. Die Häufigkeit der Nutzung einer Funktion bzw. eines Geschäftsvorfalls ist nur einer der Faktoren, die sich auf die Bewertung des Schadensausmaßes eines Risikos auswirken können. Im Risikomanagementprozess erfolgt diese Bewertung zu Recht erst im dritten Schritt.

Fazit:

Der Weg zu einer erfolgreichen risikobasierten Teststrategie führt durch drei Tore:

  1. Verstehen und Visualisieren der eigenen wertschöpfenden Geschäftsprozesse.
  2. Verstehen und Visualisieren, wie und wo die zu testende Software diese unterstützt. Dies erleichtert die Risikoidentifikation und Bewertung des Schadensausmaßes.
  3. Verstehen und Visualisieren, wie Softwareentwicklung und -deployment im Zusammenhang mit den ersten beiden Punkten organisiert sind. Dies unterstützt die Einschätzung von Eintrittswahrscheinlichkeiten und Festlegung angemessener Maßnahmen.

Auf Basis dieser Informationen kann der eigentliche Zyklus aus Risikoidentifikation, -analyse, -bewertung und Durchführung adäquater Testmaßnahmen beginnen.

Im nächsten Beitrag betrachten wir anhand von Beispielen, wie diese Schritte bei der Festlegung konkreter Testmaßnahmen und der Identifikation von Testdaten eingesetzt werden und geben Tipps für risikobasierte Testautomatisierungsstrategien.

Quellen:

* Christian Alexander Graf, https://schattenboxen-fuer-tester.org/risikotypen-und-der-softwaretest/

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.
Christian Alexander Graf ist außerdem Buchautor und hat etliche Fachartikel zu unterschiedlichen Themen rund um die Qualitätssicherung verfasst.

Co-Autorin:
Isabella Rieger ist Head of Sales and Business Development bei FMC GmbH und beschäftigt sich mit Software zur Erstellung von synthetischen Testdaten sowie für Testautomatisierung.


‹ zurück