Eigentlich hatte man sich von der Einführung einer Prozessengine erhofft, flexibel und gleichzeitig zuverlässig Anpassungen am Geschäftsablauf der Anwendung vornehmen zu können. Leider kommt es immer wieder zu Fehlern im Produktivbetrieb, da bei den Änderungen Abhängigkeiten im Prozess übersehen werden. Auch dass eine komplette Integrationsumgebung aufgesetzt wurde, um den Prozess vorab durch Tester manuell testen zu lassen, hat nur bedingt Besserung gebracht: Wiederholt rutschen Bugs in die Produktion durch. Die Idee, diese Tests automatisiert ablaufen zu lassen, wurde aufgegeben – zu aufwändig waren die Provisionierung der Integrationsumgebung, automatisierte Testdatenbereitstellung in allen beteiligten Systemen sowie die Pflege der Testabläufe im Fall von fachlichen Prozessänderungen. Und mit den gefundenen Fehlern konnte sowieso niemand etwas anfangen – sie waren unspezifisch und es dauerte Stunden, bis die Ursache gefunden und behoben werden konnte.

Waren die vollmundigen Versprechen des Zusammenwachsens von Fachbereich und IT durch die gemeinsame Arbeit mit Prozessmodellen also nur ein schöner Traum? Könnte man meinen. Es geht aber besser. Und wie das geht, wollen wir in diesem Blogbeitrag erklären.

Seit der Version 2.0 ist BPMN ausführbar. Das bedeutet, das Prozessmodell ist Teil des Anwendungscodes. Damit unterliegt es denselben Qualitätskriterien wie der „normale“ Quellcode. Es gibt ein breites Verständnis, wie dieser zuverlässig und trotzdem flexibel gestaltet werden kann: Durch agiles Projektvorgehen wird die Software iterativ-inkrementell entwickelt. Um Regressionen auszuschließen und Refactoring zu ermöglichen, wird testgetrieben entwickelt. Hierfür muss ein Großteil der Tests schnell und einfach durchführbar sein. Ebenso wichtig ist, dass die Tests fokussiert sind. Schlägt ein Test fehl, muss einfach feststellbar sein, wo das Problem liegt. Im Idealfall findet der Entwickler selbst das Problem und kann es so frühzeitig und zügig beheben. Je aufwendiger die Testklasse aufgrund steigenden Integrationsgrades, desto weniger Tests hat man im Idealfall – und desto seltener sollten die Tests fehlschlagen. Alle diese Eigenschaften einer guten Teststrategie sind als Testpyramide bekannt und für die meisten sicher nichts Neues.

Warum sollte man dann aber im Fall von Prozessen – wir hatten uns darauf geeinigt, dass sie Teil des ausführbaren Programmcodes sind – anders verfahren? Das leider noch viel zu verbreitete Modell „Eiswaffel“ hat doch schon für „normalen“ Code nicht getaugt…

Die Basis der Testpyramide stellen Unit-Tests dar. Klassische Unit-Tests sind technische Tests, die zum Ziel haben, ein abgeschlossenes Modul möglichst vollständig zu testen. Dies greift für Prozessmodelle zu kurz: Prozesse sind keine Units! Das Prozess-Artefakt beschreibt komplexe, fachliche Arbeitsabläufe eines (quasi-)offenen Systems. Vollständigkeit wird hier kaum durch Abtesten einzelner Zustände möglich sein. Vielmehr geht es darum, relevante, fachliche Zustandsfolgen zu überprüfen. Hierfür eignen sich hervorragend BDD (Behavior Driven Design) und die Formulierung der Testfälle in der Beschreibungssprache „Gherkin“. Zusätzlich wird auf diese Weise auch wieder die Brücke zum Fachbereich geschlagen, der die Testfälle verstehen oder sogar mitgestalten kann. Und sind die Szenarien einmal formuliert, stellen sie eine hervorragende Prozessdokumentation dar.

Aus technischer Sicht ist das Ziel, das Prozess-Artefakt möglichst isoliert und mit kurzen Testlaufzeiten zu überprüfen. Glücklicherweise gibt es Process Engines, z.B. camunda, die auch In-Memory ausgeführt werden können und damit genau solche Tests ermöglichen. Sobald die Schnittstellen zu den externen Services des Prozesses bekannt sind (diese müssen noch nicht fertig implementiert sein) kann durch Mocken eben jener Services damit begonnen werden, die Ablauflogik des Prozessmodells in Isolation zu testen – oder dieses gar testgetrieben zu modellieren. Somit können Fehler im Prozessmodell bereits bei der Modellierung und deutlich vor der vollständigen Integration im Gesamtsystem gefunden werden.

Mit der regelmäßigen Ausführung der Testfälle können wir gleich mehrere Dinge sicherstellen. Zum einen ist da die syntaktische Korrektheit unseres BPMN-Modells. Ist diese nicht gegeben, wird sich die ausführende In-memory Engine mit Sicherheit zügig beschweren. Wir sichern durch die fachlichen Test die Korrektheit der Ablauflogik ab. Ebenso wird bei der Prozessausführung im Rahmen des Tests überprüft, dass die Bindings zu aus dem Prozessmodell angesprochenen Java-Klassen (z.B. TaskExecutionListenern oder Delegates), die Verwendung von Prozessvariablen/-daten und die Formulierung von Conditions in Form von Expressions korrekt sind. Somit haben wir ein rundum gut getestetes Prozessmodell, das flexibel und schnell angepasst werden kann.

Fazit

Auf die beschriebene Art und Weise lassen sich Prozesse hervorragend testen. Die Tests können fachlich in Form von Szenarien formuliert werden und dokumentieren gleichzeitig den Prozess. Sie helfen bei der Modellierung, da diese nun testgetrieben vonstatten gehen kann. Regelmäßige Testdurchführungen können mit geringem Zeitaufwand eine hohe Qualität sicherstellen. Flexible Anpassungen sind kein Problem, da Regressionen durch die Tests gefunden werden. Fehlerhafte Modellierungen werden frühzeitig entdeckt und können mit wenig Aufwand behoben werden.

Referenzen

• Meine Kollegen Simon Zambrovski und Jan Galinski haben vor einiger Zeit bereits einen Vortrag zum Thema „Testgetriebene Geschäftsprozessmodellierung“ gehalten. Dieser ist als Video verfügbar und umfasst sowohl die theoretischen Details als auch ein Live-Coding Beispiel.