Software nach Fahrplan

Der Autor ist freier Publizist in München. Der Beitrag entstand in Zusammenarbeit mit Beck et al. Das «Shared Service Center Logistik», in dem die IT der Zürcher Kantonalbank beheimatet ist, bearbeitet in vier grossen Software-Entwicklungsbereichen (ERP, CRM, Kernbanken- und Handelssystem) pro Jahr rund 120 grössere Change-Projekte und über 400 kleinere. Weil bis vor Kurzem ein geordneter Release-Prozess und eine Integ­ra­tionstestumgebung in der Entwicklungszone fehlte und deshalb nur unzureichende Verbundtests durchgeführt wurden, kam es immer wieder zu Qualitätsproblemen, die oft erst beseitigt werden konnten, wenn eine neue oder geänderte Software bereits in Produktion gegangen war. Das machte den Entwicklungs- und Testprozess zeitaufwendig und fehlerhaft. Nachdem eine neutrale Studie diese Ineffizienzen nachgewiesen hatte, gab die Geschäftsführung der Zürcher Kantonalbank grünes Licht für den Aufbau eines neuen «Service Center Testings». Ziel war eine höhere Software-Qualität und – wenn möglich – kürzere Einführungszeiten.

«Sie können sich den Prozess vorstellen wie einen Bus, der bestimmte Haltestellen nach einem festen Fahrplan ansteuert. Projekte, die nicht pünktlich an der Haltestelle stehen, müssen einfach auf den nächsten Bus warten», erläutert Klara Isler, die als Leiterin Logistik, Informatik, Service Transition bei der Zürcher Kantonalbank die Neuordnung des Change-, Test- und Deployment-Prozesses verantwortete. Der neue Prozess ist in fünf Stationen strukturiert: Initiierung, Definition, Realisierung, Gewährleistung und Betrieb. Dazwischen liegen sechs sogenannte «Quality Gates», in denen geprüft wird, ob alle notwendigen Schritte einer Phase in hinreichender Qualität vollzogen sind. Erst wenn diese grünes Licht geben, darf das jeweilige Software-Projekt in die nächste Phase starten. Dabei hat das Quality Gate «Freigabe Integrationstest» (QG 3) eine besondere Bedeutung. Ab hier muss die eigentliche Entwicklungs­arbeit an allen Projekten abgeschlossen sein, die zu einem vorgesehenen Release-Wochenende produktiv gehen sollen. Denn sollte das nicht der Fall sein, sind keine Integrationstests möglich, und damit auch keine Fehlerbeseitigung, Abnahmetests und Produktionsfreigabe. Die Integrationstests dauern inklusive Fehlerbeseitigung sechs Wochen, für die Abnahmetests sind in der Regel drei Wochen angesetzt. Zwischen Integrations- und eigentlichem Abnahmetest liegt noch eine Einführungsprobe, die sicherstellen soll, dass die geplante Einführungszeit ausreicht. Nach dem Abnahmetest und vor dem Release-Wochenende haben die Testdesigner eine Reservewoche eingeplant, damit auch Unvorhergesehenes und Last-Minute-Reparaturen durchgeführt werden können.

Natürlich fährt nicht nur ein Bus. Die Zürcher Kantonalbank hat für 2012 vier Release-Wochenenden und zusätzliche acht Release-Tage für kleinere Changes vorgesehen. Ab 2013 sind fünf Release-Wochenenden geplant. Eine Sonderrolle spielt das Handelssystem, bei dem die Geschwindigkeit, mit der Neuerungen eingeführt werden können, eine hohe Priorität hat. Deshalb fährt der Handelsbus die Haltestellen Initiierung bis Betrieb jede Woche ab. Die anderen Projekte haben in der Regel längere Durchfahrtszeiten. Lesen Sie auf der nächsten Seite: Testdurchsatz erhöht

Vor seiner Neudefinition lief der Entwicklungs- und Release-Prozess bei der Zürcher Kantonalbank deutlich ungeordneter ab. «Um noch einmal auf das Bild des Busses zurückzukommen, das war ungefähr so, als wenn jeder mit einem Kart statt mit dem Bus fährt, und dann noch auf Routen, die er selbst gewählt hat und mit einer meistens sehr regelwidrigen Motorisierung», verdeutlicht Isler. «Man kann sich leicht vorstellen, wie wenige pünktlich ins Ziel kamen. Die meisten fuhren viel zu spät und ziemlich ramponiert durch», meint Isler schmunzelnd. Schliesslich starteten die Software-Projekte früher zu beliebigen Zeiten, feste Release-Zyklen und -Termine gab es genauso wenig wie gemeinsame Integrationstests. Jedes Change-Projekt musste individuell behandelt werden, was zu etlichen Schleifen und Verzögerungen bei der Einführung führte. Auch die neu ein­gesetzten Tools zur Testautomatisierung beschleunigten das eigentliche Testen enorm. «Allein die Tagesendverarbeitung bewerkstelligen wir jetzt in 30 Stunden statt in fünf Tagen», berichtet Isler stolz. «So können wir innerhalb einer Testwoche zwei Online-Tage, zwei BatchTage und einen Tag für Fehlerbeseitigung einplanen. Das erhöht den Takt erheblich.»

