Teststrategie beim Redevelopment — Risikominimierung im SCHUFA-Projekt

80 HMD 257

Jens Borchers, Dieter Steinbauer

Teststrategie beim Redevelopment – Risikominimierung im SCHUFA-Projekt

Mit der Gründung der SCHUFA Holding AG imJahr 2001 entstand auch der Bedarf, das Anfangder siebziger Jahre entwickelte Auskunftei-Kern-system durch eine zukunftsorientierte und denaktuellen Gegebenheiten des Marktes angepass-te Lösung zu ersetzen. Da das bisher verwendeteSystem zu 100% Mainfame-basiert ist und au-ßerdem in einer Programmiersprache entwickeltwurde, die eine rein technische Portierung nichtsinnvoll zuließ, musste die gesamte Geschäftslo-gik des bestehenden Systems in aktueller Techno-logie erneut entwickelt werden. Im Rahmen die-ses Redevelopment-Projekts waren angesichtsder Tragweite der durch das System nach außengelieferten Bonitätsinformationen umfangrei-che Testmaßnahmen erforderlich, um das Risikovon fachlich inkorrekten Informationen auf dasmögliche Minimum zu reduzieren. Daneben wa-ren im Rahmen der nicht funktionalen Anforde-rungen die Verfügbarkeit und Leistungsfähigkeitdes Systems mindestens so gut wie beim beste-henden herzustellen.

Inhaltsübersicht1 Ausgangslage und Ziele2 Initiator des Redevelopment-Projekts3 Umsetzung der Redevelopment-Strategie4 Qualitätssicherung im Rahmen des

Redevelopments4.1 Globale Teststrategie4.2 Testorganisation4.3 Testziele und Abnahmekriterien4.4 Testdurchführung

5 Risikominimierte Produktionseinführung5.1 Parallelbetrieb als

Produktionssimulation5.2 Stufenorientierte Produktionsaufnahme

6 Fazit7 Literatur

1 Ausgangslage und Ziele

Die SCHUFA als Organisation existiert im Jahr2007 genau 80 Jahre und ist das in Deutsch-land führende Unternehmen zur Lieferung vonVerbraucher-Bonitätsauskünften an die ange-schlossenen Vertragspartner. Dazu haben die– damals noch rechtlich getrennten – SCHUFA-Gesellschaften bereits seit Anfang der siebzigerJahre zunächst getrennte, dann seit 1992 ein ge-meinsames Mainframe-System genutzt, das inklassischer Hosttechnologie entwickelt wurdeund seitdem – wie alle Systeme aus dieser Zeit –durch viele fachliche Anpassungs- und Erweite-rungszyklen gegangen ist. Seit 1992 wird diesesSystem von einem externen Dienstleister be-trieben und gewartet.

In diesem System werden derzeit (Stand2006) in der SCHUFA-Datenbank für etwa64 Millionen Verbraucher über 400 MillionenEinzelinformationen gehalten und pro Tagmehrere Hunderttausend Auskünfte an Ver-tragspartner geliefert bzw. neue Informationenüber vertrags- bzw. nicht vertragskonformesVerhalten von Verbrauchern eingepflegt.

An das System sind praktisch alle Kreditins-titute in Deutschland und darüber hinaus einegroße Anzahl anderer Unternehmen direkt an-geschlossen, die Informationen über die Bonität(oder im Bereich von Onlineanbietern auchschon allein über die tatsächliche Existenz)ihrer Kunden benötigen.

Neben den pro Tag mehreren Hunderttau-send Anfragen über elektronische Kanäle wer-den Anfragen über eine Benutzeroberflächeauch noch manuell bearbeitet und über tradi-tionelle Kanäle wie Brief, Telefon und Fax an dieVertragspartner übermittelt. Außerdem wer-den pro Jahr weit über eine Million sogenannter

Teststrategie beim Redevelopment

HMD 257 81

Eigenauskünfte direkt an die Verbraucher selbstgegeben. Eine detaillierte Übersicht über diewesentlichen Funktionen und Services findetsich in [Steinbauer 2005].

2 Initiator des Redevelopment-Projekts

Mit der Gründung der SCHUFA Holding undder damit einhergehenden Zentralisierung derIT-Organisation wurden erste Untersuchungendurchgeführt, inwieweit sich das bestehendeSystem, das fast ausschließlich in /370-Assemb-ler programmiert ist, auf technischer Ebene ineine moderne Systemumgebung migrieren las-sen würde. Ein derartiges technisches Reengi-neering (vgl. [Baumöl et al. 1996]) musste dannaber als Lösungsansatz recht schnell verworfenwerden, weil es bei hohen Kosten keine wirklichqualitative Verbesserung der Zukunftsfähigkeit,insbesondere in Bezug auf die Verfügbarkeit(24x7-Betrieb) und verbesserte Produkterwei-terungsmöglichkeiten, der Software gebrachthätte. Außerdem wäre das gesamte Anwen-dungs-Know-how weiterhin allein beim Out-sourcing-Unternehmen geblieben, von dem dasSystem ja seit vielen Jahren betrieben und auchgewartet wird.

