Interview: Qualitätssicherung und Testen in BPM-Projekten
Zusammenfassung
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. In diesem Interview diskutiert er mit Dirk Slama die wichtigsten Aspekte von Qualitätssicherung und Test-Management in BPM-Projekten.
Interview
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 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. 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), Versionskontrollsystemen (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!
Kommentar hinzufügen