Risikobasiertes Testen reicht allein nicht aus

Was ist ein Risiko?

Gemäß ISTQB® Certified Tester Foundation Level wird zwischen Projekt- und Produktrisiko unterschieden. Das Risiko selbst ist ein Faktor, der zu negativen Konsequenzen in der Zukunft führen könnte, gewöhnlich ausgedrückt durch das Schadensausmaß und die Eintrittswahrscheinlichkeit[1].

Ein Risiko weist typischerweise 3 Dimensionen auf:

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

Beim risikobasierten Testen orientiert sich das Testmanagement bei der Entscheidung „was, wie umfangreich, wo getestet wird“ an einer zuvor getätigten Risikobewertung und der berechneten Risikoprioritätszahl (RPZ).

Die 5 Phasen der Risikobewertung

Risiken identifizieren: Unabhängig von der Software muss geklärt sein, mit welchen 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 einen Einfluss auf die Wertschöpfungskette oder Auswirkungen auf regulatorische Anforderungen hat.

Die Identifizierung von Risiken erfolgt meist in Form von Experten-Brainstorming Sitzungen. Eine bewährte Vorgehensweise ist es 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 analysieren: Zu jedem identifizierten Risiko werden systematisch weitere Informationen ergänzt. Sinnvoll ist dabei die Verwendung von Risikotemplates, in denen Risikokategorien festgelegt sind, wie z.B. betroffene Funktion, erwartete Fehlerart, mögliche Ursache, möglicher Auslöser, Verursacher, Art des Risikos. Dabei wächst die Risikoliste, da im Rahmen der Analyse selbst weitere Risiken identifiziert werden.

Risiken bewerten: Dabei liegt der Fokus auf der Priorisierung der identifizierten und analysierten Risiken. Den Schlüssel dazu bilden nachvollziehbare Bewertungskategorien für die Eintrittswahrscheinlichkeit einer Abweichung (unerwartetes Ereignis) und den daraus resultierenden Schäden.

Aus unserer Erfahrung heraus stellt die Einstufung der Wahrscheinlichkeit des Eintretens einer Schadensauswirkung die größte Herausforderung dar. Im Falle von Software spielen zwei Quell-Faktoren bei der Risikobewertung eine entscheidende Rolle.

1. Der erste relevante Faktor basiert auf dem Quellcode oder den Konfigurationseinstellungen der Software, die zu einer Abweichung führen können. Dies wird als Fehlerzustand bezeichnet.
2. 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 empfehlen wir die Einbindung von Vertretern des IT-Infrastrukturteams bzw. der Software-Entwicklung.

Maßnahmen definieren/implementieren: Es reicht nicht, eine Maßnahme festzulegen, sie muss auch durchgeführt werden. Erst nach Durchführung kann beurteilt werden, ob sie wirksam ist.

Verbleibende Risiken (neu) bewerten: Die Wirksamkeit der zuvor festgelegten Maßnahmen muss (neu) bewertet werden – 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 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.

Risikobewertung

Die Risikobewertung bringt zusätzlichen Aufwand mit sich, da sie als eine Kombination aus

• Wahrscheinlichkeit des Auftretens einer Abweichung: gering [1] bis hoch [10],
• Entdeckungswahrscheinlichkeit eines Fehlers: gering [10] bis hoch [1] und
• Schweregrad des resultierenden Schadens: gering [1] bis hoch [10]

definiert wird.

Die Risikoprioritätszahl (RPZ) ist das Produkt aus Wahrscheinlichkeit des Auftretens der Abweichung, Entdeckungswahrscheinlichkeit eines Fehlers und Schweregrad des resultierenden Schadens bzw. Auswirkung des Fehlers und kann einen Wert zwischen 1 und 1000 annehmen.

Bevor im Projekt mit dem Risikomanagementprozess begonnen werden kann, muss für alle Prozessbeteiligten transparent sein, was einen Schaden für das Projekt 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.

In unseren Projekten ermitteln Experten (z.B. Projektleiter, Testmanager, Fach- und Testteam) die Wahrscheinlichkeit einer Abweichung als hoch (z.B. 9 von 10), die Entdeckungswahrscheinlichkeit als mittel (z.B. 5 von 10) und die Auswirkung des Fehlers als niedrig (z.B. 3 von 10). Dann berechnet sich die RPZ als 9 x 5 x 3 = 135.

Oftmals verwenden wir einen tabellarischen Aufbau, der sich grafisch darstellen lässt.

Fazit

Bei einer Gleichverteilung der verfügbaren Testressourcen auf alle Testobjekte werden kritische und unkritische Programmteile oftmals gleich intensiv getestet. Das hat zur Folge, dass die kritischen Programmteile nicht ausreichend getestet werden und bei unkritischen Teilen Ressourcen verschwendet werden. Risikobasiertes Testen verhindert dies, da den komplexen oder technisch herausfordernden Testobjekten eine höhere Testpriorität zugewiesen wird. Zu beachten gilt, dass die Risikobewertung auf Experteneinschätzung und Annahmen beruht.

Wir orientieren uns im Testmanagement an einer Risikobewertung und nutzen die RPZ zur Priorisierung der Testaktivitäten.

Testaufwände, wie

• das Erstellen der Testspezifikation
• das Erstellen des Testskript für automatische Tests, oder
• das Erstellen des Testablaufs für manuelle Tests,
• die Testdurchführung
• die Auswertung der Ergebnisse

können mit diesem Verfahren effizient gesteuert werden.

Es ist eine Fehlannahme, dass der risikobasierte Testansatz Geld spart, da weniger getestet wird. Es wird gezielt dort getestet, wo viel Geld verloren geht, wenn es zu Abweichungen kommt. Risikobasiertes Testen trägt zur Steigerung des Return on Investment (ROI) bei.

Entscheidend ist, mit welchen Testfallentwurfsverfahren Sie den Risiken entgegenwirken. Es sollten angemessene Verfahren zum Aufbau von Testfällen zum Tragen kommen.

Unsere Experten unterstützen Sie in Ihren Projekten, auch durch geeignete methodische Testfallentwurfsverfahren wie z.B. Black-Box- und White-Box-Testverfahren sowie dem erfahrungsbasierten Test.

Gerne schulen wir Ihr Fach- und Testteam in der praxisgerechten Anwendung von Testfallverfahren.

Kontaktieren Sie uns gerne unverbindlich, um noch mehr über unser Angebot zu erfahren.

[1] ISTQB® Glossary