QS-Checkliste

Checkliste: QS-Bereiche im IBPM-Framework

Im Folgenden betrachten wir kurz jeden einzelnen der QS-Bereiche im IBPM-Kontext.

(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.
• 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ür-lich 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:

• Die fachliche Richtigkeit und Vollständigkeit der Regeln muss sichergestellt werden.
• Die fachliche Richtigkeit der Wissensbasis, auf welcher die Regeln aufsetzen, muss geprüft werden (Konfigurationstabellen etc.).
• Für variable Parameter, welche ggf. in Regeln ausgewertet werden, müssen ent-sprechende Testdaten bereitgestellt werden.

Testen der Auswirkungen von Regel-Aufrufen auf das Gesamtsystem:

• Die Auswirkungen der Regeln auf den Prozessfluss müssen getestet werden.
• 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:

• 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 QS- und 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 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

(10) QS Toolchain & Infrastrukturtests

In der Säule E J des IBPM Frameworks siedeln sich zum Schluss weitere QS-Themen an: Die QS-Infrastruktur,  die Durchführung von Systemtests 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.