Die SCHUFA hat sich daher entschieden, fürdas gesamte Auskunftei-Kernsystem ein Re-development in aktueller Technologie durchzu-führen. Dieses Redevelopment wird in diesemBeitrag im Sinne der Definitionen von [Baumölet al. 1996] als Kombination von Reverse- undForward-Engineering-Techniken verstanden, beider die implementierten Geschäftsfunktionenauf Basis einer neuen Plattform erneut ent-wickelt werden. Im beschränkten Umfang sinddabei auch Optimierungen und andere Modifi-kationen der Geschäftslogik erlaubt, soweit sienicht das grundlegende Ziel der 1:1-Funktionali-tät gefährden.

Die gesamte Spezifikation und Umsetzunghat sich dabei an einer Wertschöpfungsarchi-tektur orientiert, die von den Geschäftsprozes-

sen ausgehend die gesamte Systemlandschaftbis zur technischen Plattform widerspiegeltund als Rahmen des gesamten Redevelopmentsdient. Diese Wertschöpfungsarchitektur zeigtgleichzeitig das Kommunikationsmodell für alleAnwendungskomponenten innerhalb und au-ßerhalb des neuen Auskunftei-Kernsystems.

3 Umsetzung der Redevelopment-Strategie

Zur Umsetzung der oben beschriebenen Strate-gie wurde ein entsprechendes Projekt initiiert,das die gesamten heute vorhandenen Ge-schäftsfunktionen in aktueller Technologie neuentwickeln soll. Dieses geschieht – auch zurRisikobegrenzung – in mehreren Stufen. Als Er-satz für die klassische Mainframe-Architekturauf Basis eines Transaktionsmonitors wurdeeine serviceorientierte J2EE-Architektur defi-niert, die auch die bereits bisher für Spezialauf-gaben genutzten Subsysteme als Services wie-der einbindet.

Die auf dem Mainframe bestehende relatio-nale Datenbank mit allen Verbraucherinfor-mationen ist bereits in einem früheren techni-schen Reengineering-Projekt aus einer indexse-quenziellen Datenhaltung entstanden undwurde bereits vor Projektstart als Replikations-bestand auch in der Zielumgebung verwendet.Sie wurde im Rahmen des Redevelopment-Pro-jekts daher nicht weiter verändert. Auch dieseEntscheidung ist als eine Risikominimierungs-maßnahme bezüglich der sicheren Einführungdes neuen Kernsystems anzusehen.

Das Redevelopment der in bisherigen An-wendungen vorhandenen Funktionen basiertauf komplett neu erstellten Spezifikationen, diein mehreren parallelen Ansätzen aus dem bis-herigen System und dessen Dokumentation er-mittelt wurden:

! Inspektion der vorliegenden fachlichen undtechnischen Dokumentation zum bestehen-den System. Hierzu zählen insbesondere dieden Vertragspartnern zugänglichen fachli-


82 HMD 257

chen und technischen Spezifikationen be-züglich der Anbindung an das SCHUFA-Aus-kunftei-System.

! Nutzung weiterer Sekundärdokumentationund insbesondere des nicht dokumentiertenKnow-hows von Mitarbeitern, die – manch-mal glücklicherweise – die gesamte Historiedes bestehenden Systems noch kennen.

Dazu wurden auf Basis der bestehenden Soft-ware, der zugehörigen Dokumentation, desKnow-hows der Mitarbeiter und in Einzelfällenauch durch Inspektion des Verhaltens der be-stehenden Anwendung neue Spezifikationenauf UML-Basis erstellt. Die eigentliche Imple-mentierung und die ersten Teststufen erfolg-ten sowohl durch eigene als auch durch Ent-wickler eines IT-Tochterunternehmens derSCHUFA.

Die gesamte Softwarearchitektur ist ser-viceorientiert ausgelegt, da neben der J2EE-basierten Kernsoftware auch Spezialanwen-dungen für die Bereiche! Adressprüfung und -normalisierung (auf Ba-

sis einer Standardsoftware),! Personenidentifizierung (auf Basis einer

schon früher individuell in einer anderen Ar-chitektur entwickelten Spezialsoftware) und

! Berechnung von Scores (auf Basis einer regel-basierten Standardsoftware)

weiterhin zum Einsatz kommen und nicht neuentwickelt wurden.

Die o. g. Systeme sind zum Teil auch zusam-men mit dem Mainframe-System im Einsatzund wurden – in leicht aktualisierten Versionen– auch für das Neusystem verwendet. Sie sindüber Service-Gateways an die Kernapplikationangeschlossen. Damit wurde für kritische Teileder Gesamtanwendung auf bewährte und sta-bile Systeme zurückgegriffen, da hier derzeitNeuentwicklungen keinen dem zusätzlichen Ri-siko angemessenen Effekt erzielt hätten. Auchder Einsatz von leistungsstarker Standardsoft-ware in einem Bereich, der nicht zu den Kern-kompetenzen der SCHUFA selbst gehört, war zu

berücksichtigen und eine entsprechende fachli-che und technische Anbindung zu realisieren.

