Szenariobasiertes Testen erklärt am Tatort Kaffeeküche

Eine solide Testbasis schaffen mit Szenario-basiertem Testdesign

Im Szenario-basierten Testdesign betrachten Sie oder Ihre Testexperten Ihren Anwendungsfall aus verschiedenen Blickwinkeln. Das hilft bei der Testfallerstellung: Durch Denken in Szenarien werden Testfälle vielseitig. Außerdem decken Sie das gesamte Spektrum des zu erwartenden Systemverhaltens ab.  

Im Szenario-basierten Testdesign werden für einen Anwendungsfall mögliche Varianten im Ablauf und Verhalten ermittelt. Dafür schauen Sie sich die zu verarbeitenden und durchaus unterschiedlichen Eingangsdaten (Input) an. Diese Varianten können Sie zusätzlich nach folgenden Szenario-Typen gruppieren: 

• Hauptszenario
• Alternativszenario
• Ausnahmeszenario
• Negativszenario
• Missbrauchsszenario

The grouping presented is based on Klaus Pohl(*) and has proven itself several times in our practice. We describe what is meant by which scenario and describe each use case using an example from everyday office life. 

Tatort Kaffeeküche

Hauptszenario

Das Hauptszenario ist der Standardfall. Dieser repräsentiert die gewünschte Verwendung eines Systems und beschreibt die favorisierte Abfolge an Interaktionen mit dem System. Es handelt sich um ein positives Szenario (Happy Case).

Unser Beispiel: Eine Tasse Kaffee (schwarz) am Vollautomaten auswählen. 

Alternativszenario

Das Alternativszenario erfüllt dasselbe Anwendungsziel wie das Hauptszenario. Es beschreibt jedoch eine alternative Abfolge an Interaktionen mit dem System. Hierbei handelt es sich ebenfalls um ein positives Szenario (Happy Case). 

Unser Beispiel: Eine Tasse Milchkaffee (Latte) am Vollautomaten auswählen. 

Ausnahmeszenario

Das Ausnahmeszenario beschreibt eine Abfolge von Interaktionen mit dem System, die bei Abweichungen vom Standard- oder vom Alternativszenario ausgeführt werden sollen. Das Ausnahmeszenario kann man mit der Ausnahmebehandlung (Exception Handling) in der Programmierung gleichsetzen. Auch hier handelt es sich um ein positives Szenario (Happy Case), welches dasselbe Anwendungsziel wie das Hauptszenario erfüllt.

Unser Beispiel: Das übergeordnete Ziel in unserem Fall ist, erfolgreich ein Heißgetränk (nach Wahl) am Kaffeeautomaten zu beziehen. Nicht immer ist das Ziel auf direktem Weg zu erreichen. In unserem Beispiel steht die Tropfschale (Auffangbecken) des Kaffeeautomaten kurz vor dem Überlaufen. Ein weiteres Heißgetränk kann erst bezogen werden, wenn die Schale zuvor geleert wurde.

Negativszenario

Das Negativszenario erfüllt nicht das Anwendungsziel von den bisher genannten positiven Szenarien (Haupt-, Alternativ- und Ausnahmeszenario). Im Negativszenario wird bewusst mit ungültigen Testdaten auf denselben Interaktionsabfolgen der positiven Szenarien gearbeitet. Hierdurch wird geprüft, ob das System diese korrekt abweist.

Unser Beispiel: Kaffeebohnen werden nicht korrekt nachgefüllt. Der Automaten gibt keinen Kaffee aus.

Missbrauchsszenario

Das Missbrauchsszenario erfüllt ebenfalls nicht das Anwendungsziel der positiven Szenarien. Es beschreibt eine unerwünschte Interaktionsabfolge, um auszuloten, wie robust das System ist und ob es Möglichkeiten gibt, das System auszutricksen.

Unser Beispiel: Auf mehr als einen oder alle Knöpfe für die Getränkeauswahl gleichzeitig drücken. Der Kaffeeautomat ignoriert diese Mehrfachauswahl einfach.

---

Anhand der einzelnen Szenarien lassen sich recht einfach diverse Fragen beantworten:

• Ob und wie funktioniert das System grundsätzlich?
• Wie flexibel verhält sich das System?
• Ist das System benutzerfreundlich?
• Was kann alles schief gehen und wie geht das System damit um?
• Lässt sich das System austricksen?

Mit Szenario-basiertem Testdesign und der Frageliste lassen sich zügig vielseitige Testideen zusammentragen. 

In einem nächsten Schritt empfiehlt es sich, die gesammelten Szenarien gemeinsam mit dem Auftraggeber und / oder Businessanalysten durchzugehen und abzuklären, welche davon für die Implementierung relevant sind. Die Szenarien, die es in die Auswahl geschafft haben, werden in Form von Testfällen ausspezifiziert.

Sobald Sie Ihre Testideen zusammengestellt haben, können Sie in einem weiteren Schritt innerhalb Ihres Teams festlegen, wer welche Szenarien vorrangig testet. So können zum Beispiel einige der Szenarien durch die Entwickler, andere durch die Test-Spezialisten im Projekt geprüft werden.

Der Beitrag ist in Zusammenarbeit mit Maike Uhlig entstanden.

---

(*)Klaus Pohl: „Requirements Engineering – Grundlagen, Prinzipien, Techniken“ dpunkt.verlag, ISBN 978-3-89864-342-9, 2007

• Weitere Blogs über Werkzeuge aus unserem Methodenkoffer gibt es hier. 
• Nachtrag April 2020: Mittlerweile haben wir unsere Szenariokarten hier online gestellt.

Über den Autor