Testen von Geschäftsprozessmodellen in BPMN 2.0
BPM-Testing

Testen von Geschäftsprozessmodellen in BPMN 2.0

Simon Zambrovski, Roman Schlömmer

© Shutterstock.com / Dusit

Durch den Einzug von Prozessorientierung in die Analyse und vor allem durch das Design von Softwaresystemen rücken die Geschäftsprozesse in eine zentrale Position – und das durchgehend, von der Anforderung bis hin zum lauffähigen Artefakt. Zu Recht, denn in den Geschäftsprozessen entsteht die Wertschöpfung. Entsprechend hoch sollten – nein, müssen – die Anforderungen an deren Qualität sein. Aber wie ist diese sicherzustellen?

Geschäftsprozesse in Form von BPMN-2.0-Modellen zu definieren und durch Business Process Engines auszuführen, ist heute gang und gäbe. Im Gegensatz zu implizit betriebenen und insbesondere durch den Anwender gelebten Prozessen, die über viele Systeme lose zusammenhängen, wird das Prozessmodell in diesem Szenario zum expliziten und zentralen Teil des technischen Artefakts. Als solches muss es denselben Anforderungen an Qualität und Korrektheit genügen, wie andere Teile der Software auch. Fehler müssen frühzeitig in der Umsetzung erkannt und behoben werden.

Im Unterschied zu Programmcode, für den es bereits seit vielen Jahren Werkzeuge für die Identifikation von unterschiedlichsten Fehlerklassen gibt, ist das Testen von Geschäftsprozessmodellen in BPMN 2.0 eine recht junge Disziplin.

In diesem Artikel werden praxiserprobte Ansätze zum Testen von Prozessmodellen in BPMN 2.0 vorgestellt und am Beispiel von Camunda BPM – einer modernen Prozess-Engine – demonstriert.

BPMN 2.0

Bei Durchführung von BPM/SOA-Projekten geht es um die Einführung von komplexer Software. Wertschöpfende End-to-End-Prozesse mit vielen Akteuren und diversen beteiligten Komponenten werden konzipiert und – bisweilen über Unternehmensgrenzen hinweg – umgesetzt. Die Anforderungen an diese Art Software werden auf eine ganz spezielle Weise erfasst: Das Skelett für das Gesamtsystem stellen Modelle der Geschäftsprozesse eines Unternehmens dar. Zur Beschreibung von Geschäftsprozessen wird oft eine formale Sprache mit grafischer Notation benutzt, die BPMN 2.0. Der heutige OMG-Standard genießt als Modellierungssprache eine hohe Beliebtheit in der IT und in den Fachbereichen. Da sie von beiden gut verstanden wird, bildet sie einen fundamentalen Teil der gemeinsamen Sprache in einem prozessorientierten Projektkontext. Ein Prozessmodell in BPMN 2.0 beschreibt die so genannte Orchestrierung – den Ablauf und die Reihenfolge der im Prozess auszuführenden Aktivitäten. Diese sind im Modell durch den Sequenzfluss miteinander verbunden.

Die Ausführung des Prozessmodells übernimmt eine Process Engine. Moderne Engines führen BPMN 2.0 direkt aus, damit wird das Modell zum ausführbaren Code. Die Engine unterscheidet beim Ausführen der einzelnen Aktivitäten zwischen Servicetasks und Usertasks. Die Servicetasks stellen eine Verbindung des Geschäftsprozesses zu Softwarekomponenten dar. Die meisten Fachprozesse kommen ohne von Menschen erledigte Aktivitäten und Eingaben nicht aus. Dazu existieren Usertasks, die mittels Formularen Benutzereingaben entgegennehmen und dem Prozess zur weiteren Verarbeitung zur Verfügung stellen.

Prozessmodell testen

Da der Prozess zum ausführbaren Artefakt wird, ist es von zentraler Bedeutung, dass das Prozessmodell getestet wird. Idealerweise bevor die Software mit ihren Services und Formularen überhaupt gebaut ist.

