Vom Post-it zum Test

Event Storming aus der Sicht eines Testers
Keine Kommentare

Event Storming ist im Domain-driven Design eine gute Methode, ein gemeinschaftliches Verständnis aller Projektbeteiligter bezüglich der Anwendungsdomäne zu erlangen und dabei ein Prozessmodell zu erstellen. Oft wird dabei aber außer Acht gelassen, dass die dabei entwickelten Informationen nur mit wenig Aufwand direkt in automatisierbare Testfälle transformiert werden können. Daher soll hier die Frage beantwortet werden, wie die verschiedenen Modellierungspattern des Event Stormings in sinnhafte Behavior-driven-Design-Testfälle umgesetzt werden können.

In Softwareprojekten ist es essenziell, ein gutes Verständnis für die Fachdomäne der zu entwickelnden Software zu erhalten und aufgrund dessen eine passende Architektur zu entwerfen. Eine Möglichkeit, dieses Wissen aufzubauen und zu erweitern, ist, durch Workshops mit allen Stakeholdern und Projektbeteiligten Prozessmodelle für die verschiedenen Anwendungskontexte zu erstellen und dabei ein fachspezifisches Vokabular zu vereinbaren – die Ubiquitous Language. Event Storming ist dabei ein Modellierungsansatz, dieses Ziel zu erreichen und auf diese Weise sowohl technisch versierte als auch rein fachliche Experten zusammenzubringen, sodass sie ihre Visionen der geplanten Software austauschen.

Das Event-Storming-Modell

Da der Fokus in diesem Artikel auf dem Entwickeln von Testfällen aus dem entstandenen Event-Storming-Modell liegt, wird auf die nähere Beschreibung eines Event-Storming-Workshops an dieser Stelle verzichtet und direkt mit einem möglichen Ergebnismodell gearbeitet. Eine kurze Beschreibung des Vorgehens und aller Elemente eines Event Stormings ist im Kasten „Wie funktioniert Event Storming?“ nachzulesen.

Wie funktioniert Event Storming?

Event Storming ist ein relativ einfacher Ansatz, mit dem man unter Zuhilfenahme von Post-its und einer weißen Tapete gemeinschaftlich die für die Software relevanten Prozesse modelliert. Dazu bereitet man einen Raum vor, in dem man ein langes Stück Tapete quer auf die Wände hängt und verschiedenfarbige Post-its sowie gut lesbare Stifte bereitlegt. Bei der Modellierung störendes Mobiliar wird zur Seite geräumt.

Elemente des Event Stormings

