THEMENSCHWERPUNKT. Qualitätssicherung und Testen in BPM-Projekten

Transkript

1

2 Inhalt Zusammenfassung... 3 Enterprise BPM... 3 Interview:... 4 Checkliste: QS-Bereiche im IBPM-Framework... 8 (0) Testplanung... 9 (1) QS Prozessmodell... 9 (2) QS Rollen & Rechte... 9 (3) QS Tasks & UI Microflows (4) QS Geschäftsregeln (5) Prozessqualität & QS Reporting (6) QS Komponentenarchitektur + Integrationstests (7) QS User Interfaces (8) + (9) Komponententests + Datenqualität (10) QS Toolchain & Infrastrukturtests Qualitätssicherung und Business Rules Management Interview: Die Business Rules-Perspektive Enterprise BPM Dirk Slama und Ralph Nelius 2

3 Zusammenfassung Die Qualitätssicherung (QS) und das Testen in BPM-Projekten unterscheiden sich in einigen Punkten stark von klassischen Anwendungsentwicklungsprojekten. Diese Aspekte werden in diesem Themenschwerpunkt herausgearbeitet. Zunächst führen wir ein Interview mit dem Experten für Qualitätssicherung und BPM, Herrn Matthias Scholze von QMethods. Anschließend präsentieren wir eine QS-Checkliste, welche auf dem IBPM-Framework aufsetzt. IBPM ist die Integrierte BPM-Projektmethodik, welche im Buch Enterprise BPM präsentiert wird. Aufgrund der hohen Relevanz und Komplexität haben wir uns entschlossen, im Kontext BPM und QS noch einmal speziell das Thema Business Rules vertiefen. Wir konnten hierzu Herrn Roland Straub von der Bosch Software Innovations GmbH als Interviewpartner gewinnen. Enterprise BPM Enterprise BPM bietet eine vollständige und in sich geschlossene Methodik zur Umsetzung von BPM auf Unternehmensebene. Es gibt dem Leser das notwendige Praxiswissen an die Hand, um einzelne BPM-Projekte effizient umzusetzen und strategische BPM-Initiativen zum Erfolg zu führen. Der Schwerpunkt des Buches liegt auf der Darstellung der»integrierten BPM-Projektmethodik«(IBPM). Mit IBPM können BPM-Projekte klar strukturiert und mit einheitlichem Vorgehen unter Anwendung von Best Practices durchgeführt werden. Weiter wird das»enterprise BPM-Framework«(EBPM) zur Einführung von BPM auf Unternehmensebene vorgestellt. Expertenmeinungen und Fallbeispiele von Firmen wie Credit Suisse, Degussa Bank, Deutsche Lufthansa AG, BAA Heathrow und Deutsche Post AG beleuchten die Umsetzung in der Praxis. Auf der Website des Buchs finden sich u.a. Dokumentvorlagen, die IBPM und EBPM unterstützen, der Pattern-Katalog sowie das BANF-Beispiel aus dem Buch in ausführlicher Form. Außerdem werden auf der Webseite regelmäßig BPM-Themenschwerpunkte wie dieser veröffentlicht. ( Enterprise BPM Dirk Slama und Ralph Nelius 3

4 Interview: Matthias Scholze ist Geschäftsführer der QMETHODS Business & IT Consulting GmbH und Experte für Qualitätssicherung mit langjähriger Erfahrung in BPM- Projekten. D. Slama: Die Integrierte BPM Projektmethodik (IBPM) hat bisher keinen Schwerpunkt auf Querschnittsaufgaben wie die Qualitätssicherung gelegt. Da stehen Ihnen als Qualitätsexperten sicherlich die Haare zu Berge? M. Scholze: Nein, das passt schon. IBPM legt ja den Fokus auf BPM-spezifisches Vorgehen im Bereich Analyse und Design. Sie postulieren ja selber, dass die Projektdurchführung auf Basis praxiserprobter Vorgehensmodelle wie beispielsweise RUP, V-Modell XT, PMI oder im agilen Umfeld z.b. SCRUM erfolgt. Und hier ist Qualitätssicherung (QS) ein existenzieller Bestandteil. Die QS stellt die Qualität des Produktes durch Validierung und Verifikation sicher z.b. durch Funktions-, Usability-, Performance- und Sicherheitstests, Dokumenten- und Code-Reviews, etc. Fehlende Qualitätssicherung stellt in einem BPM-Projekt ein genauso großes Risiko dar wie in jedem anderen Projekt. im Enterprise-Umfeld. D. Slama: Welche Konsequenzen ergeben sich aus dem Einsatz eines Business Process Management Systems (BPMS) in einem Projekt konkret für die Qualitätssicherung? M. Scholze: Nun, zunächst einmal muss man sehen, dass die BPMS-Einführung potenziell die Komplexität des IT-Gesamtsystems erhöht. Anders als bei einer klassischen monolithischen Anwendung müssen hier alle bekannten Aspekte der Qualitätssicherung in einem verteilten System berücksichtigt werden. Dank SOA sind ja heute zumindest die Schnittstellen der Komponenten in diesen Systemen klar definiert. Trotzdem muss aus Sicht der Qualitätssicherung berücksichtigt werden, dass hier getrennte Komponenten entwickelt werden, die in der Regel auch jeweils einen eigenen Lebenszyklus haben. Das erhöht die Testkomplexität signifikant. Auf der anderen Seite hat die Komponenten- bzw. SOA-orientierte Entwicklung aus der Perspektive der Qualitätssicherung ja auch den Vorteil, dass Komponenten zunächst über ihre Schnittstellen individuell getestet werden können. Das ermöglicht ein arbeitsteiliges Vorgehen und erhöht potenziell die Qualität der individuellen Komponenten schon in einer frühen Phase, was das Projektrisiko mindert und bspw. die Aufwände für den Gesamtintegrationstests reduziert. Auch die Enterprise BPM Dirk Slama und Ralph Nelius 4

5 Automatisierung von Schnittstellen-Tests auf Basis von Testwerkzeuge wie z.b. SoapUI oder HP ServiceTest kann signifikant zu einer hohen Qualität der Einzelkomponenten beitragen. D. Slama: Bietet die Verwendung von formalen Prozessmodellen Vorteile aus Sicht der Qualitätssicherung? M. Scholze: Ja, insbesondere wenn die fachlichen Prozessmodelle auch die Grundlage für die ausführbaren Prozessmodelle sind. Aus dem Prozessmodell lassen sich sehr gut die Testfälle und -ausprägungen ableiten. Denn im Prozessmodell sind ja sowohl der Happy Path als auch die zu erwartenden Ausnahmefälle formal definiert. Hier sehen wir in der Zukunft ein sehr hohes Automatisierungspotenzial, indem Testfälle und Testdaten automatisch aus den Prozessmodellen extrahiert und als Basis für ein entsprechendes Testfall-Repository verwendet werden können. Bei den Testdaten wäre sogar eine Ableitung der Äquivalenzklassen und Grenzwerte aus den in einem ausführbaren Prozessmodell hinterlegten Entscheidungspfaden möglich. D. Slama: Wie kann die Qualität der Prozessmodelle selbst sichergestellt werden? M. Scholze: Hier greift das Business Process Quality Management (BPQM), welches sich immer mehr zu einem wichtigen Steuerungswerkzeug eines System-/BPM-Architekten etabliert, vergleichbar zum Code Quality Management in der klassischen Entwicklung. Mittels BPQM wird nicht nur die semantische Richtigkeit eines Prozessmodells sichergestellt, sondern z.b. auch die Einhaltung von Konzernrichtlinien sowie technischen und formalen Anforderungen an Prozessmodelle. Durch BPQM wird dadurch ein Investitionsschutz sichergestellt und die zukünftigen Aufwände für die Weiterentwicklung minimiert. Des Weiteren können über BPM-spezifische Metriken steuerungsrelevante Information für das Management der BPM-Implementierung und - Plattform ermittelt werden. Je umfangreicher die Abbildung von Unternehmensprozessen auf Basis von BPM erfolgt, umso existentieller ist die Umsetzung von BPQM in BPM-Projekten. D. Slama: Wie sieht es allgemein mit der Unterstützung durch Testwerkzeuge für BPM-Projekte aus? M. Scholze: In erster Linie finden natürlich auch in BPM-Projekten die meisten klassischen Testwerkzeuge ihre Verwendung. Das beinhaltet zum einen etablierte Werkzeuge für das Testmanagement, die Testautomation und das Fehlermanagement. Einige BPM Systeme bieten heute außerdem selber Unterstützung zur Ausführung von Unit- und Regressionstests innerhalb der Engine, wie z.b. die inubit Suite. Dieses unterscheidet sich allerdings noch stark zwischen den BPM-Produktherstellern. Auf Grund der in BPM-Umgebungen häufig stark verteilten und heterogenen Systemlandschaften ist der Bereich Application Performance Management ein weiterer entscheidender Punkt. Wer wünscht sich hier nicht ein architekturlayer- und plattformübergreifendes Profiling. Ausgereifte Lösungen für das Java- und.net-umfeld bieten hier bspw. Enterprise BPM Dirk Slama und Ralph Nelius 5

6 dynatrace oder CA Wily an. Wenn das BPMS auf einer Standard-Architektur aufsetzt, dann können diese Lösungen hier hilfreich sein. Allerdings werden sie nicht helfen, BPM-spezifische Probleme zu analysieren, die sich beispielsweise auf die Performance unterschiedlicher Prozesse in der BPM-Engine beziehen. Gerade bei XML-basierten Process Engines ist dieses ein wichtiger Aspekt, da hier das Fine-Tuning der Server-Ressourcen kritisch sein kann. Ein letztes wichtiges Thema ist der ganze Bereich der Testautomatisierung. Hier haben wir klassische Capture & Replay Automation über die Anwendungsoberfläche, die gerade in BPM-Projekten mit einem starken Anteil an Benutzerinteraktion sehr wichtig ist. Speziell für BPM-Projekte sei hier noch einmal auf die Bedeutung der Automation von Tests über die technischen Schnittstellen, wie Webservices oder JMS verwiesen, die auf Grund der hohen Integrationsdichte im BPM- Umfeld unabdingbar ist. D. Slama: Automatisierte UI-Tests sind wichtig, um die Funktionalität des Systems sicherzustellen. Aus Sicht des Usability Engineerings stehen solche Aspekte aber eher am Schluss der Entwicklung. Was ist hier im Kontext BPM zu beachten? M. Scholze: Usability ist natürlich ein wichtiger Qualitätsaspekt, der nicht nachträglich in ein System hineingetestet werden kann. Im Kontext BPM gelten natürlich zunächst auch alle Aspekte des Usability Engineerings, die in normalen Projekten Anwendung finden. Ein wichtiger zusätzlicher Aspekt ist die Frage nach dem Grad der Führung des Nutzers durch den Prozess. Viele BPM-Projekte tendieren hier dazu, die Nutzerführung zu strikt prozessgeführt zu gestalten. Die meisten BPM-Systeme bieten Task-Mechanismen an, über welche rollenbasiert Aufgaben verteilt werden können. Für Nutzer, die nur sekundär in Prozesse eingebunden sind, ist es auch OK, wenn diese über Aufgaben geführt werden. Aber gerade für Nutzer, die einen Hauptteil ihrer Arbeit im Kontext eines Prozesses verrichten, kann ein zu stark Task-orientierte Herangehensweise kontraproduktiv sein. Diese Nutzer beschäftigen sich ja sowieso täglich mit den aktiven Prozessinstanzen, und möchten dieses eher nach Status und anderen Aspekten filtern und sortieren, um dann selber zu entscheiden, welche Aktivitäten sie als nächstes durchführen wollen. Ein weiteres, häufig unterschätztes Thema sind Microflows in Tasks bzw. Aufgaben. Die meisten BPMS arbeiten ja sehr Formularbasiert. Gerade mehrstufige Arbeitsschritte lassen sich nicht immer ideal über einfache Formularfolgen abbilden. Hier bieten sich z.b. klassische Wizard- Konzepte an. Generell sollte man die Formular-Mechanismen des BPMS nicht übermäßig strapazieren. Sie ersetzen selten ein vollwertiges Framework zur UI-Entwicklung. D. Slama: Gerade die iterative Optimierung im UI-Bereich setzt häufig einen effizienten Prozess für Continuous Integration (CI) voraus. Was ist bei CI im Kontext BPM zu beachten? M. Scholze: Im klassischen Programmierumfeld z.b. Java sind ja heute CI-Werkzeuge wie beispielsweise Hudson stark verbreitet. Diese fungieren quasi als Orchestrator, um das Zusammenspiel von Compilern, Build-Werkzeugen (z.b. Make, Ant oder Maven), Versionskontrollsys- Enterprise BPM Dirk Slama und Ralph Nelius 6

7 temen (z.b. Subversion, CVS) und Test-Frameworks (z.b. JUnit oder Selenium) zu koordinieren. Leider lassen sich viele BPM-Werkzeuge nicht besonders gut in dieses Umfeld integrieren. Jedoch ist dies ein wichtiges Kriterium für den Einsatz von BPM im Enterprise-Umfeld und sollte bei einer BPM-Evaluation unbedingt berücksichtigt werden. Hier spielt insbesondere die Scripting-Fähigkeit des BPMS eine wichtige Rolle, d.h. die Einbindung in Automatisierungsskripte über ein Command Line Interface (CLI). Ein weiteres, häufig auftretendes Problem beim Einsatz eines BPMS ist die Integration von bestehenden Repositories. Auch wenn das BPMS seine Diagramme als normale Dateien ablegt, die in einem zentralen Repository verwaltet und versioniert werden können, führt das BPMS intern häufig ein Eigenleben, indem es z.b. intern eigene Versionsmechanismen realisiert. Dann besteht die Aufgabe darin, die unterschiedlichen Versionen, die innerhalb der Modellwelt und der Repository-Welt existieren, in Einklang zu bringen. Natürlich gibt es heute auch SOA/BPM-spezifische Repositories wie z.b. Centrasite, aber diese sind selten ein Ersatz für die etablierten Repositories, welche als Grundlage des Konfigurationsmanagements in der klassischen Programmierwelt existieren. Natürlich kann man hier auch komplett komponentenorientiert vorgehen, und die beiden Welten getrennt nebeneinander existieren lassen. Dieses funktioniert ja auch, wenn man beispielsweise ein separates Konfigurationsmanagement für bspw. Java- und Cobol -Komponenten hat. Dann ist es aber umso wichtiger, dass man zumindest auf übergreifender Ebene die Schnittstellen zwischen diesen getrennten Welten durch Einsatz eines SOA-Repositories in den Griff bekommt. Dieser Ansatz setzt natürlich eine Enge Koordination dieser bewusst getrennten Welten auf Managementebene voraus. Die unterschiedlichen Entwicklungsgeschwindigkeiten, die normalerweise in diesen Welten existieren, stellen dann natürlich ein weiteres Problem dar. Aber hier kann man natürlich sehr gut auf die benannten Werkzeuge für Schnittstellentests und simulation zugreifen. Natürlich müssen die hier entstehenden Testdaten und Simulatoren auch wiederum in den CI-Mechanismus mit integriert werden, d.h. sie müssen versioniert sein und für die jeweils benötigte Testkonfiguration automatisch ausgecheckt und bereitgestellt werden können. Hier bietet eine saubere Service- Architektur viel Flexibilität und Möglichkeiten zur Unterstützung der Qualitätssicherung im Kontext BPM. D. Slama: Herr Scholze, wir bedanken uns für Ihre Zeit! Enterprise BPM Dirk Slama und Ralph Nelius 7

8 Checkliste: QS-Bereiche im IBPM-Framework IBPM (die Integrierte BPM Projektmethodik) ist darauf ausgelegt, im Kontext etablierter IT- Projektvorgehensmodelle angewendet zu werden. IBPM konzentriert sich darauf, die BPMspezifischen Aspekte insbesondere während der Analyse- und Designphasen zu strukturieren. Es wird angenommen, dass Querschnittsaufgaben wie die Qualitätssicherung (QS) in den etablierten Projektvorgehensmodellen (RUP, V-Modell, SCRUM, etc.) adressiert werden. Allerdings eignet sich das IBPM-Framework natürlich sehr gut, auch aus der QS-Perspektive die BPMspezifischen Aspekte zu identifizieren. In der folgenden Grafik sind diese QS-Bereiche (0-10) über das IBPM-Framework (Säulen A-J bzw. Phasen 1-5) gelegt worden. Auf der linken Seite sind die typischen Verantwortlichkeiten aufgezeigt: Die Entwicklung (Dev.) und die Qualitätssicherung (QS) bereiten gemeinsam den Testplan (0) sowie das Test-Design vor. In der Umsetzung ist zumeist die Entwicklung selber gefordert, um auf Komponenten-Ebene zu testen. Die Integrationstests und weitergehende Systemtests werden wiederum mit Unterstützung von QS durchgeführt. Im Folgenden betrachten wir kurz jeden einzelnen der QS-Bereiche im IBPM- Kontext. Abbildung 1: QS-Bereiche im IBPM-Framework Enterprise BPM Dirk Slama und Ralph Nelius 8

9 (0) Testplanung Die Testplanung umfasst normalerweise die Festlegung der Testinhalte und des Testvorgehens, die Struktur der Testdokumentation, eine Zeitplanung einschließlich Prüfaufwand je Testfall, eine Schätzung des Gesamtprüfaufwandes, die Festlegung der Testverantwortlichen, sowie die Festlegung von Entscheidungskriterien. Außerdem muss eine Planung für den Aufbau der Testumgebung erfolgen. Erfolgt die Testplanung im Kontext von IBPM, dann kann sie sehr gut gemäß der folgenden 10, an den IBPM-Säulen orientierten QS-Bereichen aufgebaut sein. Einige Bereiche der Testplanung werden erst dann im Detail planbar sein, wenn zumindest das Grobdesign feststeht. Beispielweise werden sich die Komponententests an der SOA Komponentenarchitektur orientieren. (1) QS Prozessmodell Die Qualitätssicherung der Prozessmodelle (häufig auch in Kombination mit der QS von Organisationsmodellen) umfasst: Prüfung auf fachliche Richtigkeit Prüfung auf Einhaltung von Modellierungsstandards (allgemeine Unternehmensstandards für die Prozessmodellierung, formale Kriterien, Verwendung und Einhaltung von BPMN Profilen, Einhaltung der IBPM-Empfehlungen für Verwendung von BPMN- Elementen in den 5 IBPM-Phasen, etc.) Prüfung auf richtige Verwendung von Modellierungspatterns (Sicherstellung der Wiederverwendung auf Modellebene) Ableitung von detaillierten Whitebox-Tests für die Prozesskomponente (siehe 8) (2) QS Rollen & Rechte Die Qualitätssicherung im Kontext der Prozessorganisation umfasst neben der QS der Organisationsmodelle häufig folgende Aspekte: Definition von Testfällen zum Testen von Rollenwechseln im Prozessverlauf. Hierzu müssen häufig recht komplexe und realitätsnahe Szenarien entworfen werden, welche mögliche Rollenwechsel in einem Prozess adressieren. Die Berücksichtigung von Rollenwechseln im Testverlauf kann die Testaufwände signifikant erhöhen, ist aber natürlich zwingend notwendig. Enterprise BPM Dirk Slama und Ralph Nelius 9

10 Ein weiterer wichtiger Punkt ist das Testen von rollenbasierten Berechtigungen im Prozesskontext. Die rollengerechte Prüfung von Zugriffsrechte für Stamm- und Bewegungsdaten kann wiederum recht aufwändig sein. Hier muss einerseits sichergestellt werden, dass die notwendigen Informationen für jede Rolle bereitstehen, und andererseits natürlich im Umkehrschluss jede Rolle nur so viel Zugriff erhält wie geplant. Aus funktionaler Sicht bietet es sich an, Rollen & Rechte-spezifische Tests als UI-Tests auszulegen und ggf. zu automatisieren. Aus der Sicherheitsperspektive wird dieses nicht ausreichen: Hier muss sichergestellt werden, dass keine unrechtmäßigen Zugriffe am UI vorbei möglich sind (z.b. über APIs oder Protokolle wie http). Ein weiterer Aspekt ist das Testen der Administrations-Tools zur Verwaltung von Rechten und Rollen. (3) QS Tasks & UI Microflows Das Testen der Task-Funktionalitäten hat zunächst starke Bezüge zum Testen der Rollen und Rechte-Konzepte, da Tasks ja häufig rollenbasiert vergeben werden. Ein weitere Aspekt sind hier Tasks, welche komplexe Microflows beinhalten. Während die Prozessmodelle aus der IBPM-Säule A meistens eher grobgranulare Tasks definieren (häufig ein Task je Rollenwechsel), kann es durchaus sein, dass in einem einzelnen Task ein durchaus komplexer Microflow enthalten ist. Ein Beispiel wäre ein Task Produktauswahl, welcher häufig mehrere Zwischenabfragen beinhaltet, über welche die spezifischen Merkmale des ausgewählten Produktes abgefragt werden. Ein solcher Microflow ist nicht zwangsweise im Prozessmodell enthalten, sondern kann z.b. klassisch als UI-Komponente ausprogrammiert werden. In diesem Fall muss die Qualitätssicherung sicherstellen, dass dieser komplexe Task ausreichend qualitätsgesichert wird, beispielsweise über einen dedizierten UI-Test. (4) QS Geschäftsregeln Der Einsatz von Geschäftsregeln in einem BPM-Projekt bringt viele fachliche Vorteile, kann aber auch die Komplexität der Qualitätssicherung noch einmal signifikant erhöhen. Wird ein dediziertes BRMS (Business Rules Management System) eingesetzt, können ggf. Test- und Simulationsfeatures des BRMS zur Qualitätssicherung eingesetzt werden. Folgende Aspekte müssen auf jeden Fall beachtet werden. Whitebox-Testen der Geschäftsregeln: Enterprise BPM Dirk Slama und Ralph Nelius 10

11 o Die fachliche Richtigkeit und Vollständigkeit der Regeln muss sichergestellt werden. o Die fachliche Richtigkeit der Wissensbasis, auf welcher die Regeln aufsetzen, muss geprüft werden (Konfigurationstabellen etc.). o Für variable Parameter, welche ggf. in Regeln ausgewertet werden, müssen entsprechende Testdaten bereitgestellt werden. Testen der Auswirkungen von Regel-Aufrufen auf das Gesamtsystem: o Die Auswirkungen der Regeln auf den Prozessfluss müssen getestet werden. o Werden Regeln außerhalb des expliziten Prozessflusses aufgerufen z.b. aus einem UI-Microflow müssen die Auswirkungen dieser Aufrufe ebenfalls getestet werden Business Rule Change Management: o Häufig soll der Einsatz von Geschäftsregeln eine schnellere Anpassung des Systemverhaltens ermöglichen. Idealerweise sollten diese Anpassungen direkt durch die Fachbereiche erfolgen können. Da dadurch aber die klassischen IT- Qualitätssicherungsmechanismen ausgehebelt werden, müssen hier neue QSund Freigabemechanismen geschaffen werden. (5) Prozessqualität & QS Reporting Die Qualitätssicherung der Prozessanalyse muss sicherstellen, dass die vom Projekt erstellen Reports auch tatsächlich den Ergebnissen der Prozessausführung entsprechen. Gerade wenn die Prozessanalyse umfangreiche BAM-Features (Business Activity Monitoring) enthält, können die Testszenarien sehr umfangreich werden, da ja in der Regel komplexe Szenarien über einen längeren Zeitraum durchgespielt werden müssen. Hier ist der gründliche Abgleich zw. den eingespielten Testdaten und den Analyseergebnissen sehr wichtig. Idealerweise kommt hier ein Testdatengenerator zum Einsatz, welcher einerseits größere Prozessvolumen mit fachlich sinnvollen Testdaten generieren kann, und der außerdem Aussagen über die zu erwartenden Analyseergebnisse bereits vor der Testdurchführung machen kann, damit Vergleichsdaten zur Verfügung stehen (z.b. für einen Abgleich zw. der im Test-Tool eingestellten durchschnittlichen Durchlaufdauer vs. den im Report angezeigten Zeiten). Außerdem muss QS schon in einer frühen Phase sicherstellen, dass im Prozess-Reporting auch tatsächlich alle KPIs enthalten sind, welche für die Sicherstellung der Prozessqualität selber wichtig sind. Wurde zum Beispiel für einen Schadensregulierungsprozess als Qualitätsmerkmal Enterprise BPM Dirk Slama und Ralph Nelius 11

12 definiert, dass eine Kundenrückmeldung immer in höchstens drei Tagen erfolgen soll, dann muss die Einhaltung dieses Qualitätsmerkmals natürlich auch als KPI im Prozess-Reporting enthalten sein. (6) QS Komponentenarchitektur + Integrationstests Die Säule F des IBPM-Frameworks beschäftigt sich mit dem übergreifenden, SOA-basierten Komponentendesign des BPM-Systems. Hier muss QS auf zwei Ebenen mit involviert sein: Zum Ersten muss die Qualität der Komponentenarchitektur selber bewertet werden. Beispielsweise kann QS hier die Einhaltung der SOA-Architekturregeln (SOA-Schichtung, Aufrufbeziehungen, Schnittstellendesign, Kopplungsarchitektur) und, sofern vorhanden, der Vorgaben aus einer Zielarchitektur mit überwachen Zum Zweiten kann QS aus dem Komponentenmodell natürlich direkt die durchzuführenden Komponententests ableiten, sowie die Strategie für die Integrationstests. (7) QS User Interfaces Die Qualitätssicherung im Bereich der User Interfaces ist heute ein gut dokumentiertes Thema, welches von rein funktionalen Tests bis hin zu Usability Reviews reicht. Hier stehen meistens diverse Werkzeuge zur Automatisierung der Oberflächentests zur Verfügung, welche natürlich auch in einem BPM-Projekt zum Einsatz kommen können. Als Besonderheiten, welche im Kontext eines BPM-Projektes berücksichtig werden müssen, sei hier auf die Themen Rollenwechsel (siehe Punkt 2) und das Testen von Task-Microflows hingewiesen (siehe Punkt 3). (8) + (9) Komponententests + Datenqualität Für die SOA-basierten Backend-Komponenten in einem BPM-Projekt bieten sich natürlich sowohl Black-Box Tests (also Tests gegen die Schnittstellen der Komponenten) als auch White- Box Tests an (also Tests, welche im Wissen über die interne Struktur der Komponenten durchgeführt werden, und die darauf abzielen, einen möglichst hohen Abdeckungsgrad der Implementierung zu erreichen). In einem IBPM-basierten Prozess wird klar zwischen Frontends bzw. UIs, Prozesskomponente und Backend-Komponenten unterschieden. Frontends werden im Rahmen der QS der User Interfaces getestet (siehe Punkt 7). Enterprise BPM Dirk Slama und Ralph Nelius 12

13 Die Prozesskomponente sollte im Rahmen der Komponententests zunächst eigenständig getestet werden. Bietet sie eine Schnittstelle zum UI an, welche als API explizit zugänglich ist, dann sollten neben der UI-basierten Tests auch automatisierte Tests gegen diese Schnittstellen gefahren werden. Als Grundlage für die Unit-Tests der Prozesskomponente können zum einen das Prozessmodell und zum anderen eine formale Zustandsübergangsmatrix dienen. Aus beiden Modellen lassen sich Testfälle erzeugen, welche - zumindest theoretisch - eine vollständige Abdeckung aller Pfade und Verzweigungen im Prozessablauf ermöglichen. Idealerweise werden die Testfälle nicht manuell erzeugt, sondern aus dem Prozessmodell werden gültige Testclients generiert, welche komplexe Testszenarien für die Prozesskomponente Automatisieren. Die Testfälle sollten auch BPM-spezifische Besonderheiten wie beispielsweise Task-Timeouts, Task- Eskalationen, Fehlaufrufe, etc. abdecken. Nach hinten hin greift die Prozesskomponente auf Backend-Services zu. In der Komponenten- Testphase sollten diese Backend-Services aus Sicht der Prozesskomponente simuliert werden, um hier die Abhängigkeiten zw. den verschiedenen Entwicklungssträngen zu minimieren. Hierfür gibt es heute Tools wie z.b. SoapUI oder HP ServiceTest. Auch für das individuelle Testen der Backend-Services selber bieten sich solche Tools an, da über sie natürlich auch die Prozesskomponente simuliert werden kann. Ein wichtiger Aspekt beim Testen der Backend-Komponenten ist neben den funktionalen Tests auch die Sicherstellung der Datenqualität, gerade bei datenzentrischen Services. Enterprise BPM Dirk Slama und Ralph Nelius 13

14 Abbildung 2: SOA Map für unterschiedliche Testszenarien Die Abbildung 2 zeigt eine SOA Map mit unterschiedlichen Testszenarien, welche auf Service Mock-Ups und Service-Simulatoren und UI-Robotern basieren. Beispielsweise wird für den Unit- Test 2 zum einen ein UI-Testroboter eingesetzt, um das UI automatisiert zu testen. Die Prozesskomponente wird sowohl über das UI automatisiert getestet, als auch über einen Service- Simulator, welche Aufrufe der Prozesskomponente simuliert. Dieser kann z.b. aus dem Prozessmodell generiert werden. Im Backend steht ein Service Mock-Up bereit, welcher die benötige Schnittstelle implementiert und entsprechende Testdaten zurückgibt. Enterprise BPM Dirk Slama und Ralph Nelius 14

15 (10) QS Toolchain & Infrastrukturtests In der Säule E J des IBPM Frameworks siedeln sich zum Schluss zwei drei weitere QS-Themen an: Die QS-Infrastruktur sowie, die Durchführung von InfrastrukturtestsSystemtests, sowie die Prüfung sicherheitsrelevanter Aspekte. Die QS-Infrastruktur benötigt zunächst eine QS-Toolchain, welche von den Tools für das Anforderungsmanagement und der Verwaltung der Testfälle bis hin zu den Tools für die Testautomatisierung reicht. In einem BPM-Projekt müssen hier häufig bestehende Tools wie z.b. UI Testroboter für die UI-Testautomatisierung mit neuen, BPM-spezifischen Tools kombiniert werden. Beispielsweise kann ein Testszenario so aussehen, dass ein UI-Testroboter gegen das UI läuft, welches gegen die BPM Engine läuft, welche wiederum Services aufruft, die von einem Service- Simulationstool wie z.b. SoapUI bereitgestellt werden, solange die wirklichen Backend-Services nicht verfügbar sind. Ein weiterer wichtiger Teil der QS-Infrastruktur ist die Bereitstellung der Testumgebung selber, inklusive der Bereitstellung von Mock-Ups, Service-Simulatoren und konkreter Testdaten, welche dann auf der QS-Toolchain aufbauen. Neben den in den Punkten 1-9 beschriebenen, eher funktionalen Test bedarf es natürlich auch weiterer Tests der Gesamtarchitektur, um die Skalierbarkeit des Systems sicherzustellen. Diese Systemtests sollten alle Tests beinhalten, welche sich mit Last-Tests, Simulation von mehreren gleichzeitigen Nutzern, Sicherheit, Recovery, etc. beschäftigen. Vieles hiervon sind wiederum Standard-Tests, insbesondere wenn das BPMS auf einem Standard-Container aufsetzt. Allerdings gibt es auch hier BPM-spezifische Besonderheiten zu beachten. Beispielsweise kann das Thema Recovery von langlaufenden Prozessen schwierig zu testen sein und bedarf besonderer Beachtung. Schließlich sollte untersucht werden, ob alle Anforderungen und Vorschriften zum Thema Sicherheit beachtet wurden. Zu prüfen sind die allgemeinen Unternehmensrichtlinien, zusätzliche lösungsspezifische Anforderungen und die Beachtung von Grundprinzipien der Sicherheit in verteilten Systemen. Enterprise BPM Dirk Slama und Ralph Nelius 15

16 Qualitätssicherung und Business Rules Management Im Buch Enterprise BPM haben wir im Kapitel Business Rules das Zusammenspiel von BPM und BRM (Business Rules Management) bereits ausführlich beleuchtet. Wichtig war uns hier insbesondere das Thema Trennung von Prozessfluss und Entscheidungslogik, da diese eine wichtige Voraussetzung zur Erreichung von Zielen wie Erhöhung der Agilität, Einbindung der Fachbereiche, Automatisierung von Entscheidungen, Verbesserung der Wartbarkeit und Wiederverwendung ist. Auf die Vor- und Nachteile einer dichten Integration zw. BPM und BRM sind wir insbesondere in dem Interview mit Daniel Steiner von Pegasystems eingegangen (Pegasystems ist ein Vertreter der dichten Integration von BPM und BRM in einer Engine). Als Verfechter von BPM und SOA gehen wir an dieser Stelle eher von einer losen Kopplung zw. BPM und BRM aus, wie sie in Abb. 1 aus dem Buch noch einmal zusammengefasst ist. Abb. 1: Einordnung des BRMS in die SOA Eine Prozesskomponente kann danach einen Service im BRMS aufrufen (z.b. als Webservice), um eine Regel auszuwerten. Der Regelservice im BRMS agiert ggf. als Orchestrierungsservice, Enterprise BPM Dirk Slama und Ralph Nelius 16

17 der wiederum Services aufruft, z.b. um auf weitere Regeldefinitionen oder auf Datenservices zuzugreifen (diese Datenservices können natürlich auch außerhalb des BRMS liegen). Wie wir bereits in der QS-Checkliste oben dargestellt haben, bietet es sich in einer SOA an, das Testen einzelner Komponenten durch den Einsatz von Service-Simulatoren und Mock-Ups zu unterstützen. Welche weitergehenden Möglichkeiten ein BRMS in einer SOA zur Unterstützung der Qualitätssicherung in einer SOA ein BRMS anbieten kann, diskutieren wir im folgenden Interview. Interview: Die Business Rules-Perspektive Roland Straub ist Senior Solution Manager für BRM bei der Bosch Software Innovations GmbH. R. Nelius: Welche Auswirkungen hat die Einführung von BRM in einem BPM-Projekt auf die Gesamt-Teststrategie? Kann die Rules Engine als Ausführungseinheit der Geschäftslogik aus Perspektive des zu testenden Prozesses als Black-Box betrachtet werden? R. Straub: Die Auswirkungen können sehr vielschichtig sein und sich u.a. auf technischer, organisatorischer und auf der Qualitätsebene erstrecken. Werden die von der Rules Engine im Rahmen des Tests zu verarbeitenden Daten vom Prozess geliefert (auch als End-2-End Testansatz zu verstehen), kann die Rules Engine aus Perspektive des Prozesses tatsächlich als Black-Box verstanden werden. Hierbei arbeitet sie klassischerweise zustandslos: Von der Process Engine angelieferte Eingabedaten werden von der Rules Engine verarbeitet und die Regelergebnisse wieder an die Process Engine zurückgeliefert. Somit lassen sich die Regeln mit den aus dem Prozess zur Verfügung gestellten Daten einfach mittesten. Einige Aspekte sind hierbei zu beachten: Prozess- und Regelversionen sind zu synchronisieren und unterliegen oftmals unterschiedlichen Lebenszyklen und unterschiedlicher Änderungshäufigkeit. Die Verwaltung und Einbindung der richtigen Regelversion muss sichergestellt sein. Enterprise BPM Dirk Slama und Ralph Nelius 17

18 Nicht immer möchte man jedoch alle Bewegungsdaten im Prozess halten, nur um sie an die Rules Engine zur Verarbeitung weiterzugeben. Es kann Sinn machen, dass die Rules Engine anhand der vom Prozess übergebenen Schlüsseldaten selbst weitere Daten etwa aus Datenbanken oder von Umsystemen bezieht. Dies erfolgt u.a. aus Performanzerwägungen, hat aber den Nachteil, dass sich Schnittstellen zu den Umsystemen dann auch in den Regeln befinden. Die Rules Engine arbeitet dann nicht mehr zustandsfrei, sondern zustandsbehaftet. Dies ist im Ablauf des Tests zu berücksichtigen. BRMS bieten darüberhinaus eine umfangreiche Testunterstützung zum Whitebox- Testen. Das BRMS kann zudem als Simulator bzw. Mock-Up Implementierung der Geschäftslogik dienen, die sie als Service bereitstellt. D. Slama: Erhöht die Kombination von BPMS und BRMS nicht exponentiell die Test- Komplexität? R. Straub: Ziel der BRMS-Integration sollte ganz klar sein, die Testkomplexität zu reduzieren. Dies wird alleine schon dadurch erreicht, dass die Prozessdarstellung übersichtlicher wird, wenn die Details der Geschäftslogik aus dem Prozess herausgelöst und unter die Hoheit eines BRMS gestellt werden. Die Geschäftslogik kann durch die vom BRMS gelieferten Möglichkeiten zum Whitebox-Testen erst einmal unabhängig vom Prozess qualitätsgesichert werden. Erst im Rahmen eines End-2-End Tests wird die Rules Engine dann aus der Process Engine aufgerufen und das Zusammenspiel getestet. Die kombinatorische Anzahl an Testfällen auf Prozessebene reduziert sich analog dazu. D. Slama: Was ist, wenn nicht nur das BPMS das BRMS aufruft, sondern das BRMS wiederum über externe Service-Aufrufe den Prozess beeinflusst? R. Straub: Dies sollte man nach Möglichkeit vermeiden, da es die Gesamtarchitektur des Systems betrifft und damit die Wartbarkeit der Schnittstellen, sowie die Orchestrierbarkeit, Skalierbarkeit und Performanz des Systems. Als sauberes Architekturkonzept bietet es sich an, die Regeln als Regelservices auf der Prozessebene genauso wie alle anderen Services zu orchestrieren. Die Koordination des Gesamtablaufes erfolgt somit auf oberster Prozessebene und nicht verborgen innerhalb der Geschäftslogik. Dies erhöht deutlich die Transparenz des Gesamtsystems. Es gibt jedoch Ausnahmen, wenn, wie bereits erwähnt, nicht alle Bewegungsdaten im Prozess gehalten werden sollen, sondern die Regeln sich selbst Daten besorgen. Insbesondere, wenn Enterprise BPM Dirk Slama und Ralph Nelius 18

19 der Datenzugriff komplexen Regeln unterliegt und wenn er aus Kostengründen (etwa auf externe Auskunfteien) minimiert werden soll, bietet sich ein regelbasierter Datenzugriff an. Hierbei sollte man jedoch nach Möglichkeit nur lesende Zugriffe vornehmen und schreibende Zugriffe nur durch dedizierte Services auf Prozessebene erfolgen lassen. Dies reduziert die notwendige Einflussnahme auf den Prozess erheblich. R. Nelius: Wie sieht eine Test-Strategie spezifisch für den BRM-Teil aus? Was muss beachtet werden? Gibt es spezifische Strategien für das Whitebox-Testen von Regeln? R. Straub: Da BRMS darauf ausgelegt sind, auch mit einer großen Anzahl komplexer Regeln umzugehen, bieten sie umfangreiche Funktionalität für die Testunterstützung. Generell wird das Unit Testing unterstützt, wobei die Testfälle (bestehend aus Eingabedaten und erwarteten Referenzergebnissen) den Regeln zugeordnet werden und beim Testen aufgetretene Abweichungen zwischen Ist und Soll kenntlich gemacht werden: Abb. 2: Unit Testing im BRMS am Beispiel Visual Rules Zur genaueren Analyse der Testausführung innerhalb des BRMS dient eine schrittweise Regelausführung, die bisweilen auch ein grafisches Debugging mit Anzeige der pro Regelschritt veränderten Datengrundlage ermöglicht (Abb. 3) Enterprise BPM Dirk Slama und Ralph Nelius 19

20 Abb. 3: Grafisches Debuggen im BRMS am Beispiel Visual Rules Des Weiteren ermitteln BRMS auch Metriken (etwa die Testabdeckung) oder ermöglichen eine komplette Testautomatisierung mit Bezug externer Daten und Reporting der Testergebnisse. Während des Testens aufgezeichnete Ausführungsstatistiken erlauben ein nachgelagertes Monitoring der Regelausführung sowie ein Profiling, bei dem die Ausführungszeiten einzelner Regelpfade ausgewertet werden können. Damit lassen sich die ausgeführten Regelpfade verdeutlichen und nachvollziehen (Abb. 4). Enterprise BPM Dirk Slama und Ralph Nelius 20

21 Abb. 4: Monitoring der Regelausführung am Beispiel Visual Rules Zuletzt bieten BRMS auch formale semantische Überprüfungen von Regelausdrücken an, wie etwa die Erkennung doppelter oder überlappender Regelausdrücke sowie lückenhafter Bereichsabdeckungen in Entscheidungstabellen. Enterprise BPM Dirk Slama und Ralph Nelius 21

22 D. Slama: Kann Regelsimulation bei der Erreichung eines hohen Testabdeckungsgrads helfen? Kann man überhaupt eine hundertprozentige Abdeckung aller Kombinationsmöglichkeiten erreichen? Ist das erstrebenswert? R. Straub: Unter Regelsimulation ist die automatische Verarbeitung großer Datenbestände zu verstehen; oftmals wird hier mit einem Abzug der produktiven Datenbestände gearbeitet. Dadurch kann man sehen, wie sich das Regelwerk insgesamt verhält, wenn alle praktisch auftretenden Datenkombinationen durchlaufen werden. Hierbei kann ein BRMS auch die Testabdeckung messen und reporten. Solche Simulationsläufe überprüfen jedoch nicht automatisch die Richtigkeit der Regelergebnisse. Hierzu müsste eine Sammlung erwarteter Referenzergebnisse existieren, die man jedoch oft nur manuell fallbasiert bereitstellen kann. Nicht immer lässt sich eine hundertprozentige Abdeckung aller Kombinationsmöglichkeiten erreichen. Die effizienteste Vorgehensweise ist, bestimmte Regeln gezielt feingranular zu testen. Werden die Regeln, die von übergeordneter Ebene aufgerufen werden, schon einmal für sich feingranular mit hoher bis voller Testabdeckung getestet, dann reichen für die übergeordneten Regeln oftmals wenige Testfälle, um den Gesamtregelablauf zu testen: Abb. 5: Test des Gesamtregelablaufs am Beispiel Visual Rules Darüber hinaus werden oft Testabdeckungsgrade definiert, die über alle Regeln hinweg mindestens zu erreichen sind. Diese betragen meist weniger als 100%. R. Nelius: Welche Tools sollte ein BRMS für ein effizientes Testmanagement mitbringen? Wie sieht das Zusammenspiel eines BRMS mit Standard-Testtools aus (z.b. QualityCenter)? R. Straub: BRMS sollten nicht nur die Möglichkeit bieten, Testfälle zu definieren, sondern auch über ein Regelspezifisches Testfallmanagement verfügen. Ein solches ermöglicht es, Testfälle als Tests zusammenzufassen und zu verwalten, wie etwa in hierarchische Test Suites, die weitere Test Suites und Tests einbinden können. Entlang dieser hierarchischen Organisation kön- Enterprise BPM Dirk Slama und Ralph Nelius 22

23 nen die Tests auf beliebiger Hierarchiestufe in ein Testmanagement-Tool eingebunden und somit auch außerhalb des BRMS ausgeführt werden. Dies ist eine wichtige Funktion, möchte man z.b. vor der Bereitstellung und dem Deployment neuer Regelversionen im Rahmen eines automatisierten Gesamttests die Konsistenz der Regelbasis sicherstellen. Abb. 6: Testfallmanagement am Beispiel Visual Rules R. Nelius: Was muss ein effizienter Rule-Governance-Prozess beachten? R. Straub: Der Rule-Governance-Prozess muss den vollen Lebenszyklus der Geschäftslogik berücksichtigen. Hierzu gehören: Regelanforderungsdefinition, Regeldokumentation, Regelmodellierung, Testen, Testdokumentation, Regelverwaltung/Versionierung, Regelfreigabe, Festlegung von Gültigkeitszeiträumen, Regeldeployment, Regelausführung und Regelmonitoring. Folglich muss das BRM, wenn Regeln in Unternehmensanwendungen eingesetzt werden sollen, unbedingt eine Toolunterstützung des gesamten Rule-Governance Prozesses liefern. Governance zielt hierbei insbesondere auf die Synchronisierung zwischen Prozess- und Regelversion ab. Hierfür bietet das BRMS entsprechende Unterstützung auf den Ebenen der Regelerstellung, -verwaltung und -ausführung an. R. Nelius: Gerade wenn Business Rules vom Fachbereich verändert werden können sollen, kann es unserer Erfahrung nach kritisch werden. Häufig nehmen die Fachbereiche an, dass die IT als Teil der Projektumsetzung auch eine Qualitätssicherung mit durchführt. In dem Moment, wo der Fachbereich ohne die IT Systemänderungen durchführen kann, entfällt diese Qualitätssicherung durch die IT und der Fachbereich müsste eigentlich eine eigene Qualitätssicherung aufbauen. Wir das so stringent gehandhabt in Ihrer Erfahrung? Enterprise BPM Dirk Slama und Ralph Nelius 23