Einen Überblick über die wesentlichen As-pekte der technischen Softwareschichten gibtdie nachfolgende Abbildung 1. Es handelt sichdabei im Grundsatz um eine »klassische« (so-weit man davon heute schon sprechen kann)J2EE-orientierte Schichtenarchitektur, bei derinsbesondere darauf Wert gelegt wurde, diePräsentations-, Workflow- und Geschäftslogik-schichten strikt zu trennen. Damit wurde einer-seits der Anforderung Rechnung getragen, dassdie Anwendung viele verschiedene Zugangs-kanäle und Nachrichtenformate unterstützt,also die Präsentationsschicht sehr mächtig seinmuss, und andererseits die Abläufe zur Erzeu-gung eines bestimmten Auskunftsproduktshochflexibel ausgelegt sein sollten. Neben denüblichen Geschäftslogik- und Persistenzschich-ten ist weiterhin die getrennte Kommunika-tionsschicht herauszuheben, über die alle ex-ternen Services auf unterschiedlichen Hard-ware- und Softwaresystemen angeschlossenwerden. Dieses schließt die Verbindung zu vor-erst verbleibenden Hostsystem-Services ebensoein wie die Anbindung von Standardsoftware-komponenten auf einem dedizierten Unix-System zur Adressprüfung.

Eine weitere wesentliche Vorgabe des Rede-velopment-Projekts im Rahmen der Risikomini-mierung war die Entscheidung, das neu entwi-ckelte System

! in kontrollierbaren Stufen zu entwickeln undin Produktion zu bringen,

! für eine Koexistenz mit dem bisherigen Main-frame-System für eine Übergangszeit vonmindestens einem Jahr einzustellen sowie

! den Vertragspartnern weitestgehend trans-parent über die aktuell genutzten Zugangs-kanäle zur Verfügung zu stellen.

Dazu wurde u. a. zwischen dem Mainframe-und dem Zielsystem eine Message-Queuing-Verbindung geschaffen. Weiterhin wurde indem bestehenden Mainframe-System eine so-


HMD 257 83

genannte »Nachrichten-Weiche« gebaut, diegeschäftsvorfallbasiert (und für bestimmteZwecke zusätzlich auch vertragspartnersen-

sitiv) entscheidet, welche der von außen ein-gehenden Service-Requests noch auf demMainframe-System bzw. bereits auf dem neuen

Abb. 1: Technische Softwarearchitektur


84 HMD 257

System bearbeitet werden. Durch diese Kon-struktion konnten sowohl während der späte-ren Testphasen als auch während der Produk-tionseinführung des neuen Systems Mecha-nismen genutzt werden, die eine direkteGegenüberstellung des Verhaltens des Alt- undNeusystems unter Produktionsbedingungenerlaubten (mehr dazu in den Abschnitten 4.4.3und 5.1).

4 Qualitätssicherung im Rahmen des Redevelopments

Gerade für eine neue Applikation mit einer der-art gravierenden Außenwirkung (vor allem aufdie jeweils betroffenen Verbraucher) sind um-fassende Qualitätsmaßnahmen eine »conditiosine qua non«, bevor eine derartige Anwendungfür den Betrieb freigegeben werden kann.

Neben den im Rahmen eines umfang-reichen Entwicklungsprojekts üblichen stati-schen Qualitätssicherungsverfahren wie auto-matischen Quellcode-Inspektionen und in aus-gewählten Fällen auch Codereviews spielten indiesem Projekt die dynamischen Qualitäts-sicherungsmaßnahmen, also das Testen inmehreren Stufen, naturgemäß eine wesentli-che Rolle.

4.1 Globale TeststrategieInnerhalb des SCHUFA-Entwicklungsprozessesdurchliefen zunächst alle Softwarekomponen-ten die üblichen Teststufen der Entwicklung,also insbesondere Unit- und Integrationstest.Diese wurden im Rahmen der normalen Ent-wicklungsorganisation durchgeführt und sol-len hier nicht weiter erläutert werden, da sieweitgehend den bekannten Mechanismen folg-ten.

Den üblichen Entwickler- und Integrations-tests schlossen sich dann zwei umfangreicheTeststufen an, die in völlig getrennten Organi-sationseinheiten durchgeführt wurden und fürdie die Entwicklungsabteilung die Rolle einesexternen Softwarezulieferers spielte. Diese ri-

gide Trennung forcierte es, dass durch die da-durch erforderlichen Liefermechanismen mitentsprechenden Qualitäts-Gateways immer einabsolut definierter Software-Release-Level ge-testet wurde, der von allen nebenläufigen Ein-flüssen unbeeinträchtigt war (»Reinraum-Test-umgebungen«).

Die beiden wesentlichen Teststufen zur Si-cherstellung der Produktionsfähigkeit der Soft-ware waren! der fachliche Abnahmetest (in der Literatur

auch als Systemtest bezeichnet, vgl. dazu z. B.[Sneed et al. 2007]) für die gesamte Abnahmeder fachlichen Korrektheit der neuen Applika-tion und

! der betriebliche Abnahmetest zum Nachweisund zur Absicherung aller nicht funktionalenAnforderungen, wie Performance, Robust-heit, Ausfallsicherheit etc.

Zusätzlich zu diesen beiden o. g. Teststufen, diejedes Entwicklungsrelease durchlaufen musste,wurden zwei weitere Teststufen vor der Pro-duktionsfreigabe definiert und für ausgewählteReleases durchlaufen:! ein Paralleltest (vgl. Abschnitt 4.4.3) zur wei-