Im Event Storming gibt es mehrere Modellierungselemente:

  1. Domain Events:
    Das sind Ereignisse innerhalb des Systems, die für Domänenexperten relevant sind. Sie lösen Reaktionen aus und können sehr kleingranular gehalten sein. Sprachlich sind sie in der Vergangenheitsform verfasst.

  2. Kommando:

    Mit einem Kommando werden die Entscheidungen beteiligter Akteure modelliert. Sie werden in der Befehlsform notiert. Ereignisse und Kommandos können nie direkt aufeinander folgen.

  3. Aggregat: Aggregate sind Objekte, die aufgrund eines Kommandos ein Ereignis auslösen. Sie entsprechen State Machines und stellen die Kernelemente innerhalb des Systems dar. Da sie normalerweise erst während der Modellierung gefunden werden, wird ihre endgültige Bezeichnung häufig erst in einer späten Phase der Modellierung festgelegt.

  4. Externes System:

    Die externen Systeme sind Organisationen oder Services, die innerhalb des modellierten Prozesses angesprochen werden und auf die kein Einfluss genommen werden kann. Sie stellen so etwas wie Blackboxes dar. Man kann ihnen Kommandos zusenden und irgendwann wird von ihnen ein Ereignis erzeugt. Zeitliche Vorhersagen sind im Normalfall nicht möglich.

  5. Regel:

    Regeln sind automatisierte oder regelbasierte Entscheidungen, die ohne eine Benutzerinteraktion innerhalb des Systems gefällt werden. Sie stellen die reaktive Logik dar und können häufig mit den Schlüsselwörtern „immer wenn“ modelliert werden, falls sie an keinerlei Bedingungen in ihrer Ausführung geknüpft sind.

  6. Lesemodell:

    Mit Hilfe von Lesemodellen werden Informationen und Daten, die für Entscheidungen des beteiligten Benutzers notwendig sind, bereitgestellt. Sie werden in der späteren Anwendung normalerweise in einer Oberfläche präsentiert. Ergänzend dazu können auch noch konkrete Bildschirmdesigns im Modell aufgenommen werden.

  7. Benutzer:

    Die Akteure, die für Aktionen und Ereig-nisse innerhalb des modellierten Systems verantwortlich sind, werden beim Event Storming durch die Benutzer modelliert. Sie agieren aufgrund ihrer Erfahrung und den Informationen, die vom System zur Verfügung gestellt werden.

  8. Unklare Bereiche:

    Unklare Bereiche sind Modellierungsbereiche, in denen noch nicht vollkommen klar ist, was passiert. Sie werden dazu verwendet, im aktuellen Modell Markierungen für alle Teilnehmer des Modellierungsworkshops zu setzen. Dadurch wird verdeutlicht, dass dieser Bereich noch einmal genauer betrachtet und ggf. nachbearbeitet werden muss, da es hier noch Unklarheiten gibt. Meistens werden diese Post-its um 45 Grad gedreht, sodass sowohl farblich als auch geometrisch bereits aus einiger Entfernung ein solcher Brennpunkt im Modell erkannt werden kann.

  9. Definitionen:

    Mit Hilfe dieses Modellelements werden Definitionen des Vokabulars, das innerhalb der Domäne verwendet wird, erklärt. Hier werden Begrifflichkeiten definiert, die später auch in der Ubiquitous Language dokumentiert werden.

Regeln des Event Stormings

Die Regeln eines Event-Storming-Modells sind einfach erklärt (Abb. 1). Ein Benutzer löst Aktionen für ein Aggregat oder ein externes System aus, die ein Domain Event erzeugen. Sie werden ggf. von internen Regeln ausgewertet und bei Erfüllung der Voraussetzungen wird vom System wieder ein Kommando erzeugt. Alternativ stellt das Event Daten zur Verfügung, die mit Hilfe eines Lesemodells dem Benutzer präsentiert werden. Aufgrund seiner Erfahrungen und den gelieferten Informationen kann der Nutzer dann eine Entscheidung treffen und erneut ein Kommando im System erzeugen. Die letzte Möglichkeit, Events im System zu erzeugen, sind externe Systeme. Sie werden entweder außerhalb des modellierten Prozesses oder als Reaktion auf Kommandos aus dem System angestoßen und erzeugen Domain Events, die innerhalb des Prozesses weiterverarbeitet werden.

Vorgehen beim Event Storming

Die Modellierung beginnt meistens damit, die Events aufzuschreiben und in einer zeitlichen Reihenfolge auf die Tapete zu kleben. Dazu erhält jeder Teilnehmer seinen eigenen Post-it-Block, sodass jeder etwas zum Modell beitragen kann. Doppelte oder gleichbedeutende Zettel werden zusammengefasst. Nach einer angemessenen Zeit werden die Kommandos und dann die Aggregate modelliert. Die Akteure des Systems werden identifiziert und die beteiligten externen Systeme eingebunden. Systemautomatismen und ihre Regeln werden modelliert und die für Entscheidungen benötigten Informationen und Daten dokumentiert.

Auch wenn sich die Beschreibung relativ einfach und schnell anhört, kann ein Event Storming mehrere Stunden andauern und ggf. sogar mehrmals wiederholt werden, da das primäre Ziel der Informationsgewinn ist. Für weitergehende Informationen über Event Storming sei hier auf die Quellenauflistung unter [1] und auf [2] verwiesen.

Abb. 1: Schaubild für die Anwendung der einzelnen Modellierungselemente