Das Ziel sind automatisiert ablaufende, permanent wiederholbare Tests anstelle von aufwändigen, manuellen und dadurch fehleranfälligen Tests durch den Anwender am mehr oder weniger fertigen System. Daher orientieren wir uns beim Testen am Vorgehen bei der Überprüfung des Quelltexts einer Programmiersprache: Zunächst sucht man nach Syntaxfehlern, daraufhin nach semantischen und sichert im Anschluss die Ausführungspfade mit Tests ab.

Übertragen auf Prozesse bedeutet das: Die erste und einfachste Prüfung ist die Erfüllung des BPMN-2.0-Standards (syntaktische Prüfung). Als Nächstes geht es darum, die Verbindung zwischen dem Prozessmodell und der Software zu validieren (semantische Prüfung), die im BPMN-2.0-Modell durch spezielle Attribute abgebildet ist und Artefakte aus der Software referenziert. Der letzte und entscheidende Schritt dient der Verifizierung der korrekten Umsetzung der fachlichen Anforderungen. Es wird überprüft, ob das spezifizierte Modell den fachlichen Geschäftsprozess korrekt abbildet (Verhaltensprüfung).

Im Folgenden stellen wir einige Aspekte der Methodik zum Testen von Geschäftsprozessen vor, die mit der Open Source Engine Camunda BPM aufgebaut wurden. Die Konzepte der Methodik sind dabei nicht spezifisch für die Camunda BPM Engine, können aber nur auf Engines implementiert werden, die bestimmte technische Voraussetzungen erfüllen. Diese liegen, neben der direkten Ausführung des BPMN-2.0-Modells, vor allem in der Fähigkeit der Engine, aus einem Softwaretest heraus ausgeführt und per API kontrolliert zu werden.

Syntaktische Prüfung

Der erste Test, der überprüft, ob das erzeugte Geschäftsprozessmodell syntaktisch korrekt ist, wird von der Engine oder sogar bereits von dem Modellierungswerkzeug selbst durchgeführt. Die meisten Engines machen bei Auslieferung des BPMN-2.0-Modells mindestens einen Syntaxcheck und überprüfen die Validität gemäß dem BPMN-2.0-Standard. Neben der Validität muss auch die Ausführbarkeit innerhalb der Process Engine geprüft werden. Damit die Engine eine Servicetask ausführen kann, muss die Adresse des aufzurufenden Service angegeben sein. Bei durch Gateways abgebildeten Ablaufentscheidungen mit mehreren ausgehenden Sequenzflüssen muss an jedem Nicht-Default-Fluss die Bedingung der Ausführung angegeben werden.

Diese und einige andere Eigenschaften haben zwar nichts mit der Erfüllung des BPMN-2.0-Standards zu tun, können aber auch durch ein im Test enthaltenes Deployment in die Engine überprüft werden. Wenn das Prozessmodell syntaktische Fehler beinhaltet, werden von der Engine Fehler produziert, die das Deployment und damit den Test fehlschlagen lassen.

Semantische Prüfung

Ein syntaktisch korrektes und strukturell valides BPMN-2.0-Modell bedeutet nicht, dass es ausführbar ist, also muss als Nächstes eine semantische Prüfung durchgeführt werden. So ist z. B. die Tatsache, dass eine Servicetask eine Adresse des aufzurufenden Service enthält, Bestandteil der syntaktischen Korrektheit. Doch ob hinter der Adresse tatsächlich ein Service gefunden werden kann, ist dadurch noch nicht zugesichert.

Für die Verbindung zwischen dem BPMN-2.0-Modell und den Software- und UI-Komponenten werden Ausdrücke im Modell zur Laufzeit von der Engine ausgewertet und die entsprechenden Softwarekomponenten aufgerufen. Um das Modell vor der Erstellung dieser Softwarekomponenten zu testen, müssen sie durch Mocks belegt werden, die unter denselben Namen verfügbar sind, wie später in der Engine. Für die Nichttechniker: Mocks sind hier kleine, speziell für den Test erstellte Stellvertreter für die „echten“ Services, die später entwickelt und eingebunden werden.

Verhaltensprüfung

Nachdem der Prozess nun syntaktisch und semantisch korrekt ist, geht es darum, die Orchestrierung, also den Ablauf und die Reihenfolge der Aktivitäten, zu testen. Das mag auf den ersten Blick befremdlich wirken. Wir haben ein Modell, das den Ablauf beschreibt und dazu noch direkt ausgeführt wird. Also, was testen wir? Wir wollen nicht testen, ob die Engine BPMN-2.0-Modelle gemäß Spezifikation korrekt ausführt. Das sollten wir als gegeben annehmen. Vielmehr geht es um das Modell als Beschreibung des gewünschten Ablaufs als solches. Wir müssen sicherstellen, dass das Modell die tatsächlich gestellten Anforderungen abdeckt und dass beim Übergang auf das Prozessmodell keine Fehler passiert sind. Für einen einfachen und streng sequenziellen Ablauf ohne alternative Ablaufpfade ist das noch einigermaßen trivial. Aber das echte Leben ist anders. Entscheidungen im laufenden Prozess führen zu unterschiedlichen Abläufen. Abhängig von der Kredithöhe kann beispielsweise eine verkürzte maschinelle Prüfung oder eine vollumfängliche Prüfung mit mehreren Akteuren stattfinden. Die Entscheidung für eine Ablehnung zieht andere Folgeschritte nach sich als die Bewilligung.

Ausgedrückt werden diese Ablaufvarianten im Prozessmodell durch so genannte Gateways. Diese operieren auf den Daten, die mittels Prozessvariablen durch den Prozess transportiert werden.

Separation of Concerns bei BPM-/SOA-Systemen

Abb. 1: BPM-/SOA-Referenzarchitektur

Abb. 1: BPM-/SOA-Referenzarchitektur

Grundsätzlich gilt es beim Design von Prozessen und Services, die Ablauflogik und die Fachlogik strikt voneinander zu trennen (Abb. 1). Die Ablaufsteuerung übernimmt das Prozessmodell und Operationen auf Fachdaten erfolgen innerhalb von Servicetasks. Das erhöht die Testbarkeit und bildet die Basis von flexiblen, schnell änderbaren Prozessen und von Wiederverwendung. Die Verknüpfung zwischen diesen zwei Welten stellen die Prozessvariablen dar.

Ob die Bedingung an einem Prozesspfad richtig formuliert ist, kann man mithilfe von Tests schon vor der Implementierung der Geschäftslogik überprüfen – das spart Zeit und minimiert Folgefehler. Dazu muss die Process Engine im Simulationsmodus gestartet werden. Nach dem Prozessdurchlauf wird ausgewertet, welche Servicetasks ausgeführt wurden. Diese Anforderung wird von verschiedenen Process Engines unterschiedlich gut implementiert.

Auch hier bietet sich für den Einsatz im Test die in der Softwareentwicklung etablierte Verwendung von Mock-Objekten an, die die Prozessvariablen anstelle der eigentlichen Serviceimplementierung auf eine bestimmte, definierte Art verändern und so unterschiedliche Abläufe gezielt hervorrufen.

Im Test werden nun Prozessinstanzen gestartet, die anhand unterschiedlicher Mock-Konfigurationen unterschiedliche Pfade und Aktivitäten durchlaufen. Im Rahmen des Tests muss also geprüft werden, welche Aktivitäten ausgeführt und welche Services aufgerufen wurden. Dazu werden die verwendeten Mock-Objekte so konfiguriert, dass nach der Ausführung der Tests beispielsweise die Anzahl der Mock-Aufrufe überprüft werden kann.

Prozessarchäologie an Scheidewegen

Mit den Tests für die Überprüfung der ausgeführten Servicetasks hat man eine hinreichende Bedingung für die Prozessausführung definiert: Im Test wurde erwartet, dass die Mock-Services aufgerufen werden, was auch nachgeprüft werden konnte.

Wenn das Prozessmodell nachträglich geändert wird und dabei neue Ausführungspfade entstehen, kann es leicht passieren, dass diese Überprüfung an Aussagekraft verliert. Das ist der Fall, wenn eine überprüfte Bedingung zwar hinreichend, aber nicht mehr notwendig ist. Um das auszuschließen, sind Tests notwendig, die nicht nur überprüfen, dass bestimmte Knoten durchlaufen wurden, sondern zusichern, dass es die einzigen waren.

Die meisten BPM-Engines schreiben eine Art Audit-Log über die Ausführung der Prozessinstanzen und bieten eine Möglichkeit, diesen zu Analysezwecken zu verwenden. Durch die expliziten Tests der Orchestrierung können Wege im Prozess durchlaufen und Bedingungen geprüft werden. Dafür müssen Tests implementiert werden, die eine Abfolge von Schritten in vorgegebener Reihenfolge überprüfen. Dabei ist es wichtig, nicht nur die Ausführung von Service- und Usertasks zu überprüfen, sondern auch die Reihenfolge von Gateways mit zu berücksichtigen.

Durch nachträgliche Prozessveränderungen können mittels Modifikationen neue Ausführungszweige entstehen, die noch nicht getestet wurden – diese fallen dann sofort auf, weil einige Tests unerwartete Sequenzknoten in ihrer Ausführung entdecken. Als Ergebnis entstehen Prozessmodelle und Tests, die eine sehr hohe Kopplung haben.

Prozesse sind keine Units

Aufgrund der Integration von JUnit-Tests in die Entwicklungsumgebung und in die Build- oder Continuous-Integration-Werkzeuge ist das JUnit-Framework relativ beliebt. Wichtig ist, im Hinterkopf zu behalten, dass der Unit-Ansatz an sich nur für eine spezielle Art von Tests geeignet ist. Er ist vor allem dadurch gekennzeichnet, dass die zu testende Stelle gut isolierbar ist und die Vorbedingungen im Test einfach aufgebaut werden können.

Beim Testen von Geschäftsprozessen sind diese Bedingungen nicht erfüllt. Bei langen Ausführungspfaden müssen ganze Prozesszweige in der Initialisierung der Tests ausgeführt werden, wodurch die Tests ihre Übersichtlichkeit verlieren und in der Erstellung sehr aufwändig werden können – ein häufiger Grund für unzureichende Testabdeckung und entsprechende Fehler in der Produktion. Die Komplexität im Test und eine hohe Wiederholung innerhalb der Testmethoden führen somit zum Versagen der Unit-Methodik bei Geschäftsprozesstests.

Statt auf einen Unit Test zu setzen, kann bei Geschäftsprozesstests auf verhaltensorientierte Tests gesetzt werden. Bei verhaltensorientierten Tests (engl. Behaviour-driven Development oder BDD) liegt der Fokus auf dem Testen von Systemen in unterschiedlichen Zuständen, die zusammen ein Verhalten bilden. Ein Geschäftsprozess bildet dabei für gewöhnlich selbst mehrere alternative Verhaltensspezifikationen ab, die abhängig von Systemeingaben sind. Der verhaltensorientierte Test konzentriert sich dabei auf die Erfüllung von bestimmten Eigenschaften eines Systems als Reaktion auf die Systemeingaben.

Beim verhaltensorientierten Testen beschreibt eine Testspezifikation eine Abfolge von Aktionen, die das System aus einem Zustand in einen anderen überführt. Populär ist dabei die Verwendung von einer speziellen Form der Testdefinition: der Gherkin-Syntax. Diese schreibt vor, die einzelnen Tests in Form von Szenarien zu beschreiben. Jedes davon besteht aus einer Reihe von Aussagen, die mit „Angenommen“, „Wenn“, „Dann“ beginnen. Der Vorteil der Gherkin-Syntax ist, dass die Tests in natürlicher Sprache geschrieben werden und somit durch den Fachbereich verstanden und erstellt werden können. Dieser Aspekt ist nicht zu unterschätzen: Würde ein Entwickler einen solchen Test formulieren, enthielte er aller Wahrscheinlichkeit nach dieselben fachlichen Fehler, die auch das Prozessmodell beinhaltet. Beides ist auf Basis seines Verständnisses der Anforderung entstanden.

