Risk Storming
Wie ihr vielleicht schon in unserem QualityHeroes Podcast mitbekommen habt, haben wir in unserem Testing Team eine 2-wöchige „Let´s Test Session“ eingeführt. Hier treffen wir uns auf freiwilliger Basis, um bekannte, aber auch weniger bekannte Methoden rund um das Testen vorzustellen und praktisch auszuprobieren. Vor kurzem haben wir uns mit dem Risk Storming beschäftigt.
Wozu?
Mit dem Risk Storming kann man kollaborativ und teamübergreifend Produktrisiken identifizieren und minimieren. Am besten wird das komplette Produktteam eingebunden und trägt so “hands-on” dazu bei, unterschiedliche Blickwinkel auf das Produkt und dessen Risiken zu betrachten.
Was man dafür braucht:
- einen Spielplan
- ein Kartenset “TestSphere”
- Stift und Post-its
- One-Page-Teststrategie-Vordruck
Mit Hilfe der “TestSphere”-Karten und der von uns empfohlenen “One-Page-Teststrategie” wird allen Beteiligten anschaulich und spielerisch klar, was man wie und wann testen kann. Das Kartenset enthält außerdem auch Karten zu den Themen Heuristik und Technik, mit deren Hilfe immer wieder neue (Test-)Ideen entstehen. So wird das Ganze auch für erfahrene und langjährige Kolleg:innen immer wieder spannend.
Was und wie haben wir getestet:
Eine fiktive Webapplikation zum Verkauf gebrauchter Waren, die in Deutsch und Englisch verfügbar ist, diente als Testobjekt. Wir haben die Vorgehensweise etwas abgewandelt und eine Lean Coffee Version des Risk Stormings umgesetzt, einfach um die Session auf maximal eine Stunde zu beschränken und um das Ganze auch online durchführen zu können.
Für unsere Online-Session haben wir folgendes benötigt:
- Risk Storming Board online (wir verwendeten Mural)
- Auswahl der Produktrisiken-Karten
- Online-Meeting-Tool
Wir haben uns auf die Produktrisiken Sicherheit, Funktionalität und Daten geeinigt und unsere fiktive Applikation auf diese drei Aspekte geprüft. Rasch kamen viele Ideen aber auch Fragen auf, worauf z. B. bereits in der Entwicklung die drei Risikoaspekten beachtet werden sollten, was getestet werden muss und wo weitere Risiken und Hürden liegen.
Fragen aus dem Bereich “Usability” kamen auf wie z. B., ob das Verwenden von Bildern eines zu verkaufenden Artikels geprüft werden muss. Oder aber welche Bildformate und welche max. Dateigröße sollte die Webapplikation unterstützen? Darf jede Art von Artikel verkauft werden oder sollte es Einschränkungen geben z. B. aus rechtlichen Gründen oder hinsichtlich des Jugendschutzes? Würde nach erfolgreichem Upload jemand die angebotenen Artikel und Bilder auf der Plattform prüfen? Gibt es einen Unterschied zwischen der Desktop-Anwendung und einer Mobilanwendung? Sind die Funktionalitäten über die Mobil-App schnell genug und reicht eine Mobiledatenverbindung dafür aus?
Im Laufe der Session kamen so immer mehr Fragen auf und zeigten, dass vermeintlich einfache Themen häufig doch deutlich größer sind und auch durchaus Abhängigkeiten zu anderen Risikoaspekten haben können.
Fazit:
Innerhalb von nur einer Stunde haben wir selbst mit einer verschlankten Version eine Vielzahl an Ideen zum Testen sammeln können. Darüber hinaus haben wir sowohl Produkt- als auch Projektrisiken identifiziert, die wir in einem echten Projekt klar an die Stakeholder hätten kommunizieren können. Und mit der One-Page-Teststrategie hätte man im Projekt schnell ein leichtgewichtiges Dokument, in dem die wichtigsten Punkte zur Teststrategie des Produktes festgehalten wären.
Falls das für dich spannend klingt, stay tuned! Bald kannst du diesen Workshop mit uns zusammen bei euch im Projekt durchführen.
Erfahre mehr über Risk Storming im QualityHeroes Podcast: https://qualityminds.com/de/qualityheroes-podcast-folge-20-was-ist-ein-risk-storming-workshop-und-wie-kann-er-einem-projektteam-helfen-2/
Hast du Fragen? Schreibe uns an! testing@qualityminds.de
Über das Testing Team (Portfolio): https://qualityminds.com/de/portfolio/qa-kernkompetenzen/funktionales-testen/
0 Kommentare