Qualitätssicherung: Check!

Check 8 und 9: Komponententests und 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, die 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, Prozesskomponenten und Backend-Komponenten unterschieden. Frontends werden im Rahmen der QS der User Interfaces getestet (siehe Check 7). Die Prozesskomponente sollte im Rahmen der Komponententests zunächst eigenständig getestet werden. Bietet sie eine Schnittstelle zum UI an, die als API explizit zugänglich ist, dann sollten neben den 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, die 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, die 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“ 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 zwischenn den verschiedenen Entwicklungssträngen zu minimieren. Hierfür gibt es heute Tools, wie zum Beispiel SoapUI oder HP ServiceTest. Auch für das individuelle Testen der eigentlichen Backend-Services 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. Auch hier gilt die allgemeine Regel, dass die Testdaten so aufgebaut sein sollten, dass man jederzeit in der Lage ist, das System in definierte Zustände zu versetzen.

Check 10: QS Toolchain und nichtfunktionale Tests

In der Säule J des IBPM-Frameworks siedeln sich zum Schluss einige weitere QS-Themen an: Die QS-Infrastruktur sowie die Durchführung von nichtfunktionalen Tests inklusive der Prüfung sicherheitsrelevanter Aspekte. Die QS-Infrastruktur benötigt zunächst eine QS Toolchain, die 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, zum Beispiel 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, das gegen die BPM Engine läuft, die wiederum Services aufruft, die von einem Servicesimulations-Tool wie SoapUI bereitgestellt werden, solange die wirklichen Backend-Services nicht verfügbar sind. Ein weiterer wichtiger Teil der QS-Infrastruktur ist die Bereitstellung der Testumgebung, inklusive der Bereitstellung von Mock-ups, Servicesimulatoren und konkreter Testdaten, die dann auf der QS Toolchain aufbauen. Neben den in den Checkpunkten 1 bis 9 beschriebenen, eher funktionalen Tests, bedarf es natürlich auch weiterer Tests der Gesamtarchitektur um die Skalierbarkeit des Systems sicherzustellen. Diese Systemtests sollten alle Tests beinhalten, die sich mit Lasttests, Simulation von mehreren gleichzeitigen Nutzern, Sicherheit, Recovery etc. beschäftigen. Viele hiervon sind wiederum Standardtests, insbesondere wenn das BPMS auf einem Standardcontainer aufsetzt. Allerdings gibt es auch hier BPM-spezifische Besonderheiten zu beachten: Beispielsweise kann das Thema Recovery von lang laufenden 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.

Fazit

Wir haben gesehen, welche neuartige fachliche und technische Komplexität ein BPM-Projekt mit sich bringt. Diesen Herausforderungen muss sich auch die QS stellen. Die Praxis zeigt, dass klassische (Silo-)Testansätze bei BPM-Projekten nicht mehr funktionieren werden. So hilft BPM mit SOA zwar die Komplexität über Schnittstellen und Arbeitsteilung in den Griff zu kriegen. Aber: Das zeit- und ressourceneffiziente Testen der Schnittstellen setzt eine hinreichende Testautomatisierung und Mock-ups voraus. Sind diese nicht vorhanden, muss hierfür erst einiges an Aufbauarbeit geleistet werden. Und: Die erforderliche Arbeitsteilung beim Integrieren und Testen von verteilten Anwendungen setzt ein hohes Maß an bereichsübergreifender Zusammenarbeit voraus. Ist diese im Projektumfeld noch nicht hinreichend eingeübt, entstehen unweigerlich Reibungsverluste, mit denen man rechnen sollte. Derartige Aspekte sollten daher bereits in der Planung des BPM-Projektes identifiziert und berücksichtigt werden. Wenn man etwas Neues macht oder zum ersten Mal baut, ist auch die QS dafür aufwändiger und teuerer. Richtig gemacht sind dadurch aber die Risiken im aktuellen Projekt und spätere Aufwände für QS in Folgereleases wesentlich geringer. IBPM und die daraus abgeleitete QS-Checkliste helfen dabei, indem sie die wesentlichen Aspekte eines BPM-Projektes strukturieren und für die QS handhabbar machen.

Dirk Slama ist Produktmanager und Methodikverantwortlicher bei der inubit AG (Bosch Group). Er ist Koautor der Bücher „Enterprise BPM“ und „Enterprise SOA“.

Ralph Nelius ist IT-Unternehmensarchitekt bei der Deutschen Post AG. Er ist Koautor des Buchs „Enterprise BPM“.

Kommentare

Schreibe einen Kommentar

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