Führung im Test: Risikobasiertes Testen
Hinweis der Redaktion: Willkommen zur Serie „Leadership In Test“ von Softwaretest-Guru und Berater Paul Gerrard. Die Serie soll Testern mit einigen Jahren Erfahrung – insbesondere jenen in agilen Teams – dabei helfen, in ihren Rollen als Testleiter und Testmanager zu glänzen.
Im vorherigen Artikel haben wir uns mit der Bedeutung von Testmodellen beschäftigt. Hier tauchen wir in das Konzept des Risikos ein und bieten ein Manifest für risikobasiertes Testen, das Sie auf Ihre eigene risikobasierte Testmethode anwenden können.
Abonnieren Sie den QA Lead Newsletter, um benachrichtigt zu werden, wenn neue Teile der Serie veröffentlicht werden. Diese Beiträge sind Auszüge aus Pauls Leadership In Test Kurs, den wir wärmstens empfehlen, wenn Sie tiefer in dieses und andere Themen eintauchen möchten. Falls Sie sich anmelden, nutzen Sie unseren exklusiven Gutscheincode QALEADOFFER für $60 Rabatt auf den vollen Kurspreis!
Risiken haben, wenn sie eintreten, einen negativen Einfluss auf unsere Projekte. Risikomanagement bedeutet, darüber nachzudenken, welche Risiken existieren, und Maßnahmen zu ergreifen, um deren Wahrscheinlichkeit zu verringern, sie zu eliminieren oder ihre Auswirkungen auf die Ziele unserer Stakeholder zu mindern.
In manchen Unternehmen wird Risikomanagement mit ingenieurmäßiger und mathematischer Präzision betrieben. Im Softwarebereich ist es jedoch nicht möglich, sehr präzise zu arbeiten. Die meisten Organisationen praktizieren risikobasiertes Testen immer noch nicht systematisch. Dafür gibt es jedoch berechtigte Gründe: Einmal identifizierte Risiken von Softwareprodukten sind oft unglaublich schwierig einzuschätzen.
Aus Sicht von Test und Qualitätssicherung ist ein Risiko eine „Fehlermöglichkeit, um die man sich sorgen muss“. Risikobasiertes Testen beschreibt die Praxis, potenzielle Fehlermuster eines Systems als Produktrisiken zu modellieren, um den Testumfang zu bestimmen, Skalierung und Priorisierung zu unterstützen.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
In diesem Artikel biete ich ein Manifest für risikobasiertes Testen an. Wir betrachten das klassische Risikomanagement und sehen uns an, wie wir es für Tester nützlich anpassen können. Abschließend gehen wir auf einige praktische Aspekte und Überlegungen ein, die Ihnen helfen werden, Ihre eigene risikobasierte Testmethode anzuwenden.
- Projekt-, Prozess- und Produktrisiko
- Ein Manifest für risikobasiertes Testen
- Der klassische Ansatz zum Umgang mit Risiken
- Produktrisiko und Testen
- Praktische Überlegungen
- Das Risikomanagement-Rolle des Testens verstehen
Wir verwenden folgende Definition von Risiko: Ein Risiko ist eine Bedrohung für eines oder mehrere Ziele der Stakeholder eines Projekts und hat eine unsichere Wahrscheinlichkeit.
Projekt-, Prozess- und Produktrisiko
Es gibt Hunderte von Büchern über Risiko und Risikomanagement, die zahlreiche Ansätze zum Management von Risiken auf Projektebene abdecken. Typischerweise konzentrieren sich diese Ansätze auf die von uns so genannten Projekt- und Prozessrisiken, mit vielleicht einem einzigen Risiko namens „Nichterfüllung der Anforderungen“. Das allein ist jedoch wenig hilfreich, da Sie für das Testen keine einzelne Anforderungsrisiko priorisieren können.
Es gibt drei Arten von Software-Risiken.
Projektrisiko: Diese Risiken beziehen sich auf das Projekt im eigenen Kontext. Projekte haben meist externe Abhängigkeiten wie die Verfügbarkeit von Fachkräften, die Abhängigkeit von Zulieferern, feste Zeitvorgaben oder Beschränkungen wie z. B. einen Festpreisvertrag. Für externe Abhängigkeiten ist das Projektmanagement verantwortlich.
Prozessrisiko: Diese Risiken beziehen sich vor allem auf das interne Projektgeschehen, insbesondere Planung, Überwachung und Steuerung des Projekts. Typische Risiken sind hier eine zu geringe Einschätzung der Projektkomplexität, des Aufwands oder der benötigten Fähigkeiten. Das interne Projektmanagement wie gute Planung, Fortschrittskontrolle und Steuerung sind alles Aufgaben des Projektmanagements.
Produktrisiko: Das Hauptrisikofeld für Tester ist das Produktrisiko. Diese Risiken betreffen die Definition des Produkts, die Stabilität (oder Instabilität) der Anforderungen, die Komplexität des Produkts und die Fehleranfälligkeit der Technologie.
Von nun an konzentrieren wir uns auf Produktrisiken. Wir verwenden den Begriff Produktrisiko wie folgt:
Ein Produktrisiko repräsentiert einen Modus oder ein Muster von Fehlern, das in einer Produktivumgebung inakzeptabel wäre.
Ein Manifest für risikobasiertes Testen
In Projekten, in denen Risiken eingegangen werden (was wohl auf alle zutrifft), müssen Tester den Entscheidern einen Überblick über die Risiken verschaffen und zuverlässige Testmethoden vorschlagen, um diese Risiken während des gesamten Projekts anzugehen.
Dies ist die Führungsaufgabe – die Durchführung und/oder Überwachung folgender Aufgaben beim risikobasierten Testen:
Der klassische Ansatz zum Risiko
Es gibt viele Variationen, aber der klassische Ansatz zum Risiko versucht, quantitativ zu sein.
Wahrscheinlichkeit, Konsequenz und Exposition
Um ein Produktrisiko zu bewerten, müssen wir verstehen, welche Konsequenz dieser Ausfallmodus hat. Wenn ein Fehler auftritt, sagen wir, das Risiko tritt ein. Dann fragen wir: „Wie schwerwiegend ist das Risiko?“, was auch als Exposition oder Risikobelastung bezeichnet wird.
Um die Exposition zu bestimmen, bewerten wir das Risiko in zwei Dimensionen:
- Die Wahrscheinlichkeit (oder das Eintreten) eines Risikos. Dieser Wert wird typischerweise als Prozentsatz zwischen (aber nicht einschließlich) null und 100 Prozent angegeben.
- Die Konsequenz (oder Auswirkung oder Verlust) eines Risikoeintritts. Dies ist der potenzielle Schaden, wenn dieser Ausfallmodus eintritt.
Die Exposition eines Risikos – wie schwerwiegend ein Risiko ist – wird als Produkt aus Wahrscheinlichkeit und Konsequenz berechnet.
Exposition = Risikowahrscheinlichkeit X Risikokonsequenz.
Dem klassischen Ansatz zum Risiko fehlt oft die technologische Unterstützung, die für ein effizientes Management nötig ist. Moderne Testmanagement-Lösungen schließen diese Lücke, indem sie speziell auf das risikobasierte Testen zugeschnittene Funktionen bieten.
Quantitative oder qualitative Bewertung
Es ist oft schwierig, die potenziellen Kosten eines Ausfalls vorherzusagen. Ohne weitere Informationen ist es ebenso fast unmöglich, die Wahrscheinlichkeit eines Fehlers mit großer Sicherheit vorherzusagen. Daher verwenden die meisten Praktiker halbquantitative oder qualitative Skalen für Wahrscheinlichkeit und Konsequenz.
Es ist gängig, Zahlenbereiche von eins bis fünf auf beiden Skalen zu verwenden, wodurch mögliche Werte für die Exposition zwischen eins und fünfundzwanzig entstehen. Aber nur wenige Tester, Entwickler oder Stakeholder vergeben diese Zahlen mit wirklichem Vertrauen, weshalb es üblich ist, die Risikobelastung direkt auf einer Skala von 1 bis 5 oder – noch einfacher – durch eine Rot-Gelb-Grün-Bewertung einzustufen. Manche gehen so weit, Risiken einfach als „im Scope“ oder „außerhalb des Scope“ zu bezeichnen, aber wir denken, das ist eine zu starke Vereinfachung.
Ganz gleich, ob Sie Risiken quantifizieren oder farblich kennzeichnen: Der kritische Aspekt von Risikoanalysen ist nicht die Bewertung selbst, sondern die Gespräche und Diskussionen, die Sie beim Festlegen und Diskutieren der Bewertungen führen.
Um Eisenhower falsch zu zitieren: Der Risiko-Plan ist nichts, die Risiko-Planung ist alles.
Wenn Sie aufgefordert werden, Risiken mit mehr Präzision als einer Skala von eins bis drei (oder maximal fünf) zu bewerten, sollten Sie ernsthaft hinterfragen, ob die von Ihnen zugewiesenen Zahlen tatsächlich einen Wert haben.
Eine numerische Bewertung kann den Eindruck wissenschaftlicher Genauigkeit vermitteln, aber wenn die Zahlen geraten sind, täuschen Sie sich selbst. Wenn Zahlen Meinungsunterschiede offenbaren, z. B. ein Benutzer sagt „fünf“ und der Entwickler sagt „eins!“, dann steckt dahinter eine Diskussion, denn die Erwartungen oder Wahrnehmungen weichen offenbar voneinander ab.
Vorsicht vor einer einfachen „im Scope/außerhalb Scope“-Einteilung von Risiken. Es mag klar sein, welche relevanten Risiken durch Tests adressiert werden sollen. Projekte verändern sich jedoch im Laufe der Zeit und geraten häufig ins Stocken, sodass Kompromisse erforderlich sind. Wenn Risiken nicht irgendwie priorisiert werden, müssen Sie regelmäßig alle relevanten Risiken überprüfen, um zu entscheiden, welche ggf. aus dem Scope entfernt oder hinzugefügt werden sollen.
Wir werden das Thema Scoping, Priorisierung und Skalierung in nachfolgenden Artikeln noch ausführlicher behandeln – bleiben Sie also dran.
Produktrisiko und Testen
Die Diskussion über (Produkt‑)Risiken bringt die Befürchtungen von Stakeholdern bezüglich der Eintrittswahrscheinlichkeit von Fehlern in kritischen Projekt- oder Systembereichen zum Vorschein. Angenommen, wir haben eine Liste von Produktrisiken – wie leiten wir daraus konkrete Maßnahmen und Testpläne ab? Bevor wir diese Frage beantworten, müssen wir besser verstehen, wie das Testen unsere Risikoanalyse beeinflusst.
Testen reduziert Risiken nicht – es informiert Risikobewertungen
Sie werden oft hören, dass „Testen Risiken reduziert“. Das stimmt nicht – manchmal erhöht Testen sogar Risiken. Das Mantra vom Testen als Risikoreduzierung entspringt einem mangelnden Verständnis sowohl von Risiken als auch vom Testen selbst.
Nehmen wir an, wir haben ein Risiko identifiziert, dass eine Funktion oder ein Feature fehlschlagen könnte. Wir formulieren einen Test und führen ihn durch. Der Test kann bestehen oder fehlschlagen. Wie würde ein Test-Ergebnis unsere Risikobewertung beeinflussen?
Zunächst einmal hat Testen keinen Einfluss auf unser Verständnis der Konsequenz eines Fehlers. Die Auswirkung eines Fehlers bleibt dieselbe, Testen verändert diese Tatsache nicht.
Es gibt vier relevante Testergebnisse und deren Einfluss auf die Risikowahrscheinlichkeit. Diese sind in der folgenden Tabelle zusammengefasst:
| Wahrscheinlichkeit des Risikos steigt | Wahrscheinlichkeit des Risikos sinkt | |
| Test besteht | Nein. Ein bestandener Test kann uns nur ein stärkeres Vertrauen geben, dass ein Fehler nicht auftritt. (Dies setzt voraus, dass unsere Tests aussagekräftig sind). | Ja, mit der Zeit. Je mehr und mehr Tests wir durchführen, die bestehen, und je vielfältiger die Szenarien werden, desto geringer wird die Wahrscheinlichkeit eines Fehlers. |
| Test fällt durch | Möglich, abhängig vom Fehler. Aber die Wahrscheinlichkeit sinkt mit der Zeit. Wir haben vorhergesagt, dass dieser Fehler auftreten könnte; unsere Testauswahl war richtig. Zum Glück können wir dies jetzt beheben und unsere Tests darauf konzentrieren, das Risiko weiterer Fehler dieses Typs zu reduzieren. | Wahrscheinlich nicht, es sei denn, unsere Risikobewertung war falsch. |
Das Durchführen von Tests, die wir mit einem bestimmten Risiko verbinden, liefert uns immer mehr Informationen, um unsere Risikoeinschätzung zu verfeinern. Wenn Tests fehlschlagen, war unsere Wahl richtig. Wenn wir beheben und erneut testen, sollte unsere Risikoeinschätzung mit bestandenen Tests sinken. Wenn wir aber immer wieder neue/weitere Bugs finden, könnten wir das Risiko als höher einstufen.
Beachten Sie: Wenn Sie einen Test durchführen und das Ergebnis Ihre Wahrscheinlichkeitsbewertung in keine Richtung beeinflusst – ist es wahrscheinlich ein wertloser Test.
Nun verstehen Sie das Potenzial von Tests, um unsere Risikobewertung zu informieren. Deshalb können wir jetzt betrachten, wie wir Tests aus Risikobeschreibungen ableiten.
Risikobasierte Testplanung
Als Tester müssen wir, sobald wir ein wichtiges Produktrisiko identifiziert haben, eine Reihe von Tests formulieren, die zeigen, dass diese Fehlerart weniger wahrscheinlich ist. Natürlich besteht unser Testansatz darin, den Fehler möglichst vielseitig zu provozieren. Dabei gilt:
- Fehler und Bugs treten auf, wir entdecken und beheben sie (dadurch sinkt das Risiko dieser Fehlerart), oder
- Tests bestehen, und unser Vertrauen, dass diese Fehlerart unwahrscheinlich ist, steigt.
Zusammengefasst konzentrieren sich unsere Tests darauf, die verschiedenen Arten eines bestimmten Fehlerschlags zu identifizieren. Angenommen, das Risiko wäre „falsche Berechnung einer Kfz-Versicherungsprämie“. Ein passendes Testziel wäre in diesem Fall: „Nachweisen, dass das System die Kfz-Prämie korrekt berechnet, indem die All-Pairs-Technik für Eingabevariablen eingesetzt wird.“ Dieses Testziel könnte einem Tester übergeben werden, der daraus mithilfe von All-Pairs eine abdeckende Menge an Testfällen ableitet.
Praktisches
Nun einige praktische Überlegungen zum risikobasierten Testen.
Was, wenn Stakeholder kein Interesse haben, bei der Risikobewertung zu helfen?
Es kann sein, dass es schwierig ist, sich die Zeit der Stakeholder zu sichern, um Sie bei der Identifizierung und Bewertung von Risiken sowie bei der Entwicklung Ihres Testplans zu unterstützen.
Was, wenn es mehrere Testoptionen für ein Produktrisiko gibt?
Das ist natürlich fast immer der Fall. Um eine relevante Funktion zu testen, könnten Sie etwa verschiedene Testentwurfsverfahren anwenden oder das Feature in einer besonderen Weise modellieren und daraus Tests ableiten. Es stehen verschiedene Abdeckungsmaße zur Verfügung, mit denen Sie ein Ziel setzen können. Sie könnten ein Feature manuell testen, mit einem Tool oder anderer Technologie.
Wie Sie in einem solchen Fall Entscheidungen treffen könnten, zeigen wir im nächsten Artikel: ‚Wie viel Testen ist genug?‘.
Was, wenn das Testen (um ein Risiko zu adressieren) zu teuer wird?
Da es fast immer verschiedene Optionen gibt und im Grunde keine Grenze dafür existiert, wie viel getestet werden könnte, um ein Risiko zu untersuchen und eine Risikobewertung zu erstellen, muss eine Entscheidung getroffen werden. Selbstverständlich werden manche Optionen als zu teuer betrachtet. Wenn Sie Stakeholdern Optionen präsentieren, sollten Sie also mindestens eine bezahlbare und eine eventuell unbezahlbare Variante bereitstellen.
Auch darauf gehen wir im nächsten Artikel ein: ‚Wie viel Testen ist genug?‘
Wenn wir riskantere Features mehr testen, testen wir andere weniger, oder?
Wenn das Testbudget für ein Team vorgegeben oder die Teamgröße und Anzahl der Tester fixiert ist, dann ist der Umfang der Tests, die im vorgegebenen Zeitrahmen durchgeführt werden können, begrenzt. Legen wir also mehr Gewicht auf bestimmte Features, reduziert sich das Testen für andere. Der Umfang der Abdeckung oder zumindest der Testaufwand für einzelne Features variiert entsprechend dem Risiko.
Man kann es so sehen: Wenn ein Test fehlschlägt und ein Fehler im System gefunden wird, wird der Schweregrad dieses Fehlers wahrscheinlich eng mit den Folgen des Fehlers (im Produktivbetrieb) zusammenhängen. Schwerwiegende Fehler werden behoben, weil sie für Stakeholder wichtiger sind.
Eine Produktrisikoanalyse hebt die Bereiche hervor, in denen Fehler (weil sie wichtig sind) mit höherer Wahrscheinlichkeit behoben werden. Die Risikoanalyse zeigt also, wo (mehr) getestet werden sollte. Das bedeutet, dass wir eher wichtige Fehler entdecken und weniger solche, die für Stakeholder weniger wichtig sind.
Es wäre schön, wenn wir manchmal überall gleichmäßig testen könnten. Doch wo Ressourcen und Zeit begrenzt sind (und das sind sie immer, nicht wahr?), hilft ein risikobasierter Ansatz dabei, die Zeit der Tester effektiver und effizienter einzusetzen.
Was, wenn Testen nicht die richtige Antwort ist?
Bevor Sie Zeit investieren, um einen Testansatz für ein Produktrisiko im Detail zu entwickeln, ist es wichtig, auch Nicht-Testoptionen zu berücksichtigen. Angenommen, es gibt große Bedenken, dass eine Systemkomponente in der Produktion nicht ausreichend performant ist und die Antwortzeiten oder Zuverlässigkeit schlecht sind. Natürlich könnten Sie Lasttests durchführen und versuchen, sich aus den Problemen herauszudebuggen. Aber andere Optionen könnten sein:
- Kaufen Sie die Komponente von einem Drittanbieter, bauen Sie sie nicht selbst und vermeiden Sie das Risiko.
- Gestalten Sie die Lösung um, um Lasten auf mehrere Komponenteninstanzen zu verteilen.
- Verlagern Sie die Verarbeitung auf ein Batch-System mit einer Kopie der Daten.
- Statt eine Big-Bang-Einführung für alle Nutzer durchzuführen, wählen Sie einen schrittweisen Ansatz und setzen Sie die Kundenregionen nach und nach um, während Sie die Performance genau überwachen.
- Und so weiter.
Oft ist ein anderer Handlungsweg, um Probleme von vornherein zu vermeiden, effektiver und wirtschaftlicher als spätere Tests, die diese Probleme erst aufdecken.
Die Rolle des Testens im Risikomanagement verstehen
Testen kann das Risiko bei der Veröffentlichung reduzieren. Wenn wir unsere Testaktivitäten durch eine Risikobewertung steuern lassen, besteht das ausdrückliche Ziel der Tester darin, Tests so zu entwerfen, dass Fehler erkannt und behoben werden können und so das Risiko eines fehlerhaften Produkts gesenkt wird.
Die Fehlersuche reduziert das Restrisiko von Fehlern im Live-Betrieb, wo die Kosten sehr steil ansteigen. Wenn ein Test einen Fehler findet und dieser behoben wird, sinkt die Fehleranzahl und damit verringert sich auch die allgemeine Wahrscheinlichkeit eines Ausfalls.
Man könnte es auch so sehen: Das „Mikro-Risiko“, das mit diesem Fehler verbunden war, ist beseitigt. Es muss jedoch bedacht werden, dass Tests nie alle Fehler finden können, daher gibt es immer latente Fehler, über die die Tests keine direkte Information liefern.
Wenn wir uns jedoch auf kritische Funktionen konzentrieren und darin Fehler finden, sind unentdeckte Fehler in diesen kritischen Funktionen weniger wahrscheinlich. Die verbleibenden Fehler in nicht-kritischen Systemteilen sind weniger folgenreich.
Ein letzter Hinweis: Der Prozess der Risikoanalyse ist selbst mit Risiken behaftet. Risikoanalysen können Risiken sowohl über- als auch unterschätzen und so zu weniger optimalen Entscheidungen führen. Wird sie zu weit getrieben, kann Risikoanalyse zudem eine Kultur der Schuldzuweisung fördern.
Neben weiteren möglichen Fallstricken bei der Risikoanalyse muss klar sein, dass es so etwas wie ein absolutes Risiko, das sich nach Abschluss des Projekts berechnen ließe, nicht gibt. Risiken sind ihrem Wesen nach unsicher. Wie bei der Wirksamkeit von Tests lässt sich der Wert einer Risikoanalyse immer erst im Nachhinein, nach Abschluss des Projekts, beurteilen.
Das war unser Manifest für risikobasiertes Testen. Das Konzept wird in der Reihe "Führung im Test" regelmäßig wieder aufgegriffen – bleiben Sie also dran für weitere Artikel!
Abonnieren Sie den Newsletter von The QA Lead, um benachrichtigt zu werden, sobald neue Teile der Serie veröffentlicht werden. Diese Beiträge sind Auszüge aus Pauls Führung im Test Kurs, den wir sehr empfehlen, wenn Sie tiefer in dieses und andere Themen einsteigen möchten. Wenn Sie sich anmelden, nutzen Sie unseren exklusiven Gutscheincode QALEADOFFER und sparen Sie $60 auf den vollen Kurspreis!
