Indiana Jones oder Black Widow wirken auf viele Menschen faszinierend und anziehend. Als Charaktere in Filmen, Videospielen (oder als explorative Tester) schätzen wir sie: Die Risikotypen.
Weniger jedoch, wenn es um unsere Software und unsere Projekte geht.
Um diese zweite Art von Risikotypen geht es in diesem Beitrag. Oder anders: Wie lassen sich Risiken erfolgreich beschreiben?

Fangen wir also einfach von vorne an.

 

Definition des Risikobegriffs

Die ISO 31000:2018 definiert den Begriff Risiko in freier Übersetzung als ‚Auswirkung von Unwägbarkeiten auf ein erwünschtes Ziel bzw. Ergebnis (‚effect of uncertainty on objectives‘).

Die Auswirkung kann daher gleichwohl wünschenswerter Natur sein als auch eine Bedrohung darstellen. So spricht man z.B. im Glückspiel von einer riskanten Strategie, wenn ein Spieler ein Vorgehen wählt, bei dem er mit hoher Wahrscheinlichkeit verliert, aber im Falle des Erfolgs mit einem sehr hohen Gewinn den Spieltisch verlässt.
Nach ISO lässt sich ein Risiko durch 4 Faktoren recht gut charakterisieren:

• Die Quelle des Risikos – z.B. ein Materialfehler oder ein Fehler in einem Computer-Programm. Im Falle des Glückspiels könnten das die Spielregeln oder gezinkte Würfel sein.
• ein (auslösendes) Ereignis – z.B. eine mechanische Belastung einer fehlerhaften Stelle oder die Nutzung einer bestimmten Programmfunktionalität. Im Glücksspiel ist das z.B. der Wurf des Würfels und das Setzen auf ein bestimmtes Ergebnis.
• Die möglichen Folgen des Ereignisses – z.B. die Zerstörung eines Bauteils, ein Programmabsturz oder ein finanzieller Verlust oder Gewinn. Mögliche Folgen können quantitativ oder einfach qualitativ (also auf einer Rangskala z.B. von marginal bis katastrophal) erfasst werden.
• Eine Beschreibung oder Bewertung der Wahrscheinlichkeit (im Sinne von engl. likelihood), mit der einer oder alle der anderen beschreibenden Faktoren (Quelle, auslösendes Ereignis, Eintreten des Schadens) zutreffen. Diese Beschreibung muss nicht notwendigerweise mathematisch sein. Wahrscheinlichkeit ist lt. ISO-Anmerkungen als Wahrscheinlichkeit im Weitesten Sinne zu verstehen. Nach Duden ist das etwas, was es erlaubt „den Grad der Möglichkeit des Eintretens bzw. der Voraussagbarkeit eines Ereignisses“ zu beschreiben.
  Eine Beschreibung der Wahrscheinlichkeit kann mithin über ein mathematisches Modell erfolgen – oder aber auch unter Zuhilfenahme einer einfachen Rangskala.

 

Risikostufen und Risikoarten

Risiken können nach Eigenschaften der sie bestimmenden Faktoren (z.B. der vier aus der ISO 31000) in Klassen (Kategorien) oder Stufen eingeteilt werden.

Beispiele:

• Der Ausgang eines Glücksspiels wirkt sich positiv oder negativ auf die Finanzen des Spielers aus, mithin haben wir es mit einem finanziellen Risiko zu tun.
• Nutzen Mitarbeiter einer Firma einen Firmenrechner für private Zwecke, kann dies die Sicherheit der Firmen-IT beeinträchtigen und stellt damit ein IT-Sicherheitsrisiko dar.
• Hängt ein Risiko mit Ereignissen wie Krieg, Sturmfluten oder Erdbeben zusammen wird das gerne als ‚höhere Gewalt‘ zusammengefasst.

Die Begriffe Risikostufe und Risikokategorie sind in der ISO 31000 nicht besprochen, da diese Art der Einstufung branchen- oder sogar produktspezifisch ist. Sie sind Gegenstand von entsprechenden Industrienormen wie z.B. der ISO 26262.

Wann von Risikostufen und wann von Risikokategorien oder -arten gesprochen werden sollte, ist nicht klar geregelt. Beziehen sich die Klasseneinteilungen auf Bewertungen der Schadenshöhe und/oder betrachteten Wahrscheinlichkeiten spricht man typischerweise von Risikostufen. Eine Stufeneinteilung ist aber gleichzeitig eine Kategorisierung. Risikostufen sind damit eine Untermenge der Risikokategorien bzw. Risikoarten.

 