Abb. 1: Schaubild für die Anwendung der einzelnen Modellierungselemente

Als Anwendungsvision wird ein Musikereventportal (Kasten: „Musikereventportal“) mit der unten dargestellten Beschreibung verwendet. Insgesamt wird lediglich auf einen kleinen Teilprozess eingegangen, nämlich die Auswahl einer Konzerthalle durch einen Musiker und der Bestätigung der Reservierung durch den Besitzer.

Musikereventportal

Sie sind Gründer eines Webportals, das Musiker und Konzerthallenbesitzer miteinander in Kontakt bringen soll. Die Idee ist, dass sich Musiker registrieren und anschließend Konzerte an verschiedenen Orten und zu unterschiedlichen Zeitpunkten planen können. Dazu sollen sie Konzerthallen oder -räume entsprechend ihrer Anforderungen (z. B. Datum, Größe der Halle, Ort, Musikgenre, ggf. Besitzer) suchen und für sich reservieren können.

Konzerthallenbesitzer können sich ebenfalls registrieren und ihre Räumlichkeiten anbieten. Dabei müssen sie die Größe der Halle, die gewünschten Musikgenres, die technische Ausstattung und die verfügbaren Termine sowie die Kosten für die Halle angeben. Zusätzlich können sie angeben, ob es ihnen möglich ist, Getränke und Verpflegung für die Zuhörer anzubieten. Um insbesondere Konzerthallenbesitzer für das Portal zu begeistern, soll das System automatisch einen Vorschuss von den Musikern anfordern, sobald die Miete der Konzerthalle mehr als 10 000 € beträgt.

 
In Abbildung 2 ist das mögliche Ergebnis eines Event-Storming-Workshops zu sehen. Das erarbeitete Prozessmodell kann auf folgende Art interpretiert werden: Ein Musiker wählt eine Konzerthalle aus und erfragt, ob sie für sein Wunschdatum bereits im System vergeben ist. Die Reservierungsvorschrift des Systems erzeugt eine Reservierungsanfrage, wenn beide Ereignisse übermittelt wurden, und verschickt eine entsprechende Mail mit den Musikerdaten, der gewünschten Halle und dem Datum an den Besitzer. Irgendwann weist der Besitzer die Halle dann dem Musiker zu und das System verschickt automatisch eine Reservierung mit Hilfe des Mailsystems, die irgendwann als Ereignis an das Webportal übermittelt wird.


Dort wird dieses Ereignis automatisch weiterverarbeitet und geprüft, ob eine Anzahlung geleistet werden muss. Falls das erforderlich ist, wird es für die Konzerthalle beantragt und durch die Rechnungsvorschrift mit Hilfe des Rechnungssystems angefordert. Falls keine Anzahlung erforderlich ist, wird die Halle reserviert und der Musiker kann das bei seinem nächsten Besuch des Portals ablesen.

Abb. 2: Modell des Event Stormings

Abb. 2: Modell des Event Stormings

Grundlagen der Testfallformulierung

Die Verwendung von Behavior-driven Design (BDD) in Kombination mit Domain-driven Design (DDD) hat den großen Vorteil, dass sich Synergieeffekte erzielen lassen, da beide Techniken auf den gleichen Prinzipien basieren. Es wird das fachspezifische Vokabular verwendet, um auf diese Weise das Verhalten des Systems zu formulieren.

Eine Möglichkeit, Testfälle im Sinn von BDD zu formulieren, ist die Verwendung der im Test-Framework Cucumber verwendeten domänenspezifischen Sprache Gherkin. Mit ihr erstellte Testfälle können sowohl als Dokumentation genutzt als auch als automatisierte Tests verwendet werden. Durch die einfache Syntax der Sprache ist es möglich, dass Fachexperten sie direkt formulieren und die Entwickler bzw. Testautomatisierer die einzelnen Testschritte nur implementieren müssen. Im Folgenden ist ein Beispiel für einen solchen Test abgebildet:

Feature: Book a Concert Hall
 
  The musician wants to book an Event Hall to give a
  concert. He has to specify some outline data like
  the size of the hall, chairs, size of the stage
  etc. 
 
  Scenario: Book an already assigned Concert Hall
 
    Given Paul McCartney wants to give a concert on 01.01.2020
      But the chosen concert hall is already assigned to him
      When he books the concert hall
      Then the concert hall is still assigned to him
      And a reminder is shown

Ein Testfall beginnt mit dem Schlüsselwort Feature, dem eine Beschreibung als ein Satz folgt. Eine weitergehende Dokumentation kann angehängt werden. Es folgen das Scenario, mit dem ein einzelnes Testszenario eingeführt wird. Der eigentliche Test wird mit den Schlüsselworten Given, When und Then eingeleitet, denen But und And ergänzend beigestellt werden können.

Mit Given wird die Vorbedingung eines Tests definiert. Hier wird beschrieben, in welchem Kontext der Test durchgeführt wird und welche zusätzlichen Bedingungen erfüllt sein müssen. Auch die Daten, die im System bekannt sein müssen, werden hier aufgeführt. When leitet die Aktion ein, die mit den zuvor beschriebenen Daten durchgeführt werden soll. Hier wird die Geschäftsregel, die getestet werden soll, beschrieben. Im Then-Teil wird die erwartete Antwort des Systems auf die zuvor durchgeführte Aktion formuliert. Hier wird beschrieben, wie die Ergebnisse aussehen bzw. welche Aktionen ggf. in einem externen System ausgelöst werden. Mit Hilfe von But und And können zusätzliche Vor- bzw. Nachbedingungen formuliert werden.

Es gibt noch weitere Elemente in der Sprache Gherkin, die hier aber nicht näher erläutert werden, da sie primär der eleganteren Formulierung von Testfällen dienen. Nähere Informationen zu Gherkin können unter [3] und [4] gefunden werden.

Transferpatterns in Gherkin

Wie bereits in der Einleitung erwähnt, besteht nun das Problem, dass man ein Event-Storming-Modell in Testfälle transformieren möchte. Wenn man sich dazu das Event Storming anschaut, erkennt man grundsätzlich das in Abbildung 3 dargestellte Muster, das sich immer wiederholt. Dieses Muster kann man wiederum in Bausteine aufteilen, die sich gut auf die von Gherkin verwendet Syntax abbilden lassen.

Abb. 3: Grundmuster im Event Storming

Abb. 3: Grundmuster im Event Storming

Abb. 4: Given, statusbasiert betrachtet

Abb. 4: Given, statusbasiert betrachtet

Abb. 5: Given, Event-basiert betrachtet

Abb. 5: Given, Event-basiert betrachtet

  1. Given, statusbasiert: Es gibt zwei verschiedene Arten, einen Given-Schritt zu betrachten. Wenn man den Fokus auf das Aggregat oder das Regelsystem legt, dann beschreibt man in diesem Schritt den internen Zustand des jeweiligen Elements. In Abbildung 4 kann man ein Beispiel für ein Aggregat sehen, in dem der interne Zustand im Test als Vorbedingung beschrieben wird. Auch der Testschritt mit der Systemregel enthält die Bedingung, die als Voraussetzung für ein Auslösen des Automatismus erfüllt sein muss.

  2. Given, Event-basiert: Die zweite Art, einen Given-Schritt zu modellieren, ist die Fokussierung auf die Ereignisse des Systems. Dabei wird deren Fluss als Vorbedingung verwendet und nicht die Zustände, in denen sich Aggregat oder System befinden. In Abbildung 5 wird für das Aggregat der Fall modelliert, dass ein Event nicht aufgetreten ist (dargestellt durch das durchgestrichene Event). Das ist in der Formulierung dasselbe wie im statusbasierten Schritt. In der Formulierung der Systemregel wird dagegen der Unterschied deutlich, da dort die Events die bestimmenden Faktoren darstellen. Welche Art von Formulierung man für den Given-Schritt auswählt, hängt von der persönlichen Vorliebe bzw. der im System beschriebenen Situation ab.

  3. When: Der When-Schritt ist relativ einfach zu modellieren. Da hier die Aktionen innerhalb des Systems abgebildet werden, ist die eine Möglichkeit, das zu tun, ein Kommando. In Abbildung 6 ist ein Beispiel hierzu aufgeführt. Die zweite Möglichkeit ist die Modellierung von Events, die von externen Systemen ausgelöst werden. Da hierbei nicht die internen Aktionen genutzt werden können, besteht lediglich die Möglichkeit, das im System ausgelöste Event zu verwenden, um so Aktionen des externen Systems zu simulieren.

  4. Then: Mit dem Then-Schritt wird die Nachbedingung (also die Reaktion des Systems auf eine Aktion) modelliert. Das lässt sich relativ einfach durch die Verwendung eines Ereignisses innerhalb dieses Schrittes erreichen (Abb. 7). Aber auch hier ergibt sich ggf. die Schwierigkeit, dass sich bei Verwendung von externen Systemen kein testbares Antwortverhalten erzwingen lässt. Daher kann man in diesem Fall direkt auf das Kommando testen, das an das externe System verschickt wird.