teren Absicherung der fachlichen Korrektheitund Robustheit sowie

! ein Produktions-Parallelbetrieb (vgl. Ab-schnitt 5.1) mit der bestehenden Mainframe-Anwendung zur letzten Absicherung sowohlder fachlichen als auch nicht funktionalen As-pekte unter Produktionsbedingungen.

4.2 TestorganisationWie bereits angemerkt, wurden die fachlichenund betrieblichen Abnahmetests in einer vonder Entwicklungsabteilung getrennten Organi-sation durchgeführt. Diese Organisation agiertdabei zwar bei der Entwicklung des neuen Sys-tems projektbezogen, sie ist aber auch als ge-trennte Linienorganisation verankert. Alle fach-lichen Testvorgaben, d. h. die Spezifikation dereigentlichen Testfälle und die Bewertung derTestergebnisse, wurden durch eine eigenständi-


HMD 257 85

ge, in der SCHUFA schon länger bestehende Or-ganisationseinheit vorgenommen. Die Mitar-beiter(innen) dieser Abteilung sind auch an denSpezifikationen der Software beteiligt gewesenund haben die Testfalldefinitionen entlang denSoftwarespezifikationen aufgebaut. Durch die-se Abteilung wird letztlich auch die fachlicheKorrektheit der Software bestätigt, bevor sie inBetrieb genommen werden kann.

Weiterhin spezifisch für die Testorganisa-tion im Rahmen dieses Projekts (und auch da-rüber hinaus) war das Outsourcing aller tech-nischen Testaktivitäten an einen externenDienstleister. Dieses hatte folgende wesentli-che Gründe:! Da die fachlichen Tester (also die Personen,

die Testfälle erstellen und letztlich deren Er-gebnisse fachlich bewerten können) in jedemProjekt eine der wertvollsten und knappstenRessourcen darstellen, sollte dieser Teil derProjekt- (und auch Linien-)Organisation nichtmit Standardtestaktivitäten belastet werden.Dazu gehört die Pflege der Testumgebungenebenso wie die tatsächliche Durchführungder Tests auf Basis weitgehend automatisier-ter Prozesse. Die fachliche Testorganisationwar damit von allen »klerikalen« Testaktivitä-ten befreit und konnte sich voll auf die fach-liche Testfallerstellung und -pflege und die ei-gentliche fachliche Abnahme konzentrieren.

! Da die SCHUFA weiterhin selbst keine dedi-zierte Organisation und Infrastruktur für dietechnische Abwicklung der umfangreichenTests auf dem neuen System aufbauen woll-te, wurde dieser Aufgabenbereich der fach-lichen Abnahmetests an einen externenDienstleister vergeben. Dieser ist sowohl fürdie Verfügbarkeit der entsprechend notwen-digen Hardware- und Softwareumgebungenals auch für die geordnete Abwicklung allerBetriebs- und Testaktivitäten verantwortlich.

! Derselbe externe Dienstleister ist auch fürden gesamten Betrieb der heutigen Main-frame-Anwendung und der neuen Anwen-dung verantwortlich und übernimmt im

Rahmen dieser Beauftragung die Verantwor-tung für die Betriebssicherheit. Es war dahernur konsequent, die Verantwortung für alleTests und Abnahmen in Bezug auf die nichtfunktionalen Aspekte der neuen Anwendungin die Verantwortung des Providers zu legen.Dadurch wurde insbesondere eine rigide ex-terne Qualitätssicherung impliziert, da derProvider letztlich für die Einhaltung der Ser-vice Levels im realen Produktionsbetrieb dieVerantwortung zu tragen hat.

Die Zusammenarbeit zwischen den fachlichenund technischen Testaktivitäten erfolgte durcheine eigene Koordinationsstelle, die für eine op-timale Auslastung aller Testressourcen und ziel-gerichteten Tests zu sorgen hatte. Für die fachli-che Freigabe der Software für den Produktivbe-trieb war allein die entsprechende SCHUFA-Organisation, für die betriebliche Freigabe dieSCHUFA zusammen mit dem externen Dienst-leister verantwortlich.

4.3 Testziele und Abnahmekriterien

Es handelt sich bei diesem Projekt um das Re-development eines seit vielen Jahren bestehen-den und »lebenden« Systems, das auch nachvielen Jahren natürlich – wie jede Software –noch mit versteckten Fehlern behaftet ist undsich nicht immer so verhält, wie es die vorlie-genden Spezifikationen aussagen.

Die Testziele bezüglich des jetzt neu entwi-ckelten Systems mussten sich dieser Tatsachestellen und waren damit nicht immer so 100 %eindeutig zu definieren, wie das einerseits ent-weder bei einem reinen technischen Re-engineering (100 % identische Funktionalität,im Zweifel inklusive der nachträglich erkanntenFehler) oder bei einer reinen Neuentwicklung(allein die fachliche Spezifikation gibt die erwar-teten Testresultate vor) der Fall wäre.

Wie bereits angemerkt, gibt es bei einemRedevelopment-Projekt, wie dem hier vorge-stellten, daher grundsätzlich zwei wesentliche,parallele und eben auch konkurrierende Test-


86 HMD 257

ziele und entsprechende abgeleitete Teststrate-gien, nämlich

