Risikobasiertes Testen: Den Blick auf die kritschen Bereiche lenken

Vor jedem Livegang eines Release steht im besten Fall ein umfassender Regressionstest an. Dieser stellt sicher, dass bisherige Funktionalität weiterhin existiert und dort keine Fehler entstanden sind durch die neuen Inkremente. Die Tester ziehen also los, arbeiten sämtliche Testfälle ab, die Testabdeckung ist hoch, die Reports grün, 100 Testfälle ausgeführt, Freigabe erteilt. Und doch tritt kurze Zeit später im produktiven Betrieb ein kritischer Fehler auf. Hier müssen folgende Fragen gestellt werden:

• Was genau wurde getestet?
• Welche kritischen Prozesse und Fälle wurden abgedeckt?
• Decken die Testfälle den entstandenen Fehlerfall ab?
• Wurde das "richtige" getestet?

Hier hilft ein kontinuierlicher Blick auf den risikobasierten Ansatz. Haben sich meine kritischen Pfade geändert? Werden diese abgedeckt? Testen wir die risikoreichsten Pfade?

In vielen Projekten herrscht der Irrglaube: Mehr Testfälle = bessere Qualität oder je mehr Testfälle, desto besser das Gefühl. Viele Testteams leiden vor Allem unter einem Problem: Zeitmangel. Oft wird am Testing gespart und die Zeit für den Livegang als wichtigstes Kriterium herangezogen. Umso wichtiger ist es hier einen risikobasierten Ansatz zu wählen der Testfälle und Komponenten clustert und nach Risiko und Schadenausmaß sortiert. Wenn die Zeit knapp wird weiß das Team in welcher Reihenfolge Testfälle abgearbeitet werden müssen und worauf das Augenmerk liegt. Als Testmanager und Testteam muss man sich in Abstimmung mit den Stakeholder immer fragen:

• Was wird zuerst getestet?
• Wie viele Testfälle existieren für die kritischen Bereiche?
• Sind die Testfälle im geplanten Zeitrahmen ausführbar?
• Verlängert sich der Testzeitraum wenn kritische Fehler aufgedeckt werden?
• Decken die existierenden Testfälle noch alle kritischen Bereiche ab oder haben sich Änderungen ergeben die neu bewertet werden müssen?

• Wird das Auswirkungen auf das Kerngeschäft haben?
• Wie viel Geld kostet der Fehler im Falle von Regressansprüchen und Imageschäden?
• Welche Geschäftsfälle und Funktionen müssen immer funktionieren?

Beim risikobasierten Testen geht es vor Allem darum die kritischen Pfade zu erkennen, zu bewerten und entsprechend abzudecken. Dazu muss man sich als Testmanager erstmal einen Überblick über die Umgebung, die Geschäftsfälle und die entstehenden Risiken verschaffen. Dazu kann man sich mit Stakeholder austauschen, mit den Entwicklungsteams und die Erfahrung des Test-Teams einholen. Folgende Fragen kann man dabei berücksichtigen:

• Welche Geschäftsfälle müssen immer funktionieren?
• Welche kritischen Bereiche habe ich in meinem System?
• Welchen Schaden, auch finanziell, kann ein schwerwiegender Fehler im produktiven System anrichten?
• Haben sich meine erfassten Risiken im vergleich zum letzten Release verändert? 
• In welcher Reihenfolge arbeite ich meine Testfälle ab? Stichwort Priorität und Kritikalität vs. Zeitachse
• Steht das gesamte Testteam bereit oder müssen abstriche im Testumfang gemacht werden?
• Welche Inhalte hat das Release und welche Komponenten/Pfade sind betroffen?

Speziell in agilen Projekten, die in regelmäßigen Abständen Software liefern ist ein ständiger Blick auf Risiken und Testfälle nötig. Auch hier kann der kontinuierliche Verbesserungsprozess (KVP) gelebt werden.

Um einen risikobasierten Ansatz zu etablieren reicht besonders eins: Den ersten Schritt machen und anfangen. Werden Fehler weiterhin auftreten? Bestimmt! Aber im Sinne des kontinuierlichen Verbesserungsprozesses justiert man mit jedem Release nach. Wichtig ist für einen Ansatz eine breite Palette an Blickwinkeln, Informationen und Erfahrungen einzusammeln. Folgende Ideen gibt es dazu:

• gemeinsamer Workshop mit Entwicklung, Product Management und QA
• Übersicht über die Releaseinhalte
• Verwendung von Stichworten und Komponenten an Tickets, falls Tools wir bspw. Jira zum Einsatz kommen
• Auswertungen erheben um eine Übersicht zu erlangen, welche Komponenten und Pfade in der Vergangenheit Fehler produziert haben
• Eine Matrix erstellen welche Risiken existieren, wie hoch das Schadenausmaß wäre und welche Maßnahmen getroffen werden um diese zu mindern