Risikobasiertes Testen bedeutet, Testfälle anhand ihres Risikowertes zu priorisieren, damit bei Zeitdruck die wichtigsten Tests zuerst ausgeführt werden. Ein mehrdimensionaler Ansatz bewertet dafür fünf Ebenen getrennt: fachliche Logik, Testhistorie, Releaseumfang, Testerzuweisung und Codeänderungen. Die Einzelwerte je Ebene werden zu einem aggregierten Risikoscore zusammengefasst.
Das Wichtigste in Kürze
- Risikobasiertes Testen wird in vielen Projekten zwar intuitiv praktiziert, aber ohne strukturierte Risikometrik bleibt die Entscheidung, welche Testfälle ins Release kommen, ein reines Bauchgefühl.
- Ein Ebenenmodell mit fünf Perspektiven, darunter fachliche Logik, Testhistorie, Releaseumfang, Testerzuweisung und Codeänderungen, liefert einen aggregierten Risikoscore pro Testfall statt eines einzelnen groben Hoch-mittel-niedrig-Werts.
- Fibonacci-Zahlen als Bewertungsskala sorgen dafür, dass ein einzelner hoher Risikowert den Gesamtscore dominant beeinflusst und niedrige Werte auf anderen Ebenen nicht künstlich ausgleichen.
- Testfallkomplexität, gemessen an Vorbedingungen und Anzahl der Schritte im Verhältnis zu anderen Testfällen im Projekt, fließt direkt in die Eintrittswahrscheinlichkeit eines Fehlers ein.
- Mit einem Risiko-Cut-Off lässt sich vor dem Testlauf festlegen, welche Testfälle überhaupt berücksichtigt werden, sodass bei Zeitdruck die hinten wegfallenden Fälle nachweislich das geringste Risiko tragen.
Was multidimensionales risikobasiertes Testen bedeutet
Multidimensionales risikobasiertes Testen bewertet das Risiko eines Testfalls aus mehreren Perspektiven gleichzeitig, statt es auf einen einzigen Wert zu reduzieren. Die klassische Einteilung in hoch, mittel und gering bleibt eindimensional. Sie sagt, dass ein Risiko hoch ist, aber nicht, aus welcher Richtung es kommt.
Richard Hönig hat bei MGM ein Ebenenmodell für die Risikoanalyse entwickelt, das diese Verkürzung aufbricht. Der Grundgedanke: Eine komplexe Welt lässt sich schlecht mit einer einzigen Skala abbilden. Wer Risiken nur global einschätzt, verliert die Information darüber, warum ein Testfall kritisch ist.
Stattdessen betrachtet das Modell jeden Testfall durch mehrere getrennte Linsen und führt die Ergebnisse erst am Ende zusammen. Was sagt die Fachlichkeit? Was sagt die Testhistorie? Was ist für das aktuelle Release wichtig? Aus diesen einzelnen Bewertungen entsteht ein aggregierter Risikoscore pro Testfall.
Warum reine Bauchgefühl-Entscheidungen das eigentliche Problem sind
Risikobasiertes Testen passiert in vielen Projekten, ohne dass es so genannt wird. Teams entscheiden intuitiv, welche Testfälle für ein Release relevant sind und welche nicht. Diese Entscheidung treffen sie meist aus dem Bauch heraus, ohne Metrik und ohne Skala.
Genau hier liegt die Schwachstelle. Das Bauchgefühl erfahrener Stakeholder ist wertvoll, aber es ist nicht nachvollziehbar und nicht reproduzierbar. Sobald das Projekt wächst oder Personen wechseln, fehlt eine gemeinsame Grundlage für die Priorisierung.
Der Ausweg ist nicht, das Bauchgefühl zu ersetzen, sondern es datengestützt zu untermauern. Am Anfang eines Projekts, wenn kaum Daten vorliegen, bleibt die Erfahrung von Entwicklern, Architekten und Testern die beste Quelle. Mit jedem Testlauf kommen Daten hinzu, die diese Einschätzung präzisieren.
Die fünf Ebenen der Risikoanalyse
Das Modell von Richard arbeitet mit fünf Perspektiven, die jeden Testfall getrennt bewerten. Jede Ebene liefert einen eigenen Wert, der später in den Gesamtscore einfließt.
| Ebene | Was sie bewertet |
|---|---|
| Fachliche Logik | Eintrittswahrscheinlichkeit und potenzielle Auswirkung eines Fehlers, inklusive Testfallkomplexität |
| Testhistorie | Fehlschlagsrate vergangener Ausführungen, entstandene Fehler-Tickets und deren Priorität |
| Releaseumfang | Verknüpfung mit Anforderungstickets, die im aktuellen Release eine Rolle spielen |
| Testerzuweisung | Know-how und zeitliche Verfügbarkeit der Person, die den Testfall ausführt |
| Codeänderung | Mit welchen Codebereichen ein Testfall verknüpft ist und was sich dort geändert hat |
Die fachliche Logik greift auf das zurück, was risikobasiertes Testen seit jeher kennt: Eintrittswahrscheinlichkeit mal Auswirkung. Neu ist, dass die Testfallkomplexität als messbarer Faktor in die Eintrittswahrscheinlichkeit einfließt.
Die Testerzuweisung ist eine Ebene, die viele Modelle übersehen. Wer in mehreren Projekten gleichzeitig steckt oder ein Themengebiet kaum kennt, bringt ein höheres Risiko mit. Das hat nichts mit dem Testfall selbst zu tun, beeinflusst aber das Ergebnis.
Die Codeänderung schließt eine typische Lücke. Ein Tester liest eine Anforderung und hält klar, was zu prüfen ist. Trotzdem treten Fehler an Stellen auf, die niemand auf dem Schirm hatte: ein Refactoring im Hintergrund, eine aktualisierte Library. Solche Änderungen wirken auf das Risiko, ohne in der Anforderung sichtbar zu sein.
Wie die Komplexität eines Testfalls ins Gewicht fällt
Die Komplexität eines Testfalls erhöht seine Fehlerwahrscheinlichkeit, weil mehr Schritte mehr Stellen bedeuten, an denen etwas schiefgehen kann. Das Modell schaut sich an, wie umfangreich die Vorbedingungen sind und wie viele Testschritte ein Testfall enthält.
Entscheidend ist die Einordnung im Verhältnis zu den anderen Testfällen im Projekt. Ein Testfall mit 60 Schritten ist nicht absolut komplex, sondern komplex im Vergleich zu den kleinen Testfällen daneben. Bestehen alle Testfälle aus solchen Kloppern, verliert der Wert seine Aussagekraft.
Diese relative Bewertung verhindert, dass ein einzelner mächtiger Testfall automatisch alles dominiert. Der Business Case, der von vorne bis hinten durchläuft, tausend Anforderungen berührt und oft instabil war, fällt nicht allein deshalb durchs Raster, weil er groß ist. Er wird in Relation gesetzt.
Warum die Fibonacci-Reihe die richtige Skala liefert
Das Modell bewertet Risiken mit Fibonacci-Zahlen, weil sie von alleine exponentiell wachsen und so hohe Risiken im Gesamtscore stärker durchschlagen lassen. Die grobe Dreiteilung in gering, mittel und hoch bot zu wenig Nuance und zu wenig Flexibilität.
Die Aufteilung folgt der Stellenzahl. Die einstelligen Fibonacci-Zahlen von 1 bis 8, also 1, 2, 3, 5 und 8, bewerten geringe Risiken. Zweistellige Werte stehen für mittleres Risiko, dreistellige für hohes.
Der Effekt zeigt sich beim Aggregieren. Liegt ein Testfall auf einer Ebene bei einem dreistelligen Wert und auf den anderen Ebenen bei 5 oder 8, gleicht der hohe Wert die niedrigen nicht einfach aus. Der Mittelwert bleibt hoch, weil die exponentielle Spreizung das hohe Risiko inhärent durchträgt.
Wenn ich da einen Wert von zum Beispiel 610 habe, gleicht er natürlich aus, wenn auf anderen Ebenen eher ein niedriges Risiko von 5 oder 8 vorherrscht, dass man trotzdem am Ende eine sehr hohe Zahl hat.
Richard Hönig
Risikoanalyse darf keinen Mehraufwand erzeugen
Eine Risikoanalyse trägt nur dann, wenn sie auf Daten zurückgreift, die ohnehin schon vorhanden sind. Sobald sie zusätzliche Dokumentation verlangt, kippt der Mehrwert in Mehrbelastung.
Im Testmanagement-Tool von MGM laufen die nötigen Informationen zusammen: verlinkte Anforderungen, verknüpfte Fehler-Tickets, vorangegangene Testläufe. Für Projekte, die ihre Dokumentation halbwegs im Griff haben, ist das Verlinken Standard und kostet die Tester keine Extrazeit. Das Backend berechnet die Risikowerte automatisch aus diesen Daten.
Kein System trifft jede Einschätzung richtig. Deshalb lässt sich die automatische Berechnung pro Testfall überschreiben. Wer das Risiko anders sieht als der Algorithmus, gibt den Wert oder einzelne Parameter selbst vor.
Wie der Risikoscore die Testpriorisierung steuert
Der aggregierte Risikoscore wird zum Steuerungswerkzeug für den Testlauf, nicht nur zur hübschen Übersicht. Manager sehen auf einen Blick die Risikoverteilung im Projekt. Für Tester ist der praktische Nutzen größer.
Beim Zusammenstellen eines Testlaufs lässt sich ein Cut-off setzen: Nur Testfälle ab einem bestimmten Risikowert kommen rein, der Rest bleibt zunächst außen vor. Innerhalb des Laufs werden die Testfälle nach Risiko sortiert, sodass die kritischsten ganz oben stehen.
Das zahlt sich aus, wenn die Zeit knapp wird. Wer von oben nach unten testet, hat immer die höchsten Risiken zuerst abgedeckt. Fällt am Ende etwas hinten runter, sind es die Testfälle mit dem geringsten Risiko: ärgerlich, aber verkraftbar.
Branchenkontext und Gewichtung als nächster Schritt
Verschiedene Projekte und Branchen gewichten die Risiko-Ebenen unterschiedlich, und ein starres Modell wird dem nicht gerecht. Ein Team hält die Komplexität für ausschlaggebend, ein anderes die Fachlichkeit. Eine frei einstellbare Gewichtung der Ebenen steht bei MGM noch im Backlog.
Auch der zeitliche Kontext kann das Risiko verschieben. In der Kfz-Versicherung müssen Verträge zum Jahresende neu abgeschlossen werden, der Run auf die Formulare beginnt. Ein Fehler im selben Bereich wiegt im Januar leichter als im Herbst. Solche Saisonalität wandert mit ins Modell.
Weitere Ebenen wie Security sind absehbar. Der eigentliche Reifeschritt geht aber weiter: Testmanagern das Framework an die Hand zu geben, mit dem sie eigene Ebenen definieren. Sie wissen am besten, wo ihre Risiken liegen, und ein Toolanbieter kann das nicht für jedes Projekt vordenken.