! einerseits das Ziel des technisch orientiertenReengineering-Tests, d. h. den Nachweis derweitestgehenden Abbildung der bisher vor-handenen Funktionalität der zu ersetzendenAnwendung (»1:1-Funktionalität«; vgl. dazuz. B. [Borchers 1997]),

! andererseits die für Neuentwicklungen maß-gebliche korrekte Umsetzung aller fachlichenSpezifikationen.

Es tut sich also das für den Test in einem Rede-velopment-Projekt klassische »Diener zweierHerren«-Dilemma auf: Einerseits soll die Soft-ware – natürlich! – den neu erstellten Spezifika-tionen entsprechen (die zwar weitgehend dasVerhalten der bestehenden Software reflektie-ren sollen, in Einzelfällen aber bewusst auchVerbesserungen einführen), andererseits mussdas Verhalten des bestehenden Systems –schon aus Verlässlichkeitsgründen nach außen– möglichst genau reproduziert werden.

Die Abnahmekriterien waren ebenfalls denparallelen Anforderungen anzupassen. In denFällen, bei denen sich das neue System zwar imSinne der Spezifikation (auch bezüglich des be-stehenden Hostsystems) korrekt, aber abwei-chend von dessen tatsächlicher aktueller Funk-tionalität verhielt, war zu entscheiden, welchesder beiden konkurrierenden Abnahmekriterienletztlich Vorrang haben sollte.

Gerade bei dieser Abwägung ging es dar-um, in den angeschlossenen Anwendungssys-temen bei den Vertragspartnern, die mit derSCHUFA-Anwendung direkt verbunden sind,möglichst keine signifikanten Wartungsaktivi-täten auszulösen. Daher wurde gerade bei reintechnischen Abweichungen, z. B. in Satz- undDatenformaten, häufig die Kontinuität für dieVertragspartneranwendungen der »harten«Spezifikationsverfolgung vorgezogen, auchwenn diese schon beim Hostsystem so hätteangewendet werden können. Hier wurde imZweifel den »Gewohnheitsrechten« der Ver-

tragspartner Vorrang eingeräumt, um bei derProduktionseinführung keine unnötigen Kon-fliktsituationen zu provozieren.

4.4 TestdurchführungWie bereits oben erwähnt, wurden alle fach-lichen und betrieblichen Abnahmetests auf ge-trennten Hardware- und Systemumgebungendurchgeführt. Dabei konnten im Extremfall vierverschiedene Softwareversionen mit jeweilsunterschiedlichen Datenbeständen getestetwerden, unter anderem für betriebliche Testsauch in der Produktionsgröße.

Zusätzlich stand eine Mainframe-Testum-gebung zur Verfügung, auf der alle Referenz-tests (genauer: die Herstellung von Referenz-testergebnissen mit den vorgegebenen fachli-chen Testfällen) durchgeführt wurden.

4.4.1 Fachlicher AbnahmetestAufgrund der oben beschriebenen Testziele undAbnahmekriterien war ein fachlicher Abnahme-test aufzusetzen, der beiden genannten Test-hauptzielen gerecht wurde und dabei weitest-gehend ausnutzte, dass mit dem bestehendenSystem und dem dafür bekannten Verhalteneine sichere Referenz vorlag, gegen die im Ein-zelfall auch noch die Korrektheit der neuen Spe-zifikationen selbst zu prüfen war.

Alle fachlichen Testfälle wurden von derfachlichen Abnahmeabteilung in Excel-Dateienmit einem festen Format abgelegt. Dieses For-mat spiegelt die klassische Aufteilung wider:

! Zustand der relevanten Datenobjekte vordem Testfall

! Testfall (»Geschäftsvorfall«) selbst! Erwartetes Ergebnis des Testfalls! Erwarteter Datenzustand der relevanten Ob-

jekte nach dem Testfall

Insgesamt wurden für die derzeit erste Produk-tionsstufe (die allerdings die wesentlichenGrundfunktionen schon enthält) fast 10.000fachliche Testfälle definiert, die sich in der Kom-bination mit allen möglichen Ein- und Ausgabe-


HMD 257 87

kanälen und der grafischen Benutzeroberflächezu einem Gesamtvolumen von über 50.000technischen Testfällen multiplizieren.

Aus den fachlichen Vorgaben wurden wei-testgehend automatisiert alle physischen Test-eingaben, d. h. die technischen Testfälle, gene-riert. Rein manuelle Tests wurden nur für einenkleinen Teil der Testfälle, insbesondere in kom-plexeren Bereichen der grafischen Benutzer-oberfläche, durchgeführt.

Die Möglichkeit zu dieser automatisiertenVorgehensweise wurde dadurch begünstigt,dass sich die bisherige Ausbaustufe des Anwen-dungssystems nach außen zum großen Teil alseine Menge von nachrichtenbasierten, zu-standslosen Services darstellt, d. h. ein – über ei-nen der vielen alternativen Zugangskanäle –eingehender Service-Request wird mit einerNachricht beantwortet und der Geschäftsvor-fall ist – zumindest nach außen – beendet.Intern laufen dann weitere Prozesse ab (auchz. B. das Verändern von Datenbanken), die abergetrennt verifiziert werden können. Das Haupt-augenmerk aller Tests bezog sich naturgemäßprimär auf die korrekte Informationsabgabenach außen.