Bei der Definition und Implementierung des neuen Prozesses liess sich die Zürcher Kantonalbank vom Münchener IT-Service-Dienstleister Beck et al Services (BeaS), der auch eine Niederlassung in Zürich unterhält, unterstützen. Gerry Wallner, Director Business Service Management Consulting bei BeaS entwickelte die neuen Abläufe gemeinsam mit einem kleinen Team auf Basis einer Ist-Analyse der Prozesse. «Es war gar nicht so einfach, die unterschiedlichen Interessengruppen in der Bank unter einen Hut zu bringen», erzählt er. «Aber wir sind hervorragend vom Management der Bank unterstützt worden und ich bin froh, dass ich meine Erfahrungen im Design von Serviceprozessen einbringen konnte.» Am stärksten involviert ist Islers 20-köpfige Qualitätsmanagement- und -testtruppe natur­gemäss in den Phasen Definition, Entwicklung, Defectmode und Abnahmetest. Insgesamt beschäftigt die Zürcher Kantonalbank in der Abteilung Service Integration 78 interne und rund 20 externe Mitarbeiter. Zur Abteilung gehören vier Testcenter, das Competence Center Testdaten, das Release- und Deployment-Team inklusive der Quality-Gate-Manager sowie die Abteilung Testumgebungen. Schon während der genauen Definition des Projekts, in dem das Projektpflichtenheft erstellt wird, beginnt die Testplanung. «Damit stellen wir sicher, dass wir von Anfang an mit im Boot sind und so Fehler und Unzulänglichkeiten möglichst früh beseitigt werden», erklärt Klara Isler. Denn «alle wissen, dass Fehlerbeseitigung umso teurer wird, je später Fehler im Entwicklungsprozess gefunden werden». Danach schliessen sich Testanalyse, Testentwurf sowie -durchführung und -auswertung an. Während des Rollouts, in der Gewährleistungsphase, werden die Testaktivitäten abgeschlossen. Lesen Sie auf der nächsten Seite: Feuerprobe bestanden

Nach der ersten Feuerprobe im Mai fällt Islers Fazit durchweg positiv aus: «Das Release-Wochenende verlief optimal. Wir hatten keine Ablauf- oder Qualitätsprobleme.» Obwohl noch keine ausreichenden Alltagserfahrungen mit dem neuen Prozess vorliegen, ist die Testchefin sehr optimistisch: «Wir können jetzt schon von deutlich gestiegener Qualität und Transparenz sprechen. Uns liegen zwar noch keine genauen Messwerte für die Testeffektivität vor, aber ich bin mir sicher, dass wir auch deutlich Zeit und Kosten sparen werden.» Allerdings sei das immer ein Nebenaspekt gewesen: «Uns ging es in erster Linie um mehr Qualität und die haben wir jetzt schon erreicht.» Damit das Projekt auch langfristig erfolgreich ist, betont sie, wie wichtig es sei, den Prozess lebendig zu halten: «Wenn wir die Regeln nicht leben, sind wir sehr schnell wieder beim alten Zustand.»

Das Testcenter

Das neue Service Center Testing ist Dreh- und Angelpunkt zwischen Entwicklern, Testmanagern und Testern. Dazu zählen: Service Integration: 4 Testmanager, ausgerichtet auf die Business-Portfolios Vertrieb, Banksteuerung, Handel und Support-Prozesse. Testdaten: Anonymisierung der produktiven Daten für den Integrationstest, auf Wunsch synthetische Testdaten­erstellung, Testautomatisierung (Tosca). Release und Deployment: Das Team ist für Releases/Auslieferung zuständig und schliesst die Quality-Gate-Manager mit ein. Testumgebungen: Batch-Bau, Datenübernahmen und Testbetrieb (morgend­liche Smoketests, Onlinefreigabe, BatchVerarbeitungen). Ressourcen - Der gesamte Bereich besteht aus 78 internen und ca. 20 ext. Mitarbeitenden. - In den Testcentern sind ca. 20 Test­manager beschäftigt, die in den Projekten eingesetzt werden. Tools - HP Quality Center - Tosca Testsuite des österreichischen Herstellers Tricentis Technology & Consulting zur Testautomatisierung