Mit agilen Prinzipien große Integrationstests einfach managen

Im traditionellen Ablauf großer ERP-Einführungsprojekte stehen nach dem Konzept und der Entwicklung die großen Integrations- und Abnahmetests an. In einem aktuellen Projekt, das ich als Teil eines Consulting-Teams betreue, wird ein Teil des Einführungsprojekts (genauer gesagt ein Teilprojekt) mit Hilfe von Scrum abgewickelt. An der Integrationstestphase ist somit nicht zu rütteln und das wollen wir auch gar nicht. Diese Phase dient in erster Linie dazu, alle Geschäftsprozesse teilprojektübergreifend durch die Fachexperten testen zu lassen.
Fakt ist: In Großprojekten sind diese Testphasen immer ein hoher organisatorischer und logistischer Aufwand. Alleine in unserem Teilprojekt müssen rund 50 Tester mehrere hundert Testfälle durchführen. Auch basieren die zu testenden Geschäftsprozesse nicht immer zwingend auf Customizing und Entwicklung unseres Teilprojekts. Das bedeutet, dass auch die Qualität der Abstimmung zu anderen Teilprojekten überprüft wird. Ein weiterer Stolperstein ist die Verantwortung der involvierten Fachbereiche: Ein Geschäftsprozess umfasst oft mehr als zehn Schritte mit mindestens fünf verschiedenen Verantwortlichkeiten. Diese Handover müssen im Test berücksichtigt werden – jeder Fachbereich nimmt nur seinen verantworteten Teil des Geschäftsprozesses ab. Stellen wir uns diese Schritte anhand eines Beispiels vor (jede Abteilung prüft nur ihren verantworteten Teilprozess):
Business Case „Tausch eines Haushaltgerätes beim Kunden“

  1. Abteilung A erstellt den Auftrag zum Tausch.
  2. Abteilung B weist den Auftrag einer der regionalen Einheiten zu.
  3. In der regionalen Einheit C gibt es Arbeitsvorbereiter, die den Auftrag einem Monteur zuweisen.
  4. Ein Monteur der regionalen Einheit C wickelt den Auftrag mit einer mobilen App ab.
  5. Abteilung D kontrolliert, ob die regionale Einheit eine Gutschrift für den Auftrag erhalten hat.
  6. Abteilung E kontrolliert, ob die Rechnung an den Kunden ordnungsgemäß automatisch versandt wurde.

Um es zusammenzufassen: Integrationstests im ERP-Großprojekt sind eine wahre Herausforderung! Um dieser Herausforderung zu begegnen, haben wir versucht, den Test gemeinsam mit dem Kunden für unser Teilprojekt nach den agilen Werten und Prinzipien auszurichten. Dazu haben wir drei Initiativen gestartet und umgesetzt:
1) Prozess- und Schnittanalyse
In einem ersten Schritt wurden die Geschäftsprozesse identifiziert, für die das Teilprojekt verantwortlich ist. In einem zweiten Schritt wurden die Prozesse priorisiert, um sie nach ihrer Wichtigkeit im Test abzuarbeiten. Um uns einen Überblick über die Verantwortlichkeiten im Prozess (und somit auch in der Abnahme) zu verschaffen, wurden alle Prozesse in kleinere Prozessschritte heruntergebrochen. Einen Schnitt machten wir immer dann, wenn die Verantwortlichkeiten wechselt. So konnten wir auf einen Blick sehen, wie viele Handover für den spezifischen Geschäftsprozess notwendig sind. Um uns die Abstimmungen zu erleichtern, wurden auch noch all jene Prozessschritte gekennzeichnet, in denen die Verantwortlichkeit in ein anderes Teilprojekt übergeht. Schließlich vermerkten wir noch die für den Schritt benötigten externen Systeme, um deren Verfügbarkeit zu gegebenem Zeitpunkt sicherstellen zu können.
ERP_1
2) Simulation des Prozessablaufes
Um die Handover während der Tests so einfach wie möglich zu gestalten, wurde in den Testräumlichkeiten mit einem großen Taskboard gearbeitet. Jedem Testfall wurde zu Beginn des Tests eine Karteikarte zugeordnet, die mit der eindeutigen ID des Testfalls gekennzeichnet war. Auf diesen Karten wurden alle wichtigen Informationen (Auftragsnummer, etc.) notiert. Sobald der erste Schritt durch den ersten Fachbereich erfolgreich erledigt war, wurde die Karteikarte in die Queue des nachfolgenden Fachbereichs am Taskboard gehängt. So konnte jeder Fachbereichstester schnell feststellen, welche Aufgaben gerade für seinen Bereich auf die Durchführung warteten. Sobald der zweite Fachbereich den zweiten Schritt erfolgreich erledigt hatte, wanderte die Karte in die dritte Queue. War ein Übergang in ein anderes Teilprojekt notwendig, hatten wir auch dafür eine eigene Spalte vorgesehen. Dieses physische Board und seine beweglichen Karteikarten halfen den Testern, auch bei vielen parallel stattfindenden Tests den Überblick zu behalten und sich auf die Fertigstellung der wartenden Testfälle zu konzentrieren.
ERP_2
 
3) Möglichst kurze Intervalle im Deming Cycle
Um den aktuellen Stand, die Befindlichkeiten, Probleme und Wünsche der Tester zu erheben, wurde zwei Mal täglich ein Daily durchgeführt. Es diente einerseits dem gegenseitigen Austausch und der Information über aktuelle Probleme und andererseits der Identifizierung geeigneter Maßnahmen, um Bottlenecks zu entlasten; das waren Fachbereiche, deren Queue vor Karteikarten überquoll.
Mit diesen drei Initiativen gelang es uns, den Test trotz des enormen Umfangs übersichtlich zu gestalten und kontinuierliche Fortschritte zu erzielen. Interessant ist dabei der Fakt, dass immer sogenannte Testkoordinatoren die Aufgabe hatten, die Tests zu organisieren. Im Wesentlichen sollen diese Koordinatoren den reibungslosen Ablauf des Tests sicherstellen. Dazu gehören Organisations- und Moderationstalent, um die Kommunikation zwischen allen Beteiligten sicherzustellen. Aus meiner Sicht kann der Testkoordinator durchaus als ScrumMaster der Tests bezeichnet werden.
Also, liebe ScrumMaster: Lasst euch durch Titel wie den Testkoordinator nicht irritieren – Tests können auf tolle und effiziente Weise mit agilen Werten, Prinzipien und Artefakten sehr erfolgreich verlaufen.
 
Tipp: Scrum und ERP passen zusammen! Worauf Sie dabei achten sollten, erfahren Sie im zweitägigen Introduction Training “Scrum in ERP-Projekten”. Nächster Termin am 11.8.2015 in Wien – hier können Sie sich anmelden.
 

Geschrieben von

bgloger-redakteur bgloger-redakteur

TEILE DIESEN BEITRAG

Schreibe einen Kommentar

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