Risikobasiertes Testen ist – wie der Name schon sagt – ein riskantes Unterfangen. Es ist alles andere als trivial, das Testvorgehen richtig und konsequent in einem IT-Projekt zu implementieren.

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.

Klicken zum vergrößern

 

Niedrige RPZ werden im grünen Bereich (unten links) der Risikobetrachtung abgebildet. Während steigende RPZ zunehmend in Richtung rot (oben rechts) tendieren.

Grafische Darstellung des Risikomanagement

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

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

Neuen Kommentar schreiben

Ihre E-Mail Adresse wird nicht veröffentlicht.

NEUESTE BEITRÄGE

Werde Werkstudent bei ITGAIN
29.11.2022

Werde Werkstudent bei ITGAIN

Sören Schmock

Als Werkstudent bei ITGAIN verdienst du neben deinem Studium nicht nur Geld, sondern sammelst wertvolle Erfahrung für dein späteres Berufsleben. Dabei achten wir darauf, dass du in der Regel zwischen 16 und 20 Stunden in der Woche arbeitest, da dein Hauptfokus auf dem Studium liegen soll.
Der Werkstudentenjob bei ITGAIN kann für dich der erste Schritt ins Berufsleben und ein Türöffner für deine eigene Entwicklung sein. Bei uns lernst du strategisch zu denken, zu präsentieren und dein Projekt zu managen. Du eignest dir zudem Soft Skills, wie den Umgang mit Kollegen, den Umgang mit Stress und Kritikfähigkeit an.

Expertise
Konzeption einer Data Governance-Initiative für einen Finanzdienstleister
13.10.2022

Konzeption einer Data Governance-Initiative für einen Finanzdienstleister

Team Data Governance

ITGAIN unterstützt in der stark regulierten Finanzbranche ein mittelständisches Bankinstitut bei der Umsetzung einer Data Governance-konformen Datenstrategie. Der Fokus liegt auf dem Ausgestalten, der durch Regularien wie BCBS239, MaRisk u. a. vorgeschriebenen Anforderungen. Hierbei werden alle relevanten Unternehmensbereiche, beginnend von der Kundenansprache, über Finanzbuchhaltung und Controlling bis hin zum Risikomanagement, betrachtet.

Data Engineering
Wichtige Details bei der Anbindung von DataStage an Snowflake
04.10.2022

Wichtige Details bei der Anbindung von DataStage an Snowflake | Umzug eines DWH auf eine Snowflake - Teil 6

Christian Hagen

In diesem letzten Teil der Blogreihe über einen Umzug von Oracle zu Snowflake wollen wir uns genauer die Besonderheiten in Jobs ansehen, auf die du bei der Anpassung der DataStage Jobs achten musst.

Data Engineering