Risikobasiertes Testen reicht allein nicht aus
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.
...weiter lesen
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.
Ein Risiko weißt typischer Weise 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).
Ein Risiko weißt typischer Weise 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).
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.
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.
Die Risikobewertung bringt zusätzlichen Aufwand mit sich da sie als eine Kombination aus
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.
Niedrige RPZ werden im grünen Bereich (unten links) der Risikobetrachtung abgebildet. Während steigende RPZ zunehmend in Richtung rot (oben rechts) tendieren.
- 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.
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.
Niedrige RPZ werden im grünen Bereich (unten links) der Risikobetrachtung abgebildet. Während steigende RPZ zunehmend in Richtung rot (oben rechts) tendieren.
Video
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.
Ich orientiere mich im Testmanagement an einer Risikobewertung und nutzen die RPZ zur Priorisierung der Testaktivitäten.
Testaufwände, wie
Ich unterstütze Sie in Ihren Projekten, auch durch geeignete methodische Testfallentwurfsverfahren wie z.B. Black-Box- und White-Box-Testverfahren sowie dem erfahrungsbasierten Test.
Gerne schule ich Ihr Fach- und Testteam in der praxisgerechten Anwendung von Testfallverfahren.
Kontaktieren Sie mich gerne unverbindlich, um noch mehr über mein Angebot zu erfahren.
Ich orientiere mich 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.
Blog
Ersetzt Künstliche Intelligenz (KI) uns menschliche Tester?
“Die KI ist ein mächtiges Werkzeug, das den manuellen, menschlichen Softwaretest verbessern, aber nicht ersetzen kann. Die menschlichen Tester sind weiterhin unverzichtbar für den Erfolg des Softwaretests. Sie müssen sich jedoch an die Veränderungen anpassen, die die KI mit sich bringt. Sie müssen lernen, wie sie mit der KI zusammenarbeiten können, um ihre Stärken zu nutzen und ihre Schwächen auszugleichen. Sie müssen auch ihre Fähigkeiten weiterentwickeln, um ihre Werte zu steigern und ihre Karriere zu fördern. Die Zukunft des Softwaretests ist also nicht eine Konkurrenz zwischen Menschen und Maschine, sondern eine Kooperation zwischen Mensch und Maschine. Die KI ist kein Feind, sondern ein Freund der menschlichen Tester.”
Warum sich Software weiterentwickeln muss
“Für die Weiterentwicklung von Software gibt es eine Vielzahl von guten Gründen. Allen gemein ist, dass ein kontinuierlicher und iterativer Prozess, der eine ständige Überwachung und Bewertung erfordert, unabdingbar ist. Die Weiterentwicklung von Software ist eine notwendige und lohnende Investition für die Schaffung eines qualitativ hochwertigen und nachhaltigen Produkts. Wenn auch Sie hochwertige und nachhaltige Software entwickeln wollen, sprechen Sie uns gerne an. Wir beraten Sie gerne im Softwareentwicklungsprozess und unterstützen Sie vom Anforderungsmanagement über die Entwicklung, bis hin zum Softwaretest.”
Kayla Bryant
“There live the blind texts. Separated they live in Bookmarksgrove right at the coast of the Semantics, a large language ocean.”
Lade...