Glossar · Testgrundlagen
Risikobasiertes Testen
Englisch: Risk-based testing
Auch genannt: risikobasierter Test, risikoorientiertes Testen, RBT
Definition
Ein Ansatz, der den Testaufwand nach Risiko (Wahrscheinlichkeit mal Auswirkung) priorisiert, damit die riskantesten Bereiche zuerst und am gründlichsten getestet werden.
Risikobasiertes Testen akzeptiert, dass Sie nie alles testen können, und entscheidet anhand des Risikos, wo Sie Ihre Zeit investieren. Jedes Feature oder jeder Bereich wird nach der Wahrscheinlichkeit eines Fehlers (Komplexität, Umfang der Änderungen, frühere Fehler, neue Technologie) und den Auswirkungen im Fehlerfall (Geld, Sicherheit, Daten, rechtliche Risiken, Zahl der betroffenen Nutzer) bewertet. Bereiche mit hohem Risiko werden früher, gründlicher und vielfältiger getestet; Bereiche mit geringem Risiko erhalten leichtere Prüfungen.
Beispiel
Ein Release betrifft vier Bereiche. Bewerten Sie jeden mit 1 bis 5:
| Bereich | Wahrscheinlichkeit | Auswirkung | Risiko (W x A) | Testtiefe |
|---|---|---|---|---|
| Migration des Zahlungsanbieters | 5 | 5 | 25 | Vollständig funktional, negativ, Integration, Performance, explorativ |
| Neue Steuerregeln für eine Region | 4 | 4 | 16 | Grenzwert- und Entscheidungstabellentests, Regression der Summen |
| Neu gestaltete Profilseite | 3 | 2 | 6 | Hauptabläufe plus eine visuelle Prüfung |
| Aktualisierter Footer-Link | 1 | 1 | 1 | Kurze Prüfung |
Wird die Deadline um zwei Tage verkürzt, wissen Sie bereits, worauf Sie verzichten: auf Tiefe bei den Zeilen mit geringem Risiko, nicht bei der Zahlungsmigration.
Warum es wichtig ist
Jeder Testplan geht Kompromisse ein. Risikobasiertes Testen macht sie explizit und abgestimmt. Es liefert außerdem eine klare Art, den Status zu berichten: „Alle Hochrisikobereiche getestet, zwei mittlere Risiken teilweise getestet, diese bekannten Lücken bleiben“ ist für eine Release-Entscheidung weit nützlicher als „83 % der Testfälle ausgeführt“.
Häufige Fehler
- Allein bewerten. Product Owner kennen die Auswirkungen, Entwickler die Wahrscheinlichkeit. Bewerten Sie Risiken gemeinsam.
- Nur einmal bewerten. Risiken ändern sich, wenn Code eingespielt wird und Bugs auftauchen. Ein Modul, das immer wieder Fehler produziert, sollte nach oben rücken.
- Bereiche mit geringem Risiko komplett ignorieren. Geringeres Risiko bedeutet leichteres Testen, nicht gar keines. Automatisierte Regressionstests decken diese Basis meist ab.
- Es mit dem Schweregrad von Bugs verwechseln. Der Schweregrad bewertet einen bereits gefundenen Fehler. Risiko ist eine Schätzung vor dem Testen, mit der Sie entscheiden, wo Sie suchen.