Die weitgehend automatisierte technischeTestdurchführung vollzog sich damit in den fol-genden Schritten:

! Erzeugen der physischen Eingabeformate fürdie jeweiligen technischen Kanäle auf Basisder gleichen fachlichen Basistestfälle

! Erzeugen einer ersten Testergebnis-Baselinedurch Ausführen aller Testfälle gegen die be-stehende Hostumgebung (also kein Test imeigentlichen Sinn, sondern eine Beschaffungvon Sollverhalten auf Basis der bestehendenHostanwendung)

! Für jeden Release-Level der neuen SoftwareDurchführung aller vorliegenden techni-schen Testfälle und Vergleich mit dem jewei-ligen Baseline-Testergebnis

! Ab einer gewissen Reifestufe der neuen Soft-ware Auswechseln der jeweiligen Ergebnis-Baselines für die einzelnen Blöcke von fachli-

chen und technischen Tests, um akzeptierteAbweichungen gegenüber der Originalsoft-ware nicht in jeder Testrunde wieder explizitfreigeben zu müssen.

Um alle diese umfangreichen Tests (über alleRelease-Level wurden bis heute weit über eineMillion Testfälle ausgeführt) effizient und vorallem in kurzen Zeitintervallen durchführen zukönnen, wurde die reine Testdurchführung imSinne einer Produktionsstraße (»Factory«) soweit wie sinnvoll möglich durch automatisierteProzesse unterstützt.

Diese Prozesse beziehen sich vor allem auffolgende Aktivitäten:! Alle Rüstprozesse wie das Laden der richtigen

Datenarchive, Rücksetzen von Ausgabearchi-ven, Setzen von testspezifischen Betriebspa-rametern

! Die eigentliche Testausführung, für alle nach-richtenbasierten Tests durch entsprechendeTreiber, im Bereich der grafischen Oberflächedurch Einsatz eines Capture-/Replay-Tools so-wohl für die klassischen Mainframe-Maskenals auch die neue GUI

! Sicherung aller Testergebnisse nach jedemTestlauf (sprich einer Menge von Testfällen zueinem Teilaspekt der Anwendung) inkl. derveränderten Datenbestände und sonstigerAusgabearchive (z. B. XML- und PDF-Dateienmit schriftlichen Informationen, Übergabenan die Fakturierung, an das Data Warehouseusw.)

! Weitestmöglich automatisierter Vergleich al-ler Testergebnisse des neuen Release-Levelsmit denen des aktuell gültigen Stands (in derRegel basierend auf dem direkten Vorgänger-Release)

! Erstellen von Auswertungen als Basis für diefachliche Bewertung von Abweichungsfällen

Wie bereits angemerkt, wird die gesamte tech-nische Testdurchführung durch einen externenProvider in einer eigens dafür aufgebauten Test-umgebung durchgeführt, in der im Extremfallbis zu vier verschiedene Software- und Daten-


88 HMD 257

stände parallel getestet werden können, ohnedass es zu unerwünschten gegenseitigenWechselwirkungen kommen kann (»Reinraum-Testumgebungen«).

4.4.2 Betrieblicher AbnahmetestNeben der Risikominimierung in Bezug auffachliche Ergebnisse sind bei einem völligneuen System, angefangen bei der Hardware-architektur über die technische Softwarearchi-tektur bis hin zur Implementierung der einzel-nen Services in Klassen und Methoden, natür-lich alle betrieblichen Aspekte umfassendabzusichern.

Die wesentlichen Tests aus betrieblicherSicht, also der nicht funktionalen Anforderun-gen des neuen Systems, lassen sich kurz in fol-genden Blöcken zusammenfassen:

! Natürlich standen zunächst alle Perfor-mance-Aspekte im Vordergrund, d. h., wieschnell wird ein Geschäftsprozess abgewi-ckelt, wie hoch ist der Durchsatz von Ge-schäftsvorfällen, wo ist die Grenze des Sys-tems usw.

! Daneben sind Dauer- und Stresstests durch-geführt worden, um zu erkennen, obSpeicherbereiche oder andere Ressourcenkorrekt wieder freigegeben werden usw.

! Im Sinne der vom neuen System geforderten24x7-Verfügbarkeit waren alle betrieblichenProzesse, inkl. der Einspielung eines neuenSoftwarestands (sog. »downtime-loses De-ployment«) ebenso zu verifizieren wie die Si-mulation des Ausfalls einzelner Softwareser-vices und -Basissysteme und letztlich auchder partielle Ausfall von Hardwarekom-ponenten sowie der sogenannte K(atastro-phen)-Fall, bei dem eines der beteiligten Re-chenzentren ganz ausfällt.

Da der Betrieb auch der neuen Anwendungdurch den Outsourcing-Provider verantwortetwird, lag die Hoheit aller Tests und letztlich auchdie Abnahme in dessen Händen, da die Ergeb-nisse der betrieblichen Tests eine wesentliche

Grundlage für die vereinbarten Service Levelsdarstellten. Dazu gehörte neben den Tests auchdie Verifizierung aller ITIL-Prozesse, die zwi-schen der SCHUFA und dem externen Providerzu vereinbaren waren. Diese stellen ebenfalls ei-nen wesentlichen Pfeiler der Risikobegrenzungdar.

