Kein Projekt hat genug Zeit, um alles gleich gründlich zu testen. Die Frage ist also nicht, ob priorisiert wird, sondern wie: nach Bauchgefühl und Gewohnheit – oder nachvollziehbar nach Risiko. Risikobasiertes Testen sorgt dafür, dass die knappe Testzeit dort eingesetzt wird, wo ein Fehler den größten Schaden anrichten würde. Dieser Artikel zeigt, wie die Methode funktioniert und wie Sie sie in vier Schritten in Ihr Projekt bringen.
Risikobasiertes Testen ist ein Vorgehen, bei dem Umfang, Tiefe und Reihenfolge der Tests anhand von Risiken festgelegt werden. Ein Risiko ergibt sich aus zwei Faktoren: der Eintrittswahrscheinlichkeit eines Fehlers und dem Schadensausmaß, wenn er im Betrieb auftritt. Funktionen mit hohem Risiko werden früher, intensiver und mit stärkeren Testverfahren geprüft; Funktionen mit geringem Risiko bekommen weniger Aufwand.
Der Ansatz ist kein Sonderweg, sondern fester Bestandteil anerkannter Testgrundlagen: Der ISTQB-Lehrplan beschreibt risikobasiertes Testen als zentrale Strategie, und auch die Normenreihe ISO/IEC/IEEE 29119 stellt das Risiko in den Mittelpunkt der Testplanung. In der Praxis wird es trotzdem oft nur halb umgesetzt – es gibt eine Risikoliste im Testkonzept, aber sie hat keinen Einfluss darauf, was tatsächlich getestet wird.
Für das Testen sind vor allem Produktrisiken relevant: die Gefahr, dass die Software im Betrieb nicht das tut, was sie soll. Beispiele sind falsche Berechnungen, Datenverlust, Sicherheitslücken, schlechte Antwortzeiten unter Last oder eine Oberfläche, die Anwender nicht verstehen.
Projektrisiken betreffen dagegen die Durchführung: verspätete Lieferungen, fehlende Testumgebungen, knappe Personalkapazität oder unklare Anforderungen. Sie bestimmen nicht, was getestet wird, aber sehr wohl, ob der geplante Test überhaupt stattfinden kann. Wie Sie solche Risiken im Projekt steuern, beschreibt unser Artikel Risikomanagement in IT-Projekten.
Am Anfang steht eine Sammlung möglicher Produktrisiken. Sie entsteht am besten gemeinsam: Fachbereich, Entwicklung, Betrieb und Test sehen jeweils andere Gefahren. Bewährte Quellen sind die Anforderungen und Geschäftsprozesse, Fehlerhistorie und Störungsmeldungen früherer Releases, Architektur und Schnittstellen sowie gesetzliche oder vertragliche Vorgaben. Ein kurzer Workshop mit gezielten Fragen – „Was darf auf keinen Fall schiefgehen?“, „Wo hatten wir zuletzt Probleme?“ – bringt meist schnell eine brauchbare Liste.
Jedes Risiko wird nach Eintrittswahrscheinlichkeit und Schadensausmaß eingestuft, etwa auf einer einfachen Skala von niedrig über mittel bis hoch. Die Wahrscheinlichkeit schätzt vor allem das technische Team ein: Wie komplex ist der Code, wie neu die Technologie, wie viele Änderungen gab es, wie fehleranfällig war der Bereich bisher? Das Schadensausmaß bewertet vor allem der Fachbereich: Wie viele Anwender sind betroffen, entstehen finanzielle oder rechtliche Folgen, leidet das Vertrauen der Kunden?
Trägt man beide Werte in eine Risikomatrix ein, werden die Prioritäten sichtbar. Wichtig ist, dass die Bewertung von mehreren Personen getragen wird. Eine Matrix, die eine einzelne Person allein ausfüllt, spiegelt eher deren Blickwinkel als das tatsächliche Risiko.
Erst in diesem Schritt wird aus der Bewertung eine Teststrategie. Das Risiko beeinflusst mehrere Stellschrauben:
Eine Risikobewertung ist eine Momentaufnahme. Während des Projekts ändern sich Anforderungen, neue Fehlerhäufungen tauchen auf, und manches befürchtete Problem erweist sich als harmlos. Deshalb gehört die Risikoliste regelmäßig auf den Prüfstand – in klassischen Projekten an festen Meilensteinen, in Scrum zum Beispiel im Refinement oder vor einem Release. Fehlerstatistiken aus dem laufenden Test sind dabei ein wertvoller Hinweis: Wo sich Fehler häufen, ist die Wahrscheinlichkeit offenbar höher als angenommen.
Der größte Nutzen zeigt sich oft am Ende. Statt „82 von 100 Testfällen bestanden“ berichtet das Testteam, welche Risiken ausreichend abgesichert sind und welche nicht. Diese Aussage können Projektleitung und Fachbereich direkt für ihre Freigabeentscheidung nutzen: Sie sehen, welches Restrisiko sie mit einem Go-live eingehen. Ein Release mit offenen Fehlern in einer Randfunktion kann vertretbar sein; ein ungetesteter Kernprozess ist es in der Regel nicht.
Damit das funktioniert, sollten die Endekriterien im Testkonzept ebenfalls risikobasiert formuliert sein, etwa: Alle Testfälle zu hohen Risiken sind ausgeführt, und es gibt dort keine offenen Fehler der höchsten Fehlerklasse.
Auch in Scrum ist risikobasiertes Testen sinnvoll, nur in kleinerem Takt. Im Refinement lässt sich bei jeder User Story kurz fragen, was schiefgehen kann und wie schlimm das wäre. Das Ergebnis fließt in die Akzeptanzkriterien, die Schätzung und die Definition of Done ein. Für das Gesamtprodukt bleibt eine schlanke, gemeinsam gepflegte Risikoliste sinnvoll, die vor Releases geprüft wird. Wie Tests insgesamt in den Sprint gehören, beschreibt unser Artikel Agiles Testen in Scrum-Teams.
Risikobasiertes Testen macht Testprioritäten nachvollziehbar: Risiken gemeinsam identifizieren, nach Wahrscheinlichkeit und Schadensausmaß bewerten, Testtiefe und Reihenfolge daraus ableiten und die Bewertung laufend aktualisieren. Das Ergebnis ist keine zusätzliche Bürokratie, sondern eine bessere Grundlage für jede Entscheidung im Test – bis zur Freigabe des Releases. Warum eine strukturierte Qualitätssicherung insgesamt über den Projekterfolg entscheidet, lesen Sie in Warum Qualitätssicherung über den Projekterfolg entscheidet.
Risikomanagement betrachtet alle Risiken eines Projekts, etwa Termine, Budget oder Personal. Risikobasiertes Testen konzentriert sich auf Produktrisiken, also mögliche Fehler der Software, und nutzt ihre Bewertung, um Umfang, Tiefe und Reihenfolge der Tests festzulegen. Beide ergänzen sich: Projektrisiken beeinflussen, ob der geplante Test stattfinden kann.
Am besten ein gemischtes Team. Fachbereich oder Product Owner schätzen das Schadensausmaß ein, Entwicklung und Architektur die Eintrittswahrscheinlichkeit. Das Testmanagement moderiert die Bewertung und leitet daraus das Testvorgehen ab.
Ja. Schon eine kurze Liste der wichtigsten Risiken mit einer einfachen Einstufung in hoch, mittel und niedrig hilft, die verfügbare Testzeit sinnvoll zu verteilen. Der Aufwand dafür liegt bei kleinen Projekten oft bei einem einzigen kurzen Workshop.
30 Minuten Erstgespräch — kostenlos und unverbindlich. Wir schauen gemeinsam auf Ihr Projekt und zeigen, wo risikobasiertes Testen Ihre Testzeit wirksamer macht.
Jetzt Erstgespräch vereinbarenMehr zu unserer Leistung: Software-Qualitätssicherung in Hamburg →
Passend dazu: IT-Projektmanagement in Hamburg →