Der Risikobegriff im Certified Tester

Der ISTQB Certified Tester definiert Risiko als (vgl. ISTQB-GTB-Standardglossar, v3.2) „einen Faktor, der zu negativen Konsequenzen in der Zukunft führen könnte, gewöhnlich ausgedrückt durch das Schadensausmaß und die Eintrittswahrscheinlichkeit.“

Da neben dem ‚Faktor‘, Schadensausmaß und Eintrittswahrscheinlichkeit zwei weitere Faktoren sind (man zähle nach – das sind schon drei), widerspricht die Definition sich selbst und ist in der Praxis nicht anwendbar.

Man kann sich das auch an einem einfachen Beispiel klar machen:

1. Wenn ich einen Gasherd einschalte, kann ich mir die Hand verbrennen.
2. Wenn ich einen Gasherd einschalte, kann er explodieren.
3. Wenn ich einen heißen Topf anfasse, kann ich mir die Hand verbrennen.

Wähle ich naiv den einen Faktor, der das Risiko ausmacht, so kann ich zu dem Schluss kommen, dass Situation 1 und 2 oder Situation 1 und 3 jeweils dasselbe Risiko beschreiben (Herd einschalten – Herd einschalten, Hand verbrennen – Hand verbrennen).

Eine sinnvolle Charakterisierung eines Risikos braucht daher mindestens zwei Faktoren: Eine Beschreibung einer Ursache und eine Beschreibung einer Wirkung.

In diesem Beitrag wird daher der Begriff Risiko nach ISO 31000 verwendet.

Hinweis für die Praxis: Bereits beim Sammeln (Identifizieren) von Risiken hilft es, diese mit Hilfe der Satzschablone „Wenn <Quelle/Ereignis> … dann <Wirkung/Schaden>.“ zu formulieren.

Diese Methodik hat außerdem einen vorteilhaften Seiten-Effekt: Hat man erst einmal Risikoquelle oder -ereignis (Ursache) und die Auswirkung klar beschrieben, lassen sich auch das Schadensausmaß und die Eintrittswahrscheinlichkeit viel leichter diskutieren und einschätzen.

 

Der Begriff der Risikokategorie (Risiko-Art, Risikotyp) ist im Certified Tester wie folgt definiert: „Eine Menge von Risiken, die einen oder mehrere gemeinsame Aspekte aufweisen.“
Das kommt dem Geist der ISO 31000 sehr nahe und wird hier übernommen.

 

Produkt- und Projektrisiken

Das ISTQB-GTB-Standardglossar, v3.2 bezeichnet das Produktrisiko als „Ein Risiko, das die Qualität eines Produktes beeinträchtigt“ und ein Projektrisiko als „Ein Risiko, das den Projekterfolg beeinträchtigt“.

Dazu betrachten wir zwei Risiken:

1. Wenn das Benutzerinterface nicht auf seine Zugänglichkeit geprüft wird, kann es sein, dass sehbehinderte Menschen nicht mit dem Produkt arbeiten können.
2. Wenn das Benutzerinterface nicht auf seine Zugänglichkeit geprüft wird, kann es sein, dass das Produkt im Abnahmetest durchfällt.

Wir haben zwei Risikokategorien. Im ersten Fall ein Produktrisiko, nämlich ein Produkt, das (vielleicht) von einer Personengruppe nicht verwendet werden kann.

Im zweiten Fall haben wir ein Projektrisiko, nämlich das (vielleicht) verpasste wichtigste Projektziel: Die Abnahme.

 

Eine alternative Sicht auf Produkt- und Projektrisiken

Die hohe Kunst ist es, die Zusammenhänge von Projekt- und Produktrisiken zu verstehen und abzubilden. Die obige Definition erfordert für manche Produktrisiken Projekt-Maßnahmen und für andere Testmaßnahmen. Besser wäre eine Unterscheidung, die bereits klar zuordnet, ob Aktionen auf Testebene oder auf Projektebene erfolgen müssen.

Z.B. sind fehlende Kenntnisse über barrierefreies Design oder verwendete Technologien bei Entwicklern, Analysten oder Testern zunächst Projektrisiken. Diesen kann ein Projektleiter mit organisatorischen Maßnahmen wie Ausbildung und Expertenbeistand entgegenwirken. Zusätzlich ergibt sich häufig ein mit dem Projektrisiko verknüpftes Produktrisiko, dass der Testmanager durch geeignete Testmaßnahmen absichern muss.

