Suche

Qualitätssicherung: Check!

Check 3: Tasks und UI Microflows

Das Testen der Task-Funktionalitäten hat zunächst starke Bezüge zum Testen der Rollen und Rechtekonzepte, da Tasks ja häufig rollenbasiert vergeben werden. Ein weiterer Aspekt sind hier Tasks, die 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“, der häufig mehrere Zwischenabfragen beinhaltet, über die die spezifischen Merkmale des ausgewählten Produktes abgefragt werden. Ein solcher Microflow ist nicht zwangsweise im Prozessmodell enthalten, sondern kann zum Beispiel 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.

Check 4: 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 Business Rules Management System (BRMS) eingesetzt, können ggf. Test- und Simulationsfeatures des BRMS zur Qualitätssicherung eingesetzt werden [4]. Folgende Aspekte müssen auf jeden Fall beachtet werden: White-Box-Testen der Geschäftsregeln:

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

Testen der Auswirkungen von Regelaufrufen 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.
Check 5: Prozess-Monitoring, Reporting und Prozessqualität

Das Prozess-Monitoring für verteilte Systeme ist eine komplexe Aufgabe, die bei unterschiedlichen Verantwortlichkeiten für die einzelnen Systeme nicht selten Gefahr läuft, stiefmütterlich behandelt zu werden. Die Qualitätssicherung muss daher darauf achten, dass die Anforderungen hierfür (KPIs, Inhalte, Messpunkte) rechtzeitig spezifiziert und in Anwendungen und Infrastruktur berücksichtigt werden, bspw. durch den Einsatz eines zentralen Monitoring-Servers, die Definition eines gemeinsamen Nachrichtenformates und die Unterstützung der verwendeten Monitoring-Anschlüsse durch die eingesetzten Komponenten [5]. QS muss außerdem sicherstellen, dass die vom Projekt erstellten Reports auch tatsächlich den Ergebnissen der Prozessausführung entsprechen. Gerade wenn die Prozessanalyse umfangreiche Business-Activity-Monitoring-Features (BAM ) 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 zwischen den eingespielten Testdaten und den Analyseergebnissen sehr wichtig. Idealerweise kommt hier ein Testdatengenerator zum Einsatz, der 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 zwischen der im Testtool eingestellten, durchschnittlichen Durchlaufdauer gegenüber den im Report angezeigten Zeiten). Schließlich muss QS schon in einer frühen Phase darauf hinwirken, dass im Prozess-Reporting auch tatsächlich alle KPIs enthalten sind, die 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.

Kommentare

Schreibe einen Kommentar

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