Erfahrungsbericht Testdatenmanagement Bei Ablösung alter Applikationen Testdaten aus unterschiedlichen Quellen verwalten Version : 1.00 Autor: Koch, Jörg QIQ Qcentris Intelligent Quality GmbH Geschäftsführer Volksbank Raiffeisenbank Niederschlesien eg Berliner Straße 60 Reto Züst BLZ 85591000 D-02826 Görlitz Peter Weber Konto 4530152109 Mail: infode@qcentris.com Amtsgericht Dresden IBAN DE21855910004530152109 Internet: www.qcentris.com HRB 91629 BIC GENODEF1GR1 USt.-IdNr. DE 279276630
Einführung Bei bestehenden IT-Systemen, die sich bereits im produktiven Einsatz befinden, kann man in der Regel nach einer Weile auf einen repräsentativen Datenbestand zugreifen. Bei zukünftigen Releases dieser IT-Systeme stellen solche Datenbestände einen Mehrwert für die Qualitätssicherung der Softwareentwicklung dar, denn um diese Daten für Softwaretests zu nutzen, bedarf es oft nur noch eine (eventuell rechtlich erforderliche) Anonymisierung der Daten. Doch wie kann man bei der Erzeugung von Testdaten vorgehen, wenn bestehende Applikationen in die Jahre gekommen sind und durch neue Applikationen ersetzt werden sollen, die jedoch andere Datenbank-Architekturen verwenden? Ein Erfahrungsbericht. Ausgangssituation Ein älteres CRM-System sollte gegen ein CRM-System neuester Generation abgelöst werden. Zwei weitere Umsysteme waren für die Verwaltung von bestimmten zusätzlichen Kundeninformationen zuständig. Eine Middleware verknüpfte die Daten der unterschiedlichen Systeme miteinander zu einzelnen Datensätzen. Dies geschah über sogenannte Beziehungen. Das alte CRM-System beinhaltete eine Stammdatenverwaltung für Kontakt- und Adressdaten, worauf auch die beiden Umsysteme zugriffen. Das neue CRM-System enthielt solch eine Stammdatenverwaltung nicht mehr. In Zukunft sollte ein zusätzliches Umsystem die Stammdaten verwalten. CRM alt Stamm daten Middleware Umsystem 1 Umsystem 2 Abbildung 1: Ist-Zustand der Systemlandschaft Erfahrungsbericht Testdatenmanagement 17.09.2015 Seite 2
Die Datenbankarchitekturen des alten und des neuen CRM-Systems waren unterschiedlich. Somit war eine Datenmigration erforderlich. Zudem mussten wir die Stammdaten aus dem alten CRM-System extrahieren, weil zukünftig ein eigens dafür eingerichtetes Umsystem diese Stammdaten verwaltete. CRM neu Middleware Umsystem 1 Stammdaten Umsystem 2 Abbildung 2: Geplanter Umbau der Systemlandschaft Zum Zeitpunkt der Softwareentwicklung der neuen Systeme existierte die neue Systemlandschaft (Abbildung 2) und die neue Datenarchitektur nur auf den Entwicklungs- und en. Auf der Produktionsumgebung befand sich noch die alte Struktur (Abbildung 1) Somit war es nicht möglich, über einen einfachen Kopiervorgang die Produktivdaten auf die zu transportieren. Lösungsansätze In einem Mini-Workshop ergaben sich 2 Lösungsansätze: Variante 1: Entwicklung eines Testdatengenerators, der in der Lage ist, entsprechende Datensätze je nach gewünschter Ausprägung zu erzeugen. Variante 2: Einrichtung einer weiteren Systemumgebung, auf der wir die Produktionsdaten in die neue Datenbankstruktur überführen. Erfahrungsbericht Testdatenmanagement 17.09.2015 Seite 3
Entscheidung Wir entschieden uns aus folgenden Gründen für den Lösungsansatz der zweiten Variante: Spätestens zum Go-Live mussten wir alle Daten über die entsprechenden Migrationen zusammenführen. Dieses Vorgehen konnten wir nun bereits im Vorfeld erproben. Wir setzten bereits ein Werkzeug ein, womit wir über entsprechende Suchabfragen (Queries) spezielle Datensätze selektieren konnten, die es dann einzeln von der Produktionsumgebung auf eine beliebige weitere Systemumgebung kopierte. Dies hatte besonders bei der zukünftigen Softwarewartung den Vorteil, dass wir nicht den gesamten Datenbestand von mehreren Terabytes kopieren mussten. Nun entstanden bereits während der Softwareentwicklung neue Queries für die neue Datenbankstruktur, die wir dann direkt nach Go-Live für die Softwarewartung nutzen konnten. Ein weiterer positiver Aspekt dieses Werkzeugs war, dass wir optional beim Kopiervorgang speziell definierte Anonymisierungen vornehmen konnten. Mit einem Datenmaster im read-only-modus hatten wir automatisch ein Backup der Testdaten. Damit waren wir in der Lage, nach jeder Testdurchführung wieder einen definierten Datenzustand auf der jeweiligen herzustellen. Umsetzung Auf einem separat eingerichteten Datenmaster führten wir die Daten im ersten Schritt zusammen. Im zweiten Schritt konnten wir nach erfolgter Selektion durch Queries die entsprechenden Datensätze auf die jeweiligen en verteilen (siehe Abbildung 3). Datenquellen Migration Stammdaten Migration CRM Umsystem 1 Umsystem 2 Datenmaster (read-only) Entwicklungsumgebung Systemtest Abnahmetest Performancetest Abbildung 3: Zusammenführen der Daten Erfahrungsbericht Testdatenmanagement 17.09.2015 Seite 4
Ergebnisse Es war die richtige Entscheidung, den zweiten Lösungsansatz für die Umsetzung zu wählen. Wir identifizierten in unserem Vorgehen diverse Schwachstellen, die wir für den Go-Live erfolgreich optimieren konnten: Beim ersten Anlauf zur Erstellung des Datenmasters gab es viele Stellen, an denen es zuerst noch hakte. Die Ursachen waren oft nur technische Kleinigkeiten und schnell behoben. Hätten wir diese Fehler jedoch beim Go-Live beheben müssen, hätte dies unnötig Stress verursacht. Nun waren wir aber gut vorbereitet und der Go-Live lief somit weitestgehend routiniert ab. Im Rahmen des Softwareentwicklungsprojektes mussten wir auch spezielle tägliche, wöchentliche und monatliche Jobs (fachlicher Art) anpassen, die die Vertragsdaten im CRM-System scannten und gegebenenfalls modifizierten. Auf der dedizierten Performancetestumgebung hatten wir nun einen repräsentativen Datenbestand und konnten eine zuverlässige Aussage über die Durchlaufzeiten dieser Jobs treffen. Die geplanten Tests der Migrationsdaten konnten wir mit den System- und Abnahmetests kombinieren. Damit reduzierte sich der Gesamtaufwand. Wir hatten eine ziemlich genaue Vorstellung davon, welche Zeit die einzelnen Arbeitsschritte für den GoLive beanspruchten. Somit konnten wir bei der Planung auf relativ zuverlässige Erfahrungswerte zugreifen. Bestimmte technische Tätigkeiten konnten wir beim Go-Live parallel ausführen, ohne dass die Performance des Gesamtsystems zusammengebrach. Dies hatten wir bereits im Vorfeld beim Aufbau des Datenmasters evaluieren können. Anfangs gingen wir davon aus, dass sich die einzelnen Entwicklungs- und Migrationsteams beim Aufbau des Datenmasters gut untereinander abstimmen könnten. Ab dem Zeitpunkt, wo wir auch die Applikationsmanager mit in den Aufbau einbezogen, gab es jedoch erhöhten Abstimmungsbedarf. Somit trafen wir die wichtige Entscheidung, einen dedizierten Testdatenmanager zur Koordination einzusetzen. Im späteren Verlauf des Projektes war er auch zuständig für die Anforderungen der einzelnen Systemumgebungseigner (System Environment Owner) bezüglich der Testdaten und koordinierte die Erstellung der Queries. Fazit Testdatenmanagement ist kein Luxus oder Spielerei sondern kann mit professionellem und an das Projekt angepasstem Aufgaben und Maßnahmen maßgeblich zum Erfolg des Projektes beitragen. Darüber hinaus kann es die zukünftige Qualitätssicherung im laufenden Betrieb und der Phase der Pflege/Wartung auf ein tragfähiges Testdatenfundament stellen!... Der Autor Jörg Koch ist Senior Berater für Softwarequalitätssicherung bei QIQ Qcentris Intelligent Quality AG und hat vielfältige Projekterfahrungen gesammelt, u.a. im Testdatenmanagement. QIQ QCENTRIS steht ihren Kunden als unabhängiges, führendes europäisches Beratungs- und Serviceunternehmen mit branchenübergreifendem Know-how in allen Belangen der Bereiche Quality, IT- Change Management und Testing zur Seite. Das Unternehmen beschäftigt Test-, Qualitäts- und IT-Change Experten in der Schweiz, Österreich, Deutschland und Ägypten. Erfahrungsbericht Testdatenmanagement 17.09.2015 Seite 5