Abb. 6: When-Schritt

Abb. 6: When-Schritt

Abb. 7: Then-Schritt

Abb. 7: Then-Schritt

Beispiel

Als konkretes Beispiel soll hier nun ein Testfall für den in Abbildung 8 dargestellten Teilausschnitt des besagten Modells formuliert werden.

Abb. 8: Teilmodell

Abb. 8: Teilmodell

 

Feature: Reservation of a Concert Hall
Scenario: Musician requests a Date with given Concert Hall
Given the Musician has selected the Dortmunder Westfalenhalle 
When he requests the concert date at 01.01.2020
Then the Concert Hall Reservation is sent to the owner.
 
Scenario: Musician requests a Concert Hall with given Date
Given the Musician requests the concert date at 01.01.2020
When he has selected the Dortmunder Westfalenhalle 
Then the Concert Hall Reservation is sent to the owner.

In den oben dargestellten Tests wird die Reservierungsregel geprüft. Sie soll automatisch beim Auftreten von zwei Events eine Reservierungsanfrage per Mail an den Besitzer auslösen. Dabei ist es unerheblich, in welcher Reihenfolge die Events ausgelöst werden. Im Beispiel kann man auch gut erkennen, dass bei der Erstellung der Tests nicht auf jedes Einzelereignis im Modell eingegangen werden muss, sondern dass es dabei um den Gesamtkontext und die Funktionalität des Systems aus der Nutzer- bzw. externen Sicht ankommt. Durch die Auswahl von fachlich sinnvollen Ereignisketten ist es möglich, die Qualität der zu entwickelnden Anwendung direkt während der Entstehung positiv zu beeinflussen.

Fazit

Event Storming ist ein mächtiges Werkzeug, um Prozesse in der Anwendungsdomäne zu modellieren und so ein gemeinsames Verständnis aller beteiligten Personen zu erreichen. Durch die Verwendung der aufgeführten Testmuster ist es möglich, aus dem entstandenen Modell hochwertige Tests zu entwerfen und auf diese Weise die Qualität der zu erstellenden Anwendung signifikant zu verbessern. Dabei sollte man beim Erstellen der Testfälle mit Hilfe von Gherkin bedenken, dass nicht jeder technisch mögliche Schritt abgebildet werden muss, sondern nur fachlich sinnvolle. Daher sollte wenigstens der sogenannte Happy Path als Testfall erstellt werden. Davon ausgehend sollten von den Fachexperten die sinnvollsten Szenarien für die Tests ausgewählt werden. Alle anderen Testfälle sollten auf einer anderen technischen Ebene gemäß der Testpyramide geprüft werden. Nur so kann am Ende die Software entstehen, die der Kunde wollte, und nicht die, die er bestellt hat.

 

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -