Testobjekt: Geschäftsprozess – Testen für kontinuierliche Verbesserung

Dr.-Ing. Daniel Lübke

Tammo van Lessen

In diesem Artikel werden wir Herausforderungen wie verteilte Anwendungen, technische und organisatorische Abhängigkeiten von umgebenden Services und Fehlerbedingungen sowie mögliche Lösungen für das Testen von Geschäftsprozessen aufzeigen, die auf Webservices zurückgreifen. Dieses Vorgehen ermöglicht Prozessdesignern, die Qualität ihrer Prozessimplementierung zu verbessern und mehr Vertrauen in die Implementierung zu entwickeln.

Das wichtigste Kapital eines modernen Unternehmens ist das Geschäftswissen, das sich in den Geschäftsprozessen manifestiert. Wendet man die Methoden des Geschäftsprozessmanagements an, kann man dieses Wissen optimieren und gezielter einsetzen. Ein Geschäftsprozess durchläuft dabei einen typischen Lebenszyklus, auch Business Process Management (BPM) Lifecycle genannt, der sich aus fünf Phasen zusammensetzt. Zunächst wird in der Analysephase der Geschäftsprozess identifiziert und anschließend in der Modellierungsphase formal dokumentiert. Damit hat man nun den Ist-Prozess, der in der Ausführungsphase zu erwarten ist, festgehalten. Im Idealfall ist er auch mit dem erwünschten Soll-Prozess identisch. Ob Soll- und Ist-Prozess tatsächlich übereinstimmen, wird in der Überwachungsphase festgestellt, in der nachverfolgt wird, ob sich die beteiligten Personen oder Systeme an das vorgegebene Modell halten. Die dabei gewonnen Informationen sind ein wichtiger Bestandteil für die nächste und letzte Phase des Lebenszyklus: Die Optimierungsphase, in der das Prozessmodell verbessert wird. In dieser Phase werden außerdem mögliche Veränderungen der geschäftlichen und fachlichen Anforderungen eingearbeitet. Damit beginnt der Zyklus erneut. Das soll als kurze Einführung genügen, es gibt natürlich verschiedene Arten, um Geschäftsprozesse umzusetzen, auch die Informationen aus der Analysephase können z.B. durch Simulation erhoben werden.

Geschäftsprozesse und IT

Interessant ist das Zusammenspiel zwischen Geschäftsprozessen und der IT [1]. Ihre Aufgabe ist es, den Menschen bei der Abwicklung der Prozesse bestmöglich zu unterstützen. Dazu gibt es unterschiedliche Ansätze. Zum einen kann man bei der traditionellen Softwareentwicklung von der präzisen Erfassung und Dokumentation der Geschäftsprozesse profitieren. Diese Prozesse werden dann als funktionale Spezifikation interpretiert und in „Code gegossen“. Das Problem ist allerdings, dass die Turnaround-Zeiten, um Änderungen in den Geschäftsprozessen wieder auf die Software abzubilden, sehr hoch sind und damit Optimierungen aufwendig und teuer machen. Die Alternative stellt der Einsatz einer sogenannten Process Engine dar. Ihre Aufgabe ist die direkte Interpretation und Ausführung von Prozessmodellen, d.h., sie arbeitet das Prozessmodell Schritt für Schritt ab. Änderungen an den Geschäftsprozessen kann die Engine direkt umsetzen, indem sie für nachfolgende Instanzen des Geschäftsprozesses das aktualisierte Prozessmodell als Ablaufbeschreibung verwendet. Die Voraussetzung dafür sind Standards wie WS-BPEL oder BPMN 2.0, die sowohl die typische, grafische Modellierung von Prozessen erlauben als auch eine wohldefinierte Ausführungssemantik festlegen. Zu den Aufgaben einer Process Engine gehört außerdem die Überwachung von Prozessen, d.h. jeder Ausführungsschritt wird protokolliert und kann später zur Analyse verwendet werden. Dadurch ist es möglich, die Geschäftsprozesse kontinuierlich zu verbessern und die Änderungen direkt auszurollen.

Unternehmen versprechen sich von dieser Technologie wesentlich schneller auf Marktveränderungen reagieren zu können. Daneben hat der Einsatz einer Process Engine Einfluss auf die Softwarearchitektur und die Programmierparadigmen. Die festprogrammierte Geschäftslogik weicht einer abstrakten Beschreibung der Abläufe und man unterscheidet zwischen den Geschäftsprozessen (Programming in the Large) und den Geschäftsfunktionen (Programming in the Small), also den Diensten, die durch den Prozess aufgerufen werden. Letztere werden traditionell entwickelt und können dank der modularen Struktur einer serviceorientierten Architektur auch gut und mit wenig Aufwand getestet werden. Trotz der vielen Vorteile den der Einsatz einer Process Engine mit sich bringt, darf nicht vergessen werden, dass auch die von der Engine ausgeführten Prozessmodelle getestet werden müssen. Gerade durch die angestrebte kontinuierliche Optimierung der Prozessmodelle ist auch ein kontinuierliches Testverfahren erforderlich.

Aus einem Projekt in einer (nicht so) weit entfernten Galaxie…

Es hatte alles so einfach angefangen. Die Prozesserhebung und -dokumentation war zwar aufgrund der vielen Stakeholder aufwändig und kräftezehrend gewesen, aber letztendlich hatte das Projektteam es geschafft, ein einheitliches Verständnis über die Prozesse zu gewinnen. Neben Workshops und Prozessmodellen wurden Prototypen erstellt, Oberflächen entworfen und immer wieder die fachlichen Vorgänge durchgespielt und nachjustiert.

Doch bereits nach der Finalisierung und während die ersten ausführbaren Prozessmodelle in der Entwicklung waren, kamen neue Prozessvarianten auf. Der zunächst einfache Prozess hatte auf einmal mehrere Untervarianten und neue Attribute in den Geschäftsobjekten. In Abhängigkeit von den verschiedenen Prozessvarianten werden Zahlungen zu unterschiedlichen Zeitpunkten ausgelöst und unterschiedliche PDFs versendet. So kämpfte das Projektteam schon vor dem ersten Release damit, neue Funktionen zu implementieren, weil Änderungen in einer Prozessvariante oftmals ungewünschte Nebeneffekte in den anderen Varianten hatten und es dadurch immer wieder zu Folgeproblemen kam. Diese entdeckte man häufig jedoch zu spät, manchmal gar erst im Produktiveinsatz. In Nachfolgeprojekten, in denen die unterschiedlichen Varianten immer weiter ausgebaut worden waren, wurde diese Situation immer prekärer. Die ursprüngliche Intention, schnell neue Prozessaktualisierungen und -änderungen entwickeln und in Betrieb nehmen zu können, verkam damit zu einem scheinbar unerfüllbaren Traum, den das Projekt nicht einlösen konnte…

Doch wie kam es dazu? Natürlich würde bei einem solchen Projekt sofort BPEL oder BPMN als gescheitert erklärt werden, doch warum konnte das Projekt die eigentlich erwünschte Wartbarkeit und Flexibilität, die man von Prozess-Engines erwartet, nicht nutzen? Die Antwort ist ganz banal: Die ausführbaren Prozessmodelle waren offensichtlich nicht wartbar! Doch warum nicht? Die Antwort liegt versteckt im (Software-)Entwicklungsprozess. Auch ausführbare Prozesse sind unter dem Strich nur eine Software, die entwickelt, gepflegt und getestet werden muss. Gerade wenn hinterher Änderungen gemacht werden, sind automatisierte Tests nötig, die feststellen, ob vormals vorhandene Funktionen immer noch richtig arbeiten. Sind solche Tests nicht vorhanden, wird kein automatisierter Prozess, egal in welcher Technologie, wartbar und leicht anpassbar bzw. weiterentwickelbar bleiben.

Ein Geschäftsprozess könnte dabei beispielhaft wie in Abbildung 1 aussehen. Der dargestellte Prozess ist stark verkürzt, aber es ist ersichtlich, dass im Laufe der Zeit verschiedene Bezahlvarianten hinzugekommen sind, die teilweise an unterschiedlichen Stellen im Prozess ausgelöst werden. Trotz der neuen Möglichkeit der Zahlung auf Rechnung muss in der Entwicklung jedoch sichergestellt werden, dass die alten Bezahlmöglichkeiten weiterhin korrekt funktionieren.

Qualitätssicherung für ausführbare Prozesse ist auch Softwarequalitätssicherung

Im Bereich des Software Engineering (SE) beschäftigt sich ein ganzes Untergebiet mit der Qualitätssicherung von Software. Auch wenn die Prozessmodellierung oftmals nicht als Teil der klassischen Softwareentwicklung gesehen wird, so gelten doch viele Prinzipien ebenfalls in der Prozessmodellierung von ausführbaren Geschäftsprozessen. Die Qualitätssicherung unterteilt sich in drei Kategorien [2]:

• Analytische Qualitätssicherung: Durch Begutachtung der Software bzw. der Prozessmodelle sollen Fehler nach der Entwicklung gefunden werden. Hierunter fallen z.B. Tests und Reviews.
• Konstruktive Qualitätssicherung: Versucht durch geeignete Mittel bereits die Entstehung von Fehlern während der Entwicklung zu vermeiden. Hierunter fallen z.B. Coding Guidelines aber auch Test-Driven Development (TDD) [3].
• Organisatorische Qualitätssicherung: Stellt den organisatorischen Rahmen für die Entwicklung her, z.B. durch Ressourcenallokation und Planung der analytischen Qualitätssicherungsmaßnahmen.

Die konstruktive und organisatorische Qualitätssicherung sind in der Regel sehr von der Entwicklungsorganisation abhängig. Dagegen sind Verfahren der analytischen Qualitätssicherung (Reviews, Teststrategien, Testheuristiken, Testabdeckung etc.) leicht auf Geschäftsprozessautomatisierungsprojekte übertragbar.

Was heißt das für Programming in the Large?

Prinzipiell sind alle Verfahren aus der „klassischen Softwarequalitätssicherung“ auf die Entwicklung ausführbarer Geschäftsprozesse mit BPEL oder BPMN 2.0 übertragbar. In diesem Artikel wollen wir uns allerdings auf das Testen beschränken und die Besonderheiten beim Testen von ausführbaren Geschäftsprozessen beleuchten und die immanenten Eigenheiten näher beleuchten.

Zum einen sind Prozesse typischerweise langlaufend [4]. Timer und lange Timeouts sind aber schwer zu testen. So ist es z.B. schwer eine Mahnung zu testen, die nach 4 Wochen Zahlungsverzug ausgestellt werden soll. Hier muss der Prozess entweder konfigurierbar gemacht oder speziell für das Testen geändert werden. Beides bürgt die Gefahr, dass sich das Verhalten des Prozesses ändert und dadurch Fehler im Originalprozess nicht gefunden werden. Insbesondere bei manuellen Änderungen und Deployments ist dies der Fall. Um solche Fehlerquellen zu minimieren erscheint es sinnvoll Veränderungen automatisiert und während des Testens transparent für den Entwickler vorzunehmen, sodass keine Spuren im Prozess, welche durch manuelle Änderungen verursacht wurden, quasi beim „Rückbau vergessen“ werden können.

Ein weiteres Problem bei der Entwicklung und insbesondere beim Testen ist die Tatsache, dass der Prozess nur zusammen mit den ihn umgebenden Komponenten, typischerweise Webservices, funktioniert. Davon werden einige zusammen mit dem Prozess entwickelt, aber erst später fertig. Somit stellt sich das Problem, wie möglichst frühzeitig der Prozess getestet werden kann, wenn noch nicht alle einzelnen Komponenten bereit für die Testphase sind.

Hierbei kommen Mocks, d.h. simulierte Ersatzservices für den Test, zum Einsatz und stellen eine wertvolle Ergänzung dar. Dadurch, dass die Webservices über WSDL-Schnittstellen sehr gut vom Prozess entkoppelt sind, ist es leicht möglich Mocks zu schreiben und sogar zu großen Teilen zu generieren. Über die Deployment Descriptoren des Prozesses können die Endpunkte leicht für die verschiedenen Test- und Produktivumgebungen angepasst werden.

Da BPEL- und BPMN-Prozesse über maschinenlesbare Schnittstellen mit ihrer Umwelt kommunizieren, können die Tests ebenfalls einfach automatisiert werden. Dies erlaubt das häufige und effiziente Wiederholen der Tests. Insbesondere bei Fortführung des BPM-Lifecycles ist dies wichtig. Wird nun der Prozess weiterentwickelt, können die Testsuites ggf. angepasst und wieder ausgeführt werden. So ist das Re-Testing deutlich einfacher und schneller. Gerade diese erhöhte Geschwindigkeit erlaubt kürzere Release-Zyklen und dadurch die schnellere Umsetzung von Features.

Doch wie kommt man an einen guten Satz von Tests? Auch hier gibt es aus der Software-Qualitätssicherung viele Ansätze, die man auch für Geschäftsprozesse nutzen kann. So können Äquivalenzklassen [2] und Klassifikationsbäume [2] zur Strukturierung der Parameter verwendet werden und es gibt für Geschäftsprozesse ebenfalls Testabdeckungsmetriken (z.B. [5]).

Wir wollen nun kurz darauf eingehen, wie man den Prozessablauf mittels Klassifikationsbäumen strukturieren und daraus Testfälle ableiten kann. Zu diesem Zweck müssen die Stellen, an denen der Kontrollfluss verzweigt, lokalisiert und als Prozessvarianten aufgenommen werden. Insbesondere zählen zu diesen Stellen auch Schleifen, bei denen wir keinen, einen und mehrere Schleifendurchläufe als Varianten in den Baum aufnehmen. Für unseren Beispielprozess könnte ein solcher Baum wie in Abbildung 2 aussehen. Mit diesen Eigenschaften bilden wir Testfälle. Dabei verknüpfen wir verschiedene Eigenschaften miteinander zu Testfällen. Maximal ein Fehler darf in einem Testfall überprüft werden. Beispielhaft sind hier verschiedene Testfälle angegeben.

Neben Tests bieten viele Entwicklungsumgebungen auch Simulationswerkzeuge an. Diese können in der Entwicklung benutzt werden, um Prozessabläufe zu verifizieren, ersetzen aber Tests nicht vollständig. Dies liegt daran, dass für die Prozessausführung nicht nur der Prozess, sondern auch dessen Deployment Descriptor, das BPMS, das Betriebssystem, die benutzten Services und viele andere technische Komponenten benötigt werden, die wiederum Fehler beinhalten können. Diese Fehler können nur durch Tests auf einem BPMS, nicht aber in der Simulationsumgebung der Entwicklungsumgebung gefunden werden.

Tools nach Konzeption

Nachdem die Testfälle konzeptionell erstellt wurden, müssen diese automatisiert werden. Hierzu gibt es eine Reihe von verschiedenen Werkzeugen, wie z.B. soapUI (http://www.soapui.org) oder BPELUnit (www.bpelunit.net). Diese können die SOAP-Nachrichten an den Prozess schicken und stellen auch einfache Möglichkeiten zur Verfügung, Services zu simulieren. BPELUnit und Hersteller-Tools können daneben zusätzlich Prozesse transparent für den Test deployen, die Testabdeckung messen und ggf. alte Prozessinstanzen von den Testservern entfernen.

Als Teil der konstruktiven Qualitätssicherung sollten diese Tools in den Build-Prozess integriert werden. Automatisierte Builds, die den aktuellen Stand aus der Versionsverwaltung auschecken, die Testfälle ausführen und Deployments erstellen, zentrale Build-Server und Nightly Builds schaffen ein Umfeld, das auch bei der Geschäftsprozessentwicklung die Prozessdesigner unterstützt und Fehler möglichst früh sichtbar zu machen.

Prozessfluss vs. Datenfluss

Bisher haben wir uns vor allem auf den Prozessablauf konzentriert. Die Testfälle orientieren sich, egal ob aus Blackbox- oder Whitebox-Sicht, an dem Prozessfluss und testen die mit der Umwelt ausgetauschten Nachrichten. Daneben gibt es zusätzlich andere Artefakte, die von den Prozessen benutzt werden. Hier sind insbesondere Datentransformationen wie XSLT- und XQuery-Skripte zu nennen.

Für diese Skripte ist es sinnvoll eigene Unit-Tests zu schreiben, um nicht bei jeder neuen Eingabedatenkombination den gesamten Prozess ausführen zu müssen. Dabei ist es vorteilhaft, wenn die Skripte extern vom Prozess gespeichert und nicht inline definiert sind, so dass sie wie die verwendeten Services separat getestet werden können.

Für XSLT- und XQuery-Skripte empfiehlt es sich z.B. JUnit zu nehmen, welches einen XSLT-Prozessor aufruft und das Ergebnis mit einer Soll-XML-Datei vergleicht.

Was Sie mitnehmen sollten…

Dieser Artikel sollte Sie motivieren, Ihre ausführbaren Prozesse mit automatisierten Tests zu entwickeln. Wenn dies für Sie selbstverständlich ist, weil Sie Ihre Software immer mit Unit Tests zusammen entwickeln – super. Dann nutzen Sie diesen Artikel einfach, um Kollegen zu motivieren, die das Testen vergessen, nur weil der darunterliegende Prozess graphisch modelliert ist. Automatisierte Tests helfen Ihnen im fortlaufenden Lebenszyklus und der Weiterentwickelung Ihres Prozesses, agil zu bleiben und Änderungen schnell und möglichst fehlerfrei ausliefern zu können. Insbesondere bei unternehmenskritischen Kernprozessen ist dies quasi überlebenswichtig. Wir haben leider in Projekten öfters miterleben müssen, dass dies nicht konsequent gemacht wurde und die Probleme, die dann im Laufe der Zeit daraus erwachsen, miterleben und ausbaden müssen.

Referenzen