Dennoch ist der Entwickler nicht gänzlich unbeteiligt an der Erstellung der Tests. Mithilfe von speziellen BDD-Frameworks können die Testspezifikationen direkt ausgeführt werden. Dazu ist die Implementierung von Code notwendig, der die Spezifikation mit der Anwendung verbindet – dem so genannten Glue-Code. Die einzelnen Methoden des Glue-Codes dienen dabei sowohl zur Steuerung der Anwendung als auch zum Auslesen der Ergebnisse und dem Vergleich zwischen Soll- und Istwert.

Der offensichtliche Unterschied zwischen BDD-Tests und Unit Tests beim Testen von Geschäftsprozessen ist, dass bei BDD die Orchestrierung der Glue-Code-Methoden in der Gherkin-Syntax beschrieben ist. Einige BDD-Frameworks erlauben neben der klassischen Gherkin-Syntax auch weitere Konstrukte, die höherwertige Wiederverwendung fördern. So können z. B. mittels JBehave ganze Szenarien mit der Angenommen-Klausel versehen werden, sodass ein vorhandener Test vollständig wiederverwendet werden kann. Damit wird das Testen von Ausführungspfaden vereinfacht und kann inkrementell entlang des Sequenzflusses aufgebaut werden.

Fazit

Durch den Einsatz von BPMN 2.0 als Modellierungssprache für Geschäftsprozesse ist es erstmals möglich, dasselbe Modell durchgehend von der Anforderungsanalyse bis hin zur Implementierung zu verwenden. Das Prozessmodell wird dabei zum zentralen Teil des technischen Artefakts. Dadurch wachsen aber auch Anforderungen an die Qualität des Modells, sodass dieses durch Tests abgesichert werden muss.

Um Prozessmodelle überhaupt testen zu können, ist es allerdings notwendig, dass die Business Process Engine die im Artikel angeführten Möglichkeiten des Zugriffs und der Steuerung anbietet. Damit gibt es für die Business Process Engines ein weiteres Merkmal, anhand dessen die Auswahl von Produktalternativen ausgewertet werden kann.
Camunda BPM erfüllt diese Kriterien und wurde zur Evaluierung und Erprobung der Ansätze verwendet. Die Ansätze sind also übertragbar, soweit die Business Process Engine alle oder einige der benötigten Features zur Verfügung stellt.

So wie in der klassischen Testpyramide müssen geeignete Tests verwendet werden, die Prozessmodelle testen: möglichst isoliert, unabhängig von anderen Softwareartefakten und möglichst früh in der Entwicklung. Nur so lassen sich qualitativ hochwertige und vor allem zukunftsorientierte Geschäftsprozesse auf Basis von Business Process Engines realisieren – ein lohnender Invest in die Nachhaltigkeit Ihrer Wertschöpfung!

Aufmacherbild: business man writing concept of business process improve growth via Shutterstock.com / Urheberrecht: Dusit

Geschrieben von
Simon Zambrovski
Simon Zambrovski
Simon Zambrovski ist bei Holisticon AG in Hamburg als BPM-Craftsman, Senior Consultant und Architekt im Kundenauftrag tätig und beschäftigt sich mit agilen BPM-/SOA-Projekten. Sein Engagement gilt auch dem Testen von Prozessen, das das agile BPM-Vorgehen erst möglich macht.
Roman Schlömmer
Roman Schlömmer
Roman Schlömmer leitet das Geschäftsfeld BPM/SOA bei der Holisticon AG. Als strategischer Berater begleitet er Unternehmen bei der Einführung von BPM/SOA. Kundenprojekte unterstützt er als Business Analyst, Architekt und Coach für die agile Durchführung von BPM-/SOA-Projekten.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.