Die folgend skizzierte strengere Definition von Produkt- und Projektrisiko illustriert, wie die Unterscheidung zwischen Prozess- und Produkt-Faktoren vorgenommen und zur Identifikation geeigneter Maßnahmen im Test als auch auf Projekt-Ebene genutzt werden kann.

 

Dazu zieht man folgende verfeinerte Kategorisierung heran:

1. Liegt die Quelle des Risikos im Produkt inkl. Artefakten (Anforderungen, Design, möglicher Fehlerzustand) und entstehen negative Folgen beim Einsatz des Produktes, dann kann er dem mit einer geeigneten Testaktivität begegnen: Das sei fortan das Produktrisiko.
2. Liegt die Risikoquelle und/oder das auslösende Ereignis in der Projektorganisation (z.B. ein ungeeigneter Prozess, schlecht ausgebildete Mitarbeiter usw.) und wirkt sich das Risiko auf den Projekterfolg (Zeitplan, Budget, Projektergebnis – in punkto Test z.B. die erreichbare Testüberdeckung), muss er in der Projektorganisation aktiv werden. Das sei nun das Projektrisiko.

Im Beispiel des fehlenden Zugänglichkeits-Tests aus dem vorangegangenen Abschnitt ist Nummer 2 nach der strengeren Einteilung ebenfalls ein Projektrisiko.

Um die Frage zu beantworten, ob und welche Tests dabei sinnvoll sind, müssen die zugehörigen Produktrisiken genauer erfasst werden.

Die bisherige Formulierung von Risiko 1 reicht dazu nicht aus. Als Produktrisiko nach der neuen Definition taugt es nicht viel, auch wenn es die ursprüngliche Definition erfüllt. Es erfüllt ja nicht die zweite, enger gefasste Definition dieses Abschnitts – denn die Ursache liegt nicht im Produkt.

Eine weitere Analyse könnte z.B. zur folgenden Erkenntnis führen:

1‘. Wenn in Anforderungsdokumenten die Verwendung nicht-barrierefreier Anzeige-Formate vorgesehen ist, können sehbehinderte Menschen nicht mit dem Produkt (oder Teilen davon) arbeiten.

Hierzu kann der Testmanager Testmaßnahmen vom Anforderungs- über ein Designreview und statische oder dynamische Analysen bis hin zum explorativen Test festlegen. Ob und wieviel hängt natürlich von der Einstufung des Risikos und den weiteren Test- und Projektgegebenheiten ab.

 

Zusammenfassung

Das Kochrezept lautet zusammengefasst:

• Jedes Risiko klar durch Angabe von Ursache und Wirkung formulieren – z.B. als ‚wenn … dann …‘ Satz.
• Gehört ein Risiko eindeutig in die linke Spalte (Produkt), kann dem Risiko (u.a.) mit einer Testmaßnahme begegnet werden.
• Gehört ein Risiko eindeutig in die rechte Spalte (Projekt), ist (wenn das Risiko nicht akzeptabel ist) eine organisatorische Maßnahme im Projekt erforderlich.
• Passt das Risiko in keine der Spalten muss es weiter analysiert, genauer gefasst und ggf. weiter aufgeteilt werden.

Danach können für die identifizierten Risiken dann leichter Eintrittswahrscheinlichkeit und Schadensausmaß bewertet und geeignete Beherrschungs-Maßnahmen identifiziert werden.

 

Autor: Christian Alexander Graf, 10.06.2020

Nachtrag vom 11.06.2020:

Die in den beiden letzten Abschnitten diskutierten Ideen orientieren sich an den Definitionen des Projektrisikos nach ISO/IEC/IEEE 29119-1:2013 Software and systems engineering–Software testing–Part 1 und Part 3.
Hier werden Produkt- und Projektrisiko wie folgt definiert:

1. Produktrisiko: ‚Risiko, dass ein Produkt einen Defekt in spezifischen Aspekten im Hinblick auf Funktionalität, Qualität oder Struktur aufweist.
2. Projektrisiko: ‚Risiko im Zusammenhang mit dem Projektmanagement‘

Aktuelle Begriffs-Definitionen von IEEE und ISO rund um das Thema Software-Engineering können auf der Webseite https://pascal.computer.org/sev_display/index.action abgerufen werden.