Risikobasiertes Testen bedeutet, Testaufwand dort zu konzentrieren, wo ein Fehler den größten Schaden anrichtet. Drei Faktoren bestimmen das Risiko: Schadenspotenzial, Auffindbarkeit und Komplexität. Wer diese Faktoren multipliziert, erhält eine Kennzahl. Je höher sie ausfällt, desto mehr Testabdeckung ist in diesem Bereich nötig.
Das Wichtigste in Kürze
- Risikobasiertes Testen hat bei der Bison Gruppe dazu geführt, dass 50 bis 60 Prozent der alten End-to-End-Tests ersatzlos gestrichen werden konnten, weil sie auf niedrigere Teststufen verlagert oder als überflüssig erkannt wurden.
- Risiken lassen sich am besten über Domänen aufteilen, zum Beispiel Verkauf, Wareneingang oder Stammdaten, und dann darunter konkret benennen, was auf keinen Fall schiefgehen darf.
- Die Bewertung jedes Risikos aus drei Faktoren, Schadenspotenzial, Auffindbarkeit und Komplexität, jeweils auf einer Skala von 1 bis 3 multipliziert, ergibt eine Kennzahl, die Priorisierungsentscheidungen objektivierbar macht.
- Risikobasiertes Testen schafft Qualitätsbewusstsein durch die gesamte Entwicklungskette, von der Anforderungsanalyse bis zur Implementierung, weil alle Beteiligten sehen, wo Fehler den größten Schaden anrichten.
- Ein Risikokatalog ist kein einmaliges Dokument, sondern muss bei neuen Anforderungen und nach jedem Bug-Feedback neu bewertet werden, um seine Steuerungswirkung zu behalten.
Risikobasiertes Testen beginnt mit einer Schlagzeile
Der schnellste Einstieg ins risikobasierte Testen ist eine einfache Frage: Welche Schlagzeile möchtest du morgen nicht in der Zeitung lesen? Aus dieser Schlagzeile formulierst du ein Risiko, und aus dem Risiko leitest du ab, wo getestet werden muss.
Das Beispiel dahinter ist greifbar. Ein Rechnungslauf produziert 4.500 Rechnungen, und irgendwo summiert das System falsch oder zieht den falschen Steuersatz. Der Kunde muss die Rechnungen zurückholen, der Schaden ist auf beiden Seiten hoch. Genau solche Fälle markieren den Punkt, an dem Testaufwand sich lohnt.
Der Vorteil dieser Frage: Der Kunde weiß am besten, wo es ihm am meisten wehtut. Stellst du sie ihm direkt, hast du dein Schadenspotenzial oft schon ermittelt, bevor irgendein Testfall geschrieben ist.
Wie ein Risiko bewertet wird
Bei der Bison Gruppe ruht die Risikobewertung auf drei Komponenten: Schadenspotenzial, Auffindbarkeit und Komplexität. Jede wird auf einer Skala von 1 bis 3 bewertet, die Werte werden multipliziert. Je höher die resultierende Kennzahl, desto genauer musst du hinschauen.
Uwe Paesch beschreibt die Logik am Rechnungs-Beispiel. Das Schadenspotenzial ist hoch, weil der Kunde tausende Rechnungen zurückholen muss. Die Auffindbarkeit ist hoch, weil der Fehler nicht auf den ersten Blick sichtbar ist. Die Komplexität ist hoch, weil der Fehler schwer zu finden ist. Drei hohe Werte ergeben ein High Risk.
Ein hoher Gesamtwert ist nicht das einzige Signal. Wer überall hoch bewertet, bekommt automatisch hohe Zahlen. Behalte deshalb auch die Risiken mit hohem Schadenspotenzial im Auge, selbst wenn sie schnell bemerkt und leicht behoben werden. Geht so ein Fehler zum Kunden, fragt der trotzdem dreimal, ob das noch geht.
So schneidest du Risiken in der richtigen Flughöhe
Der erste Schritt ist nicht die Bewertung, sondern der Schnitt. Definiere zuerst Themengebiete, dann nimmst du die Risiken darunter leichter auf.
Bei einem ERP-System bieten sich Domänen an: Verkauf, Bestellung, Wareneingang, Lieferung, Schnittstellen, Stammdaten. Bei einer mobilen App eher die Funktionalität der App selbst und die Kommunikation mit den Umsystemen. Erst wenn dieser Cluster steht, überlegst du je Bereich, was auf keinen Fall schiefgehen darf.
Die häufigste Falle ist die falsche Flughöhe. “Der Verkauf geht nicht” ist als Risiko zu grob, einzelne Detailfälle sind zu fein. Trifft man diese Ebene nicht, sind die Bewertungen unbrauchbar, das eine zu tief, das andere viel zu hoch. Für ein ERP-System landet man so bei rund 150 Risiken, im Bereich Verkauf etwa bei einem Dutzend.
Wer anfängt, sollte klein starten. Erst Fachgebiete, dann herunterbrechen. Die ersten Schritte zählen mehr als der perfekte Katalog.
Risikobasiertes Testen lohnt sich besonders bei einer Migration
Eine Migration ist der ideale Anlass, um risikobasiert vorzugehen. Bison stand vor genau diesem Fall: Ablösung eines Rich Clients durch einen Webclient, dazu rund 1.000 End-to-End-Tests, die übertragen werden sollten.
Statt jeden alten Test eins zu eins nachzubauen, fiel die Entscheidung für Testabdeckung dort, wo es dem Kunden am meisten wehtut. Man stellte einen Risikokatalog auf, identifizierte die höchsten Risiken und zog Business-Leute, Entwickler und Architekten in die Bewertung. Erst danach prüfte man, welche Tests es schon gab, ob sie erweitert werden mussten und wo neue Testfälle nötig waren.
Das Ergebnis war eine spürbare Entlastung. Je nach System wurden zwischen 50 und 60 Prozent der alten End-to-End-Tests gestrichen, weil die Abdeckung über Risiken zeigte, dass man sie schlicht nicht brauchte.
Warum End-to-End-Tests nicht die Standardantwort sind
End-to-End-Tests sind teuer in der Herstellung, teuer in der Wartung und teuer im Feedback. Bevor du einen schreibst, lohnt die Frage: Brauche ich das wirklich auf diesem Level?
Testet ein End-to-End-Test am Ende nur eine Kleinigkeit, gehört er zwei Ebenen tiefer. Setzt du den Test eine oder zwei Stufen niedriger an, bekommst du dein Feedback deutlich schneller und sparst Wartungsaufwand.
Bei Bison läuft die Automatisierung bereits dicht. Mit jedem Build laufen alle Unit- und Modultests, zweimal täglich folgen Komplett-Tests inklusive End-to-End-Tests. Damit verschiebt sich die eigentliche Arbeit auf die Frage nach dem richtigen Testlevel, nicht auf das Ob der Automatisierung.
Risikobewertung ist ein lebendiger Prozess, kein Gesetz
Ein Risikokatalog ist nie fertig. Die Bewertungen ändern sich mit dem Feedback, das aus der Praxis zurückkommt.
Diese Rückkopplung kommt aus mehreren Quellen: aus Requirements Engineers, aus dem Kunden und aus Bugs. Bei Bison wurde anfangs zu jedem Bug ein verletztes Risiko notiert, zunächst in Confluence-Katalogen, später direkt in Jira, damit die Verlinkung trägt. Daraus zeigte sich eine Korrelation: hoher Risikoindex, höheres Bug-Level.
Auch neue Anforderungen lösen eine Neubewertung aus. Kommt eine Idee vom Kunden, prüfst du, ob du dir ein neues Risiko einhandelst oder ein bestehendes verletzt, und gehst die Bewertung noch einmal durch.
Über drei Jahre lieferte das ein klares Bild. Blocker- und High-Bugs, also die Fehler, die dem Kunden wehtun, zeigen eine deutlich fallende Tendenz.
Wie man sich bei unterschiedlichen Einschätzungen einigt
Wenn der eine ein großes Risiko sieht und der andere keins, wird diskutiert, nicht abgestimmt. Die Argumente werden gegenseitig gehört, dann sucht man einen Consent.
Meist geht das zügig und sachlich. Jemand sagt am Ende, er könne damit leben, dass die anderen es so einschätzen. Erst ein echtes Veto zwingt zu längerer Auseinandersetzung. Reibung entsteht vor allem bei der Auffindbarkeit, also wie schnell ein Fehler sichtbar wird, und bei der Komplexität, wo sich die Gelehrten streiten.
Der größte Nebeneffekt ist Bewusstsein für Qualität
Risikobasiertes Testen wirkt über das Testteam hinaus. Es schafft ein Bewusstsein dafür, an welchen Stellen genau hingeschaut werden muss, und das zieht sich durch die ganze Kette.
Es ist nicht nur der Entwickler, der sieht, dass einer Story drei Risiken zugeordnet sind und der dann besonders aufmerksam testet. Es geht durch die ganze Kette, bis hin zum Requirements Engineer, der mit dem Kunden spricht.
Uwe Paesch
Konkret heißt das: Der Requirements Engineer kann dem Kunden sagen, dass eine bestimmte Umsetzung die Preisfindung kaputt macht. Entwickler verstehen besser, wie komplex eine Funktion beim Kunden wirklich ist, statt nur die eigene Story in der eigenen Bubble abzuarbeiten. Aus der Risikodiskussion werden Aha-Momente über das, was draußen passiert.
Wo risikobasiertes Testen als Nächstes hingeht
Die Ausbreitung im Unternehmen braucht Zeit. Bei Bison begann das Vorgehen in den ERP-Teams, die durch den Altbestand getrieben waren, dann kamen weitere Teams sukzessive dazu. Bis das flächendeckend greift, dauert es.
Der Weg dorthin lief nicht reibungslos. 2022 wurde das Ziel ausgegeben, risikobasiertes Testen in der gesamten Gruppe zu leben, was zu hoch gegriffen war. 2023 wurde es gesetzt und mit einem Kurs begleitet, der Vorgehen, Zweck und Methode vermittelt.
Der nächste Meilenstein ist die flächendeckende Einführung, gefolgt von mehr Automatisierung. Nicht nur Tests, die automatisch laufen, sondern Tests, die aus Use Cases und Risikobeschreibungen generiert oder als Vorschlag erzeugt werden. Genau hier wird in den kommenden Jahren KI-Unterstützung erwartet.
