Risk-Based Testing: Qualität sichern, wo es zählt
29. Apr. 2026 • Paul Kalbitzer
Vollständiges Testen ist in modernen Release-Zyklen meist unrealistisch. Wer versucht, alles gleich intensiv zu prüfen, verliert Zeit in unwichtigen Details, während kritische Fehler unentdeckt bleiben. Deshalb geht es oft nicht um mehr Tests, sondern um die richtigen Prioritäten. Genau hier setzt Risk-Based Testing (RBT) an.
Beim Risk-Based Testing werden Testressourcen gezielt dort eingesetzt, wo Fehler den größten Schaden verursachen könnten. Das Risiko ergibt sich aus zwei Faktoren: der Wahrscheinlichkeit, dass ein Fehler entsteht, und dem möglichen Schaden im Fehlerfall. Eine hohe Wahrscheinlichkeit entsteht zum Beispiel durch komplexen Code, viele Änderungen, Zeitdruck, neue Technologien oder instabile Schnittstellen. Der Schaden kann sich etwa in Umsatzverlust, Datenverlust, Sicherheitsproblemen, Reputationsschäden oder operativen Ausfällen zeigen.
Um Risiken greifbar zu machen, hilft eine einfache Matrix. Bereiche mit hoher Eintrittswahrscheinlichkeit und hohem Schaden erhalten höchste Priorität und werden besonders intensiv getestet, zum Beispiel mit manuellen Tests, Integrationstests oder Security-Prüfungen. Mittlere Risiken bekommen eine solide Standard-Abdeckung, niedrige Risiken werden nur stichprobenartig geprüft.
| Risiko-Level | Strategie | Testintensität |
|---|---|---|
| Kritisch (hoch / hoch) | Höchste Priorität | Intensive manuelle Tests, Integrationstests, Boundary Checks, Security Reviews |
| Hoch | Hohe Priorität | Vollständige funktionale Abdeckung, regelmäßige Regression |
| Mittel | Standard-Abdeckung | Fokus auf häufige User-Flows, automatisierte Kernchecks |
| Niedrig | Minimale Tests | Explorative Stichproben oder Testen bei verfügbarer Kapazität |
Ein risikobasierter Testplan entsteht meist in vier Schritten: Zuerst werden neue oder geänderte Funktionen identifiziert. Danach bewerten Product Owner, Entwicklung und QA gemeinsam Wahrscheinlichkeit und Auswirkungen, oft mit einer Skala von 1 bis 5. Daraus ergibt sich ein Risk Score. Anschließend werden Zeit und Testaufwand entsprechend verteilt. Wichtig ist außerdem ein regelmäßiger Review, denn Risiken verändern sich laufend, etwa nach Refactorings oder größeren Änderungen.
Einige wichtige Fragen an das Team zum RBT könnten wie folgt aussehen:
| Fragen zum Impact | Fragen zur Wahrscheinlichkeit |
|---|---|
| * Hängt Umsatz an dieser Funktion (z. B. Check-out)? * Sind personenbezogene Daten betroffen? * Gibt es Security- oder Compliance-Risiken? * Wie sichtbar wäre ein Fehler für Kund:innen? * Führt ein Problem zu Supportaufwand oder SLA-Verletzungen? | * Ist der Code komplex oder Legacy? * Wurde unter Zeitdruck entwickelt? * Gab es dort früher bereits viele Bugs? * Werden neue Technologien eingesetzt? * Sind mehrere Teams oder Systeme beteiligt? |
Besonders wertvoll ist RBT, weil Teams effizienter arbeiten und ihre Entscheidungen transparent begründen können. Wenn Zeit knapp wird, lässt sich klar darstellen, was getestet wurde, was bewusst verschoben wurde und welches Restrisiko bleibt. Gleichzeitig werden kritische Schwachstellen früher erkannt, was Releases sicherer macht.
Risk-Based Testing bedeutet also nicht weniger Qualität, sondern einen professionellen Umgang mit begrenzten Ressourcen. Wer nicht alles testen kann, sollte zumindest das Richtige intensiv testen. Genau darin liegt die Stärke dieses Ansatzes.