Risikobasiertes Testen: Testaufwand mit einer Risikomatrix priorisieren

Was risikobasiertes Testen ist

Der ISTQB beschreibt Risiko als Kombination aus zwei Größen. Die Eintrittswahrscheinlichkeit sagt, wie wahrscheinlich ein Modul, eine Funktion oder eine Änderung einen Fehler enthält. Die Auswirkung sagt, was passiert, wenn dieser Fehler in Produktion auftritt: finanzieller Schaden, betroffene Kunden, Folgen bei der Aufsicht, Störungen im Betrieb.

Gemeint sind Produktrisiken, also Risiken in der Software selbst. Projektrisiken wie Personalengpässe oder späte Lieferungen gehören in die Projektplanung, nicht in die Testpriorisierung.

Risikobasiertes Testen ist keine Abkürzung. Es macht die Entscheidung sichtbar, die jedes Projekt ohnehin trifft: wo es genau hinschaut und wo nicht.

In fünf Schritten zur Risikomatrix

1. Zerlegen Sie das System in Prüfobjekte, die sich getrennt testen lassen: Module, Geschäftsvorfälle oder die Änderungen eines Releases. 10 bis 40 Einträge sind ein guter Rahmen.
2. Bewerten Sie die Eintrittswahrscheinlichkeit von 1 bis 5. Anhaltspunkte sind Fehler in früheren Releases, Umfang und Art der Änderungen, Komplexität, Zahl der Schnittstellen, neue Technik und die Erfahrung des Teams mit dem Modul.
3. Lassen Sie den Fachbereich die Auswirkung von 1 bis 5 bewerten. Wie viel Geld steht im Feuer, wie viele Kunden merken es, muss der Fehler der Aufsicht gemeldet werden, steht der Betrieb still?
4. Berechnen Sie das Risiko als Eintrittswahrscheinlichkeit × Auswirkung. Das ergibt Werte von 1 bis 25.
5. Ordnen Sie jeder Risikoklasse eine Testtiefe und einen Platz in der Reihenfolge zu.

Beispiel

Ein Versicherer bringt ein Release für sein Kundenportal. Test und Fachbereich bewerten fünf Prüfobjekte, die Matrix oben zeigt das Ergebnis.

Der Rechenweg für die Beitragsberechnung: Sie wurde für den neuen Tarif umgebaut und hatte im letzten Release zwei Fehler, also Wahrscheinlichkeit 4. Ein Rechenfehler trifft jeden Neukunden und ist aufsichtsrechtlich relevant, also Auswirkung 5. 4 × 5 = 20 ergibt die höchste Priorität. Die Adressänderung dagegen wurde kaum angefasst und ein Fehler wäre ärgerlich, aber schnell behoben: 2 × 2 = 4, niedrig.

Die Klassen im Beispiel sind 15–25 hoch, 8–14 mittel und 1–7 niedrig. Die Grenzen legt jedes Projekt selbst fest und schreibt sie in die Teststrategie.

Für Ihre eigenen Module können Sie die Matrix mit dem Risikomatrix-Rechner aufstellen. Er läuft nur in Ihrem Browser und speichert nichts.

Von der Klasse zur Testtiefe

Klasse	Reihenfolge	Testtiefe
hoch	zuerst, schon in frühen Teststufen	systematische Testverfahren wie Grenzwertanalyse und Entscheidungstabellen, Review der Anforderungen, Tests auf mehreren Teststufen, automatisierte Regression, Abnahme durch den Fachbereich
mittel	danach	Standardverfahren, Positiv- und wichtigste Negativfälle, Regression für die Kernabläufe
niedrig	zuletzt, bei Zeitdruck zuerst gekürzt	Stichprobe, Smoke-Test oder explorativer Test

Eine Regel schützt vor einem Fehlschluss. Das Produkt behandelt 5 × 1 und 1 × 5 gleich, aber ein seltener Fehler mit verheerender Wirkung ist etwas anderes als ein häufiger mit geringer. Viele Projekte legen deshalb fest, dass Auswirkung 5 immer mindestens „mittel“ ist, egal wie niedrig die Wahrscheinlichkeit.

Nach jedem Release neu bewerten

Die Matrix ist eine Momentaufnahme. Neue Änderungen verschieben die Wahrscheinlichkeit, neue Produkte die Auswirkung. Bewerten Sie vor jedem Release neu und halten Sie fest, wer wann wie eingestuft hat. So können Fachbereich, Revision und Aufsicht jede Priorität nachvollziehen. Für Banken stützt diese Dokumentation das Testprogramm, das DORA verlangt.

Grenzen

Bewertungen sind Einschätzungen, und zwei Personen kommen zu unterschiedlichen Werten. Bewerten Sie deshalb im Team und mit klaren Kriterien je Stufe.

Niedriges Risiko heißt nicht „kein Test“, sondern weniger Tiefe, bewusst entschieden. Und die Methode ersetzt keine Pflichttests: Was Gesetz, Aufsicht oder Vertrag verlangen, wird getestet, unabhängig vom Wert in der Matrix.

Am schwächsten sind Wahrscheinlichkeiten aus dem Bauch. Belastbarer wird die Bewertung mit Daten aus Fehlerhistorie und Änderungen. Wie KI dabei helfen kann und wo sie an Grenzen stößt, steht im Artikel Eintrittswahrscheinlichkeit von Fehlern mit KI schätzen.