4.4.3 Fachlicher ParalleltestTrotz aller fachlichen und betrieblichen Testsmit vielen 10.000 Testfällen und Millionen vonTestausführungen über alle Release-Levels wur-de entschieden, zur Reduzierung des Einfüh-rungsrisikos einen weiteren – fachlich orientier-ten – Test durchzuführen, nämlich den fach-lichen Paralleltest.

Bei diesem handelte es sich noch einmalum einen klassischen Regressionstest, aller-dings in diesem Fall auf Basis von Testfällen, dieaus dem Hostproduktionssystem durch Mit-schnitt echter Geschäftsvorfälle gewonnenwurden. Dazu wurde in einem eigens dafür ge-schaffenen Mitschnittmodul in der Produk-tionshostanwendung der wesentliche produk-tive Geschäftsvorfallmix (nur die Eingaben,nicht deren Ergebnisse) über mehrere Intervalleaufgezeichnet. Da dieser durch andere Neben-einflüsse des Produktionsbetriebs nicht regres-sionsfähig war, wurden alle relevanten Produk-tionsdatenbestände ebenfalls gesichert.

In einer eigenen Testhostumgebung wur-den dann alle diese mitgeschnittenen Ge-schäftsvorfälle – basierend auf den gesichertenDatenbeständen – noch einmal durchgeführt,und erst bei diesem Durchlauf wurden dannauch alle Ergebnisse zur Erstellung einer Tester-gebnisreferenz gesichert.

Im eigentlichen (als »Paralleltest« bezeich-neten) Regressionstest wurden dann in derneuen Produktionsumgebung (die ja zu diesemZeitpunkt produktiv noch nicht genutzt wurde)alle Geschäftsvorfälle nachgefahren und mitden Hostergebnissen verglichen. Dabei standbei diesem Test nur im Vordergrund, weiterefachliche und technische Konstellationen, wie


HMD 257 89

es sie eben doch nur in einer schon lange Jahrelaufenden Produktion gibt, bezüglich ihrer kor-rekten Abwicklung im neuen System zu verifi-zieren. Performance und andere betrieblicheAspekte fielen bei diesem Test nicht ins Ge-wicht, wurden aber am Rande natürlich bereitsmit betrachtet.

Durch diese Testläufe konnten Verhaltens-weisen von externen angeschlossenen Syste-men ermittelt und abgesichert werden, die sichin selbst aufgebauten fachlichen Testfällen nurschwer vorhersehen und abbilden lassen.

5 Risikominimierte Produktionseinführung

5.1 Parallelbetrieb als Produktionssimulation

Ungeachtet der bereits vorangegangenen um-fangreichen Tests wurde auch für die eigentli-che Produktionseinführung eine weitere Absi-cherungsstufe eingeführt, der Parallelbetrieb.

Wie in Abbildung 2 dargestellt, bleibt dasHostsystem nach Einführung der neuen Kern-

anwendung auf der Unix-Plattform als Front-end zu den Vertragspartnern erhalten. Damitkonnte eine weitere Stufe einer gleitenden Ein-führung genutzt werden: der Parallelbetrieb alsFortsetzung zum oben beschriebenen Parallel-test. Im Gegensatz zu diesem waren aber allefachlichen und betrieblichen Aspekte produk-tionsäquivalent ausgelegt:! Die neue Zielproduktionsumgebung wurde

vollständig aufgebaut und war mit allen Pro-zessen im Prinzip voll produktionsbereit.

! Alle über die Hostumgebung eingehendenService-Requests wurden dort normal verar-beitet (also die »alte« Produktion war nachaußen immer allein in Betrieb), es wurdendort aber jetzt alle ein- und ausgehendenNachrichten mitgeschnitten und gesichert.

! Gleichzeitig wurden die für den späterenProduktionsbetrieb der neuen Anwendungvorgesehenen Message-Queuing-Mechanis-men in einer speziellen Form so genutzt, dassparallel zur bestehenden Hostverarbeitungalle Geschäftsvorfälle »realtime« auch an dieneue Umgebung geschickt (»geklont«) und

Abb. 2: Infrastruktur für den Parallelbetrieb


90 HMD 257

dort bearbeitet wurden; das Ergebnis derneuen Anwendung wurde – wie im späterenneuen Produktionsbetrieb vorgesehen – andas Host-Frontend zurückgeschickt und dortebenfalls mitgeschnitten.

! Die Anfragen und Ergebnisse der bestehen-den und neuen Anwendung wurden dannoffline sowohl unter fachlichen als auch be-trieblichen Aspekten ausgewertet.

Das oben beschriebene Prozedere wurde fürviele – zu Anfang kurze, später immer längere –Perioden zu unterschiedlichen Belastungszei-ten wiederholt und hat neben der weiterenfachlichen Absicherung auch dem Einüben allerbetrieblichen Prozesse und der stufenweisenAnbindung der nachgelagerten Systeme wiez. B. Fakturierung, Data Warehouse und ande-ren gedient.

