Risikobasiertes Testen: die richtige Testtiefe bestimmen

Testressourcen sind endlich, die Zahl möglicher Test Cases ist es nicht. Wer alles gleich intensiv testet, verbrennt Zeit an unkritischen Stellen und übersieht am Ende die eine Funktion, deren Ausfall den Umsatz kostet. Risikobasiertes Testen löst das, indem es den Testaufwand am Risiko ausrichtet, nicht an der Reihenfolge im Anforderungsdokument.

Was risikobasiertes Testen bedeutet

Risikobasiertes Testen ist ein im ISTQB-Lehrplan beschriebener Ansatz, bei dem Produktrisiken die Auswahl, Priorisierung und Testtiefe beeinflussen. Jede Anforderung wird nach ihrem Risiko bewertet, und dieses Risiko steuert, wie tief getestet wird. Hohe Risiken bekommen viele, gründliche Test Cases; niedrige Risiken einen schlanken Nachweis. So wird der Testplan zu einer begründeten Prioritätenliste statt einer beliebigen Abarbeitung.

Risiko = Eintrittswahrscheinlichkeit × Auswirkung

Das Risiko einer Anforderung ergibt sich aus zwei Faktoren, die man je auf einer einfachen Skala (etwa 1 bis 3) einschätzt:

• Eintrittswahrscheinlichkeit: Wie wahrscheinlich ist ein Fehler? Treiber sind technische Komplexität, häufige Änderungen, unklare Anforderungen, neue Technologie oder externe Schnittstellen.
• Auswirkung: Was passiert, wenn es schiefgeht? Umsatzverlust, rechtliche Folgen, Datenverlust, Reputationsschaden oder blockierte Kernprozesse.

Das Produkt beider Werte ergibt eine Rangfolge. Eine Anforderung mit hoher Wahrscheinlichkeit und hoher Auswirkung landet oben, eine kosmetische Funktion mit geringer Auswirkung unten.

Von der Risikoklasse zur Testtiefe

Die Risikoklasse bestimmt die Testtiefe:

• Hohes Risiko: mehrere Test Cases je Anforderung, negative und Grenzwertfälle, End-to-End- und Integrationstests, oft zusätzlich automatisiert für die Regression.
• Mittleres Risiko: die wichtigsten positiven Pfade plus die kritischsten Fehlerfälle.
• Niedriges Risiko: ein schlanker Bestätigungstest, dokumentiert, aber nicht überfrachtet.

Wichtig ist der Nachweis: Über eine Requirements-Traceability-Matrix lässt sich zeigen, dass jede Anforderung entsprechend ihrem Risiko abgedeckt ist. Das ist der Unterschied zwischen „wir haben getestet“ und „wir können belegen, was wie geprüft wurde“.

Ein kurzes Beispiel

Bei einem SaaS-Release fielen vier Anforderungen als Hoch-Risiken auf: Zahlungsstrecke, Mahnwesen, Rollenmodell und Single Sign-On. Zahlungsstrecke und Rollenmodell verbinden hohe Auswirkung (Umsatz, Sicherheit) mit hoher Wahrscheinlichkeit (viele Änderungen, externe Schnittstellen). Genau dorthin floss der Großteil der Test Cases, während ein selten genutztes Export-Feature mit einem einzigen Bestätigungstest auskam. Das Ergebnis war kein Bauchgefühl, sondern ein Risikobild, eine Empfehlung und eine klare Liste offener Punkte vor dem Go-live.

Fazit

Risikobasiertes Testen macht Testmanagement überhaupt erst steuerbar: Es begründet, warum an einer Stelle mehr und an anderer weniger getestet wird, und liefert eine belastbare Grundlage für die Release-Entscheidung. Wer den Testaufwand am Risiko ausrichtet, findet die teuren Fehler zuerst, nicht zufällig.