Reinventing Quality

ERROR: Content Element with uid "6552" and type "dce_dceuid16" has no rendering definition!

Continuous Testing im Filialbackend der Deutschen Post

Agile Ansätze in einem traditionellen Projektumfeld. Widerspruch oder Erfolgsstory?

Das Filialbackend der Deutschen Post verarbeitet alle in den Post- und Partnerfilialen, sowie Paketshops anfallenden Daten. Sie werden gesammelt, archiviert, aufbereitet und an unterschiedliche Umsysteme (andere Abteilungen im Konzern oder Partner) weitergeleitet.
Mehr als 30.000 Clients erzeugen täglich etwa 10 Millionen Datensätze, die das Backend verarbeitet.
Das Projekt ZORA kümmert sich um eine ordnungsgemäße Verarbeitung, Archivierung und Weiterleitung dieser Datenmenge.
Deutsche Post IT Services als Entwicklungsdienstleister im Konzern trägt hierbei die Verantwortung für Weiterentwicklung und Wartung der Software.
Das System wurde ab 2004 entwickelt, 2007 produktiv gesetzt und unterliegt seitdem fortwährend Veränderungen und Erweiterungen.
Jährlich werden 2-3 Major Releases mit jeweils mehr als 100 Changes erstellt.
Jedes Release stellt ein eigenes Teilprojekt dar, das nach einem posteigenen (ans V-Modell angelehnten) Vorgehensmodell arbeitet.

Wie bei vielen traditionellen Projektansätzen, zeigte sich auch hier die Problematik der späten Testobjektbereitstellung und einem damit verbundenen Aufwandspeak im Systemtest zum Ende der Realisierung.
Strategien, wie die frühe Einbindung des Testteams im Projektverlauf, gepaart mit einem hohen Grad an Automatisierung der Regressionstests stellten erste Maßnahmen dar, um dem entgegenzuwirken.
Die größte Herausforderung, die späte Bereitstellung der Testobjekte, war mit diesen Maßnahmen jedoch nicht zu meistern.
Die Ursache der späten Bereitstellung lag

  • in der späten Fertigstellung und damit späten Integration der entwickelten Artefakte und
  • in dem, aufgrund des hochkomplexen Backends, aufwändigen Deploymentverfahren.

Dieser Erfahrungsbericht stellt den im Filialbackendder Deutschen Post realisierten Ansatz zur Lösung dieser Probleme dar.
In einem an das V-Modell angelehnte Projektvorgehen traditioneller Schule wurden Ideen und Prinzipien agiler Projekte erfolgreich eingesetzt.

Das Team etablierte einen Nigthly Build und das automatische Deployment der daraus resultierenden Artefakte (ca. 100 unterschiedliche Installationspakete).
Jeden Abend werden nun automatisiert alle Änderungen des Tages kompiliert, entsprechende Installationspakete erzeugt und auf einer virtuellen Maschine installiert.
Nach der Installation laufen dann alle Unit Tests, sowie ein sogenannter Entry Check auf Systemtestebene. Der Entry Check beinhaltet derzeit 24 Testfälle, die die wichtigsten Backendprozesse prüfen und so einen ersten Fingerzeig bezüglich der Qualität des aktuellen Builds liefern.
Bei Fehlern erzeugt der Automatismus zu Analysezwecken einen Clone des aktuellen Zustands der VM.
Mittels automatisch erzeugter Mails erhalten Entwicklung, Build und Test unverzüglich Informationen über die Ergebnisse des Build und der folgenden Testläufe.
Die nächtlich erzeugte VM kann auf Knopfdruck vervielfältigt und für weitere Tests, als individueller Clone, den jeweiligen Testern in einer virtuellen Testumgebung zur Verfügung gestellt werden.
Die Clones dienen zur Durchführung von Prüfungen neuer/geänderter Funktionalitäten, Defektretests, wie auch zu Regressionstests.
Die Durchführung aller automatisierten Regressionstests (aktuell mehr als 1000 Testfälle) erfolgt aus Zeitgründen nicht automatisch für jeden Build.
Ein solcher ‚Gesamttest‘ findet während der Release-Entwicklung zweimal monatlich und obligatorisch für die finale Version statt.

Folgende agile Ansätze wurden in das traditionelle Projektvorgehen übernommen:

  • Nigthly Builds zur Sicherstellung der Code Qualität.
  • Automatische Regressionstests für jeden Build zur frühzeitigen Entdeckung von Fehlern.
  • Frühzeitige Tests zum schnellen Feedback an die Entwicklung.
  • Aufteilung in kleine Änderungen zur Vereinfachung der Fehleranalyse.
  • Tägliche Iterationen zur Reduzierung blockierter Testfälle.

Die entscheidenden Erfolgsfaktoren für eine erfolgreiche Umsetzung waren:

  • Gemeinsame Zielvorstellung von Entwicklung, Build und Test
  • Einbindung in existierende Toollandschaft (Team Foundation Server, MS Build)
  • Existierende Testautomatisierung
  • Virtuelle Testumgebung (ESX-Server)
  • Unterstützung des Managements

Der Erfolg gibt uns Recht:

  • Bereits in frühen Entwicklungsstadien stehen die ersten fertigen Artefakte zum Test zur Verfügung.
  • Unbeabsichtigte Auswirkungen von Änderungen werden frühzeitig erkannt und können ohne Zeitdruck behoben werden.
  • Die Aufwände für Fehleranalysen sind deutlich gesunken.
  • Gleichmäßigere Auslastung des Entwicklung-, Build- und Testteams
  • Automatisierter, reproduzierbarer Bereitstellungsprozess sorgt für einen Qualitätssprung.

Fazit: Agile Ansätze können, richtig eingesetzt, auch im traditionellen Projektumfeld zu deutlichen Qualitätssteigerungen führen.

Michael Kurz, Deutsche Post IT Services GmbH

Michael Kurz ist bereits mehr als 25 Jahre in den Bereichen Test, Qualitätsmanagement und Systemeinführung tätig.
Seit 15 Jahren arbeitet er als Testspezialist bei der Deutschen Post IT Services.
Als Testmanager für das Filialbackend verantwortet er den reibungslosen Test einer komplexen Backendarchitektur.
Sein besonderes Interesse gilt den Themen Testautomatisierung und Testdatenmanagement.