Diese – immer noch als Teststufe anzuse-hende – Simulation des späteren Produktivbe-triebs der ersten Stufe der neuen Kernanwen-dung hat damit das eigentliche Produktions-aufnahmeszenario, das aus einer Kombinationder bestehenden Hostanwendung für be-stimmte Geschäftsprozesse und den bereits aufder neuen Unix-Umgebung abzuwickelndenGeschäftsvorfällen besteht, weitestgehend ab-gesichert.

5.2 Stufenorientierte ProduktionsaufnahmeAls letzte Risikominimierungsstufe diente diestufenweise Freigabe der angeschlossenenVertragspartner für das neue – kombinierte –Produktivsystem.

Dabei wurden die auf dem Host bestehen-den Message-Queuing-Mechanismen so einge-stellt, dass nicht alle Vertragspartner gleichzei-tig zum neuen System durchgeschaltet wurden.Vielmehr wurde in Absprache mit den Vertrags-partnern die Last auf dem neuen System stu-fenweise immer weiter erhöht, bis letztlich allebereits in der Zielumgebung implementiertenServices nicht mehr auf dem bestehendenHostsystem, sondern in der neuen Umgebungabgewickelt werden. Auf dem Hostsystem ver-

bleiben derzeit die Services, die erst in weiterenEntwicklungs- und Produktionsstufen auf demZielsystem zur Verfügung stehen werden. Erstwenn alle Entwicklungsstufen des neuen Sys-tems fertiggestellt sind, kann das bestehendeHostsystem auf die reine Frontend-Funktion re-duziert und die dort implementierte Geschäfts-vorfallbearbeitung abgeschaltet werden.

6 FazitSicherlich wird dem einen oder anderen Leserder in diesem Projekt betriebene Aufwand fürQualitätssicherungs- und Produktionseinfüh-rungsmaßnahmen exorbitant erscheinen, under ist nicht für jede Produktionseinführung ei-nes neuen Systems notwendig.

Warum gab es für die SCHUFA trotzdem kei-ne Alternative dazu? Weil das Kernsystem derSCHUFA! eines der »zentralsten« Systeme in der Bun-

desrepublik Deutschland ist, es sind viele Tau-send andere Unternehmen angeschlossen,die über viele verschiedene technische KanäleServices der SCHUFA nutzen;

! in Zukunft noch sicherer und leistungsfähigersein soll als das jetzt über 30 Jahre laufendeHostsystem;

! im Sinne einer »Just-in-Time«-Informations-zulieferung an die Vertragspartner signifi-kanten Einfluss auf deren Geschäftsprozessehaben kann; wenn von dort eine SCHUFA-Auskunft nicht zeitnah abgerufen werdenkann, kommen gegebenenfalls Kredit- oderHandelsgeschäfte nicht zustande;

! eine hohe Verantwortung gegenüber denVerbrauchern (primär natürliche und nicht ju-ristische Personen) repräsentiert, indem esüber ihre Bonität nur absolut korrekt infor-miert, soweit dieses im Einflussbereich derSCHUFA liegt.

Unter diesen Aspekten sind die Maßnahmenaus Sicht der Vertragspartner und auch primärder Verbraucher mehr als gerechtfertigt ge-wesen.


HMD 257 91

Die Frage, ob alle diese Aktivitäten dennnun sofort zu einer »Null-Fehler-Produktion«geführt haben, kann man mit »prinzipiell ja«beantworten. In wenigen Fällen sind zwar dochnoch Fehler aufgetreten, allerdings bisher keineinziger, der zu einer falschen Bonitätsauskunftüber einen Verbraucher geführt hat. Die meis-ten Probleme waren administrativer oder tech-nischer Natur. Dieses kann sicherlich als Erfolgder Risikominimierung in diesem Projekt ge-wertet werden.

Das hier beschriebene Vorgehen hat sichdaher bewährt und wird bei den weiteren Ent-wicklungs- und Produktionsstufen der neuenSCHUFA-Kernanwendung weitergeführt.

7 Literatur[Baumöl et al. 1996] Baumöl, U.; Borchers, J.; Eicker,

S.; Hildebrand, K.; Jung, R.; Lehner, F.: Einord-nung und Terminologie des Software Reengi-neering. In: Informatik-Spektrum, 19(4), 1996.

[Borchers 1997] Borchers, Jens: Erfahrungen mitdem Einsatz einer Reengineering Factory in ei-nem großen Umstellungsprojekt. In: HMD –Praxis der Wirtschafsinformatik, Heft 194, 1997.

[Sneed et al. 2007] Sneed, Harry; Baumgartner,Manfred; Seidl, Richard: Der Systemtest – Anfor-derungsbasiertes Testen von Software-Syste-men. Hanser Verlag, München, Wien, 2007.

[Steinbauer 2005] Steinbauer, Dieter: An Interme-diate Information System Forms Mutual Trust.In: Härder, Theo; Lehner, Franz: Data Manage-ment in a Connected World. Lecture Notes inComputer Science, Springer-Verlag, Heidelberg,2005.

Dipl.-Math. Jens BorchersSteria Mummert Consulting AGHans-Henny-Jahnn-Weg 2922085 [email protected]

Prof. Dr.-Ing. Dieter SteinbauerSCHUFA Holding AGKormoranweg 565201 [email protected]

Documents

Teststrategie beim Redevelopment — Risikominimierung im SCHUFA-Projekt