Automatisierte Webseiten-Tests innerhalb von Minuten aufgesetzt dank Leankoala.
Leankoala →

Lean Testing in der Praxis: Risk Estimation Game

Manche unserer Kunden unterstützen wir nicht nur mit unserer Monitoring und Testing-Lösung, sondern auch mit Beratung und Workshops zum Thema Qualität. Da nicht jede Organisation vor den gleichen Herausforderungen steht, haben wir für den Einsatz von Lean Testing in der Praxis das Risk Estimation Game entwickelt. Ziel war es eine einfache und spielerische Methode im Portfolio zu haben, mit der man die wichtigsten nächsten Schritte im Qualitätsmanagement bestimmen kann.

Bei der Einführung eines Qualitätsmanagements kann einiges schief gehen, zum Beispiel die falschen Dinge richtig zu testen. Aber was sind die richtigen Dinge und dringlichsten Aufgaben, die es zu erledigen gilt? In einer risiko-basierten Qualitätswelt ist diese Frage einfach zu beantworten. Es sind diejenigen, die die größten Risiken in Zaum halten. Dies ist der Grund warum der Aufbau des Qualitätsmanagement oder der Qualitätssicherung immer mit einem Risiko-Workshop beginnen sollte.

Risiko-Workshops mit Risk Estimation Game

Ziel des Risk Estimation Games (REG) ist eine saubere Risikomatrix, in der alle aktuellen potentiellen Herausforderungen positioniert sind. Solche Workshops können bereits nach einer Stunde ergiebig sein. Dabei untergliedert sich das Vorgehen in fünf Schritte und es ist wichtig, dass das teilnehmende Team aus allen relevanten Domänen zusammengestellt wird. Entwickler, Marketing, Sales, Product Owner und ähnliche Projektrollen sind essentiell für einen vollständigen Überblick.

Risk Estimation Game in fünf Schritten

  1. Risiken notieren
    Jeder Workshopteilnehmer hat eine eigene Einschätzung, was gerade in einem Projekt potentielle Gefahren birgt. Deshalb ist es wichtig, dass der erste Schritt von jedem individuell ausgeführt wird. Ziel ist es nach 15 Minuten auf Karteikarten oder Post-Its alle Risiken notiert zu haben, die einen derzeit beschäftigen. Da solche Workshops in regelmäßigen Abständen durchgeführt werden sollten, ist es nicht problematisch, wenn nicht alle Risiken in der ersten Ausgabe den Weg aufs Papier finden.
  2. Risiken vorstellen
    Nachdem alle Risiken aufgeschrieben wurden, darf jeder seine Notizen vorlesen und erklären. Wichtig dabei ist, dass noch keine Risikobewertung ausgesprochen wird. Dies geschieht erst im vierten Schritt. Wenn alle Risiken verstanden wurden, geht es weiter mit dem nächsten Schritt.
  3. Mischen
    Die von den Teilnehmern erstellten Karten müssen nun gemischt und in eine zufällige Reihenfolge gebracht werden.
  4. Karte anhängen oder umhängen
    Jetzt geht es an die Risikomatrix. Diese besteht aus zwei Achsen: auf der einen Achse wird die Eintrittswahrscheinlicheit abgetragen, auf der Zweiten die Kosten (z.B. Reparatur, Umsatzausfall etc.). Die Eintrittswahrscheinlichkeit definiert wie hoch die Chance ist, dass ein Risiko tatsächlich eintritt, Kosten beschreiben die monetären Aufwände, die enstehen, wenn ein Risiko eintritt.
    In diesem Schritt wechseln sich die Teilnehmer ab. In jedem Zug gibt es zwei Aktionen, die durchgeführt werden können. Zum einen kann man eine Karte vom Stapel nehmen und das Risiko in der Risikomatrix positionieren. Die zweite mögliche Aktion ist das Umhängen einer Karte, die sich bereits auf der Matrix befindet. Dies sollte jedes Mal geschehen, wenn man mit der Einschätzung eines Vorgängers nicht zufrieden ist. Sobald ein Risiko zwei mal umgehängt wurde, wird es aus dem “Spiel” genommen und später separat diskutiert. Die vierte Runde endet, sobald alle Karten ihren Platz auf der Matrix haben inklusive der vorher zwei mal umgehängten Karten. Die strittigen Fälle sollten im Team besprochen und gemeinsam eine möglichst realistische Einschätzung gefunden werden, mit der alle leben können. Im Zweifelsfall sollte zu Beginn eines Projektes das Risiko eher zu hoch als zu niedrig eingeschätzt werden. Auch deshalb ist eine regelmäßige Risikobewertung und Aktualisierung der Matrix wichtig, denn die meisten Probleme werden im weiteren Projektverlauf klarer und lassen sich dann besser einordnen.
  5. Square of interest: Relevante Risiken fest legen
    Der risikobasierte Ansatz ist einfach. Potentiell teure Probleme mit einer hohen Eintrittswahrscheinlichkeit werden angegangen, niedriges Risiko links wird liegen gelassen. Wann ein Risiko als relevant eingeschätzt wird, muss nun noch fest gelegt werden. Klar ist, dass sich die relevanten Risiken in der rechten oberen Ecke der Matrix befinden. Wie groß diese ist, muss das Team gemeinsam bestimmen. Dabei werden alle Tickets in diesem Quadranten kurz vorgelesen und das Team entscheidet, ob es noch relevant genug ist, um sich kurzfristig drum zu kümmern. Begonnen wird mit der Karte, die sich am nächsten am Maximum aus Wahrscheinlichkeit und Kosten befindet, anschließend wird sich abwärts und seitwärts vorgearbeitet. Sobald das Team zu einem Ticket gelangt, das nicht mehr relevant genug ist, ist der “square of interest” mit den wichtigen Risiken abgesteckt.

Mit Abschluss des Risk Estimation Game hat man eine gefüllte Risikomatrix und weiß, welche Punkte man als nächstes angehen muss, um das Produkt oder Projekt am besten abzusichern.

Wichtig ist, dass eine Risikobewertung keine einmalige Aktion ist, sondern zyklisch durchgeführt um immer eine aktuelle Perspektive auf den Stand des Produktes und die Außenwelt zu haben. Im agilen Umfeld kann sie zum Beispiel Teil der Sprint-Planung werden. So könnt ihr euch iterativ zum Lean Testing bewegen. Nicht zuletzt sind wir auch der Überzeugung, dass es aufgrund von risikobasierten Ansätzen im Qualitätsmanagement in fünf Jahren keine klassischen Tester mehr geben wird. 😉

 

← Previous post

Next post →

1 Comment

  1. Guten Tag.

    Danke für diesen Beitrag.
    Die Identifikation möglicher Risiken ist ein wichtiger Prozess in sämtlichen Unternehmensbereichen. Gerade bei der Produktentwicklung, der Software- oder Appentwicklung und der Entwicklung komplexer Sites ist bedarf genauester Prüfung. Risiken in einer Matrix darzustellen ist eine gute Form. Prototypenentwicklung, Zeitverzug, Testszenarien, Mehraufwand, Fehlerkosten, Ressourcen etc. sollten auch als Puffer im Projektplan abgebildet werden.

Leave a Reply