Eine Teststrategie zur unterstützenden Modernisierung von Altsystemen

Unser Kunde Edrington, das renommierte internationale Spirituosenunternehmen in Privatbesitz mit Sitz in Schottland, beauftragte Objectivity mit der Umgestaltung seines Systems zur Verwaltung von Massengut (Bulk Stock Management-System) auf der Basis der IBM I-Series-Plattform. Wir haben die Herausforderung angenommen und ein komplexes, aber sich lohnendes mehrjähriges Engagement gestartet, das auf einer bereits bestehenden strategischen Partnerschaft basierte.

Das Bulk Stock Management System (TESS) von Edrington verfolgt die Spirituosen vom Produktionsort bis zur Abfüllbereitschaft. Dieses System läuft seit 1986 und bestand ursprünglich aus über einer halben Millionen Zeilen IBM RPG III-Code. Die von diesem Altsystem verarbeiteten Daten verwalten Aktien im Wert von über 400 Mio. GBP und sind geschäftskritisch. Sie werden verwendet, um wichtige Kennzahlen für interne Stakeholder und externe Compliance-Institutionen bereitzustellen.

Die Einzigartigkeit des Geschäfts in Verbindung mit über 25 Jahren maßgeschneiderter Anpassung hatte dazu beigetragen, dass frühere Modernisierungsversuche gescheitert sind. Die Wartung und Unterstützung des Systems wurde immer schwieriger und mit verzögerten Änderungsanforderungen bestand ein erhöhtes Risiko für das Geschäft von Edrington.

Mit einem inkrementellen Ansatz war das Testen ein wichtiger Bestandteil des Modernisierungsprogramms, um sicherzustellen, dass das Bulk Stock Management-System weiterhin ordnungsgemäß funktionieren wird.

 

Die Geschäftsanforderungen

Die Herausforderung

Angesichts der Anforderung, dass das Bulk Stock Management-System während der gesamten Modernisierung aktiv bleiben und verwendet werden musste, war die Kombination von manuellen und automatisierten Tests von entscheidender Bedeutung, da schrittweise Änderungen mit dem ersten Treffer gelingen mussten.

Da der geplante Umfang der Modernisierung jedes Programm und jede Datendatei enthielt, wurde klar, um das Risiko der Masse an Code zu verringern, mussten Änderungen schrittweise bereitgestellt werden.

Bei begrenzter Systemdokumentation bestand eine der größten Herausforderungen zu Beginn darin, eine umfassende Teststrategie zu erstellen, welche die verschiedenen Geschäftsprozesse und die Übernahme des vorhandenen Systems umfasst.

Zu diesem Dilemma kam noch hinzu, dass die Geschäftsprozesse je nach Betriebsstandort unterschiedlich waren und, dass das System eine Zusammenführung von vier verschiedenen Systemen war.

Und als ob die oben genannten Herausforderungen nicht genug wären, gab es auch einen festen Lieferzeitpunkt, welcher eingehalten werden musste. Der unmittelbar bevorstehende Ruhestand der Fachexperten, die das System über viele Jahre gewartet hatten, lag uns im Nacken.

Ein Standardtestansatz würde nicht funktionieren. Wir mussten unsere Aufmerksamkeit auf die schrittweise und priorisierte Modernisierung von Programmen und den dazugehörigen Datendateien richten.

Das Design und die Implementierung des Altsystems sind teilweise so komplex - und kann während einer digitalen Transformation viele Herausforderungen verursachen. In diesem Fall wurde der Code über 25 Jahre schrittweise entwickelt, hauptsächlich durch Hinzufügen neuer Funktionen und ohne wesentliche Code-Umgestaltung oder technischen Schuldenabbau. Die bestehenden Beziehungen zwischen Systemeinheiten veranschaulichen diese Komplexität

Aufgrund der Komplexität des Systems war eine manuelle Analyse zunächst nicht möglich. Daher wurden automatisierte Systemanalysetools verwendet, um die relevanten Einheiten, ihre Wechselbeziehungen und ihre Verwendung zu identifizieren. Die Verwendung eines automatisierten Systemanalysetools war für die Bestimmung unseres Testumfangs und -ansatzes von entscheidender Bedeutung.

Prozess für Prozess mussten wir herausfinden, welches Programm unter den Screens oder Batch-Programmen ausgeführt wurde. Auf dieser Basis konnten wir Szenarien erstellen, die alle möglichen Pfade und einschließlich Randfälle abdeckten. Diese bildeten die Grundlage einer Regressionsreihe von Tests.

Bei der Ermittlung dieser Tests und der anschließenden Skripterstellung dieser Elemente, konnten wir das Risiko und die Auswirkungen der Entlassung von Fachexperten minimieren und die laufende Systemwartung und Unterstützbarkeit insgesamt verbessern.

Was wir getan haben

Die Lösung

Aufgrund des Mangels an vorhandener Systemdokumentation waren das Engagement und die enge Zusammenarbeit von Experten im Unternehmen sehr wichtig. Diese Mitarbeiter verstanden nicht nur die Geschäftsprozesse, sondern kannten auch die Nuancen der Systemnutzung, von denen sich viele entwickelt hatten. Wir haben eine regelmäßige und enge Zusammenarbeit mit diesen geschäftlichen Product Ownern aufgebaut. Ein entscheidender Punkt in den Diskussionen war es sicherzustellen, dass der Geschäftsbetrieb fortgesetzt wird, während Änderungen zur gleichen Zeit umgesetzt werden. Diese Diskussionen und die Definition von Testskripten hatten den zusätzlichen Vorteil Materialien für die Erfassung und den Wissenstransfer bereitzustellen.

Die Überprüfung und Auswahl eines automatisierten Test-Tools war von zentraler Wichtigkeit für unsere Teststrategie. Wir haben unsere Aufmerksamkeit auf die wichtigsten Anforderungen gerichtet, die dieses Tool erfüllen muss:

• Entwickelt für Qualitätssicherungsteams, Geschäftsanalysten, Geschäftsbenutzer und Entwickler, um schnelle Funktions- und Regressionstests der Benutzeroberfläche (UI) zu unterstützen.
• Die Fähigkeit, Automatisierungsskripte schnell und mit minimalem Wartungsaufwand zu erstellen. Ideal für agile Projekte, Entwicklung von Wasserfällen und auch Paket-Upgrades.
• Konfiguriert, um die Anwendungen automatisch zu erkennen und den vollständigen Inhalt jedes Bildschirms so zu erhalten, wie er angezeigt wird, ohne dass einzelne Elemente abgefragt, angeklickt oder Programmcode geschrieben werden muss;
• Sicherstellen, dass die Benutzeroberfläche weiterhin ordnungsgemäß funktioniert und nach geänderten RPG-Programmen testet.
• Automatisch alle Unterschiede zur Referenzimplementierung protokollieren.

Unser Grundprinzip war „alles zu ändern, um nichts zu verändern“. Das heißt, jede Zeile des Programmcodes sollte modernisiert und jede Datendatei aktualisiert werden. Aus Anwendersicht sollte es jedoch keine sichtbaren Änderungen an der Benutzeroberfläche geben. Daher war die Erfassung der vorhandenen Prozessabläufe und der Systeminteraktionen wichtig für die Testautomatisierung. Wir haben alle Geschäftsprozesse mit dem Testautomatisierungstool aufgezeichnet. Sobald Änderungen vorgenommen wurden und die automatisierten Regressionstests durchgeführt wurden, konnten wir uns der erwarteten Ergebnisse sicher sein. Unser Ansatz bestand darin, einen detaillierten Geschäftsprozess zu validieren und dann die detaillierten Geschäftsprozess-Tests zu kombinieren, um einen End-to-End-Geschäftsprozess (Epic) zu überprüfen. Schritt für Schritt haben wir bestätigt, dass alles ordnungsgemäß funktioniert. Wenn Abweichungen festgestellt wurden, wurden dies direkt protokolliert.

 

Die Automatisierung war entscheidend, um wiederholbare und zeitnahe End-to-End-Tests zu ermöglichen. Die letzte Testphase war das Testen der Benutzerakzeptanz. Mit Engagement während der gesamten Modernisierung wurde dies von den Geschäftsinteressenten mit Begeisterung durchgeführt. Der erfolgreich durchgeführte detaillierte Ansatz, wurde vom Unternehmen gut aufgenommen und legte die Erwartungen und den Ansatz für zukünftige Testzyklen fest.

Die Automatisierung des End-to-End-Testens von Geschäftsprozessen bestand aus einer Reihe von einzelnen Testfällen. Phase 0 des Programms lieferte genügend Testszenarien, um mit der iterativen Modernisierung des Systems zu beginnen. Diese Testszenarien galten als feste Basis und wurden während des gesamten Programms wiederverwendet. Darüber hinaus wurden sie das Rückgrat im Zusammenhang mit der laufenden Unterstützung und Wartung und Teil eines Gesamtarchivs.

Wir haben Mitarbeiter engagiert, die täglich mit der Applikation arbeitet, um Abnahmetests durchzuführen. Wir haben eine Liste der wichtigsten Funktionen (Test-Spine) erstellt, um sicherzustellen, dass die Produktionsumgebung (production environment) bei jeder Implementierung von Änderungen weiterhin funktioniert. Die Verwendung von Test-Spine und die automatisierte Regression gaben uns das Vertrauen, dass die Produktqualität sehr hoch war.

User Acceptance Testing (UAT) war ein wesentlicher Bestandteil des inkrementellen Freigabeprozesses, bei dem die Product Owner genehmigten, dass die geänderte Anwendung wie erwartet funktioniert. Die Tests wurden anhand von Testdesigns durchgeführt, die von Experten und Testern erstellt und anhand der erwarteten Ergebnisse validiert wurden.

Vor dem ersten UAT-Zyklus wurden vom Testmanager verschiedene Workshops und Einzelsitzungen mit Geschäftsinteressenten durchgeführt, um Folgendes zu erklären, zu diskutieren und zu vereinbaren:

• UAT Bedeutung
• Rolle der Business-Nutzer in der UAT-Phase
• Verantwortlichkeiten der UAT-Nutzer
• Testausführungsprozess
• Sign-off Prozess der Testergebnisse

Dieser Ansatz ermöglichte es uns, den ersten UAT-Zyklus reibungslos und mit vollem Engagement aller Stakeholder durchzuführen.

 

Nach jeder der inkrementellen Freigaben und mit ihrem detaillierten Anwendungsverständnis spielte das Qualitätssicherungsteam eine wesentliche Rolle bei der Unterstützung der Endbenutzer nach dem Go-Live. Es gab keinen Systemausfall infolge der inkrementellen Lieferungen.

Die Testausführung wurde von Geschäftsanwendern und Fachexperten abgeschlossen und von Mitgliedern des Objectivity-Testteams unterstützt. Die Rolle des Testteams, während der UAT bestand darin:

• Testexpertise bereitzustellen
• Bei der Dateneinrichtung, falls erforderlich, zu unterstützen
• zu beraten
• bei der Testausführung auf Anfrage des Delivery Managers zu helfen
• an mehreren Standorten unterstützend vor Ort zu sein (Glasgow und Destillerie)
• ein tägliches Morgen-Meeting mit UAT-Benutzern, um Status, Fortschritt und Herausforderungen zu besprechen
• UAT-Fortschritt- und Statusberichte zu erstellen
• UAT-Freigabe von den Product Ownern einzuholen

Was wir erreicht haben

Das Ergebnis

1. Das Bulk Stock System und mehrere zugehörige Applikationen basieren jetzt auf strategischen, unterstützbaren und wartbaren Technologien.
2. Test-Spine und die Skripte bieten eine tragfähige Grundlage für die kontinuierliche strategische Verbesserung und zukünftige Transformation.
3. Positives Engagement und Beziehungsaufbau sowohl geschäftlich als auch IT-technisch haben unsere strategische Partnerschaft gestärkt.
4. Die teamübergreifende Zusammenarbeit war entscheidend, damit wir erfolgreich liefern können.
5. Wir haben uns mit den beiden wichtigsten Geschäftsrisiken befasst, die sich aus der Entlassung von Fachexperten sowie der allgemeinen Unterstützbarkeit und Wartbarkeit der Plattform ergeben.
6. Der erweiterte Wissenstransfer wird an ein neues gemeinsames Produktentwicklungsteam (Edrington and Objectivity) durchgeführt.
7. Laufender Plattformwechsel aktiviert, einschließlich:
   
   7.1. Neue Regression Suite für Automatisierungstests (114 Szenarien, Tausende von Screens, die nicht wiederholt manuell ausgeführt werden können - es würde Wochen statt Stunden dauern).
   
   7.2. Neuer Konfigurations-Management-Prozess und Toolset für die gleichzeitig verteilte Entwicklung.
8. Eine fehlerfreie Migration des Bulk Stock Management-Systems auf eine neue Hardwareplattform wurde ermöglicht.
9. Trotz herausfordernder Zeitpläne und technischer Komplexität lieferte das Team erfolgreich eine kritische, betriebliche und modernisierte Applikation sowie unterstützende Anwendungen.