Ein Projekt, das sich mit der Jahrtausend-Umstellung befaßt, verlangt mühsame Kontrollen, wenn es darum geht, sämtliche Komponenten aus dem Bereich der Informationstechnologie (IT) zu checken. Das Millennium-Problem zieht sich durch eine überaus heterogene IT-Landschaft: Von Mainframes über Client-Server-Systeme und Netzwerke bis hin zu Factory-Processing-Rechnern ist alles zu analysieren.
Die voneinander abhängigen einzelnen Komponenten in diesem komplexen Umfeld beeinflussen entscheidend den Testbeginn und -ablauf. Aber bevor ernsthaft von einer erfolgreichen Jahreszahlen-Umstellung die Rede sein kann, sind außer den eigentlichen Anwendungsprogrammen, die die wiederkehrenden Geschäftsprozesse unterstützen, die Hardwareplattform, das jeweilige Betriebssystem, die Datenbanksoftware und die zum Systembetrieb erforderliche Middleware zu untersuchen.
Außerdem ist festzustellen, ob sämtliche Schnittstellen, sowohl zu anderen Anwendungen als auch zu externen Dienstleistern, weiterhin funktionieren. Es ist logisch, daß mit diesen Aufgaben mehrere Mitarbeiter eine gute Zeit lang beschäftigt sein werden.
Je näher das Jahr 2000 rückt, desto knapper und teurer wird die Ressource Personal - das ist inzwischen bekannt. Viele Unternehmer und IT-Manager wissen aber nicht, daß bereits im nächsten oder sogar schon in diesem Jahr erste Auswirkungen des Millennium-Problems auftreten können. Daher empfiehlt es sich unbedingt, daß die Mitarbeiter in den Jahr-2000-Teams bei der zu testenden Anwendungssoftware Prioritäten setzen.
Die Umstellungsreihenfolge ergibt sich daraus, wie wichtig die jeweilige Anwendung für die täglichen Geschäftsprozesse ist und wo das Millennium-Problem frühestens auftreten dürfte. Gleichzeitig sollten Alternativlösun- gen bereitstehen, und die Tester müssen, falls die DV-Technik versagt, jederzeit improvisieren können.
Alle voneinander abhängigen IT-Komponenten (Hard-, Soft- und Middleware, OS, Datenbank sowie andere Anwendungen) werden zu einem Paket zusammengefaßt. So läßt sich durch Ermittlung des schwächsten Glieds in der Kette (das noch nicht mängelfrei umgestellte Modul) der früheste Termin für den Integra- tionstest festlegen. Dies wird Einfluß auf die notwendigerweise flexible Ressourcen-Planung haben.
Der frühe Test der einzelnen Module kann komplikationslos über die Bühne gehen. Allerdings rufen häufig zwei Komponenten, deren Kommunikation nicht richtig aufeinander abgestimmt ist, Fehler hervor. Eine Fehlerquote von schätzungsweise fünf Prozent läßt sich erst durch den Integrationstest aufdecken.
Aus diesem Grund sollte man Netzprotokollen, Ein- und Ausgabedateien, EDI-Standards, aber auch den mit Banken und anderen Organisationen vereinbarten Strukturen besondere Aufmerksamkeit widmen. Es ist unerläßlich, die Verarbeitung eines Datumstyps einvernehmlich abzustimmen und entsprechend zu prüfen.
Welche Ereignisse des Datumswechsels müssen nun hinsichtlich ihrer DV-technischen Lösung untersucht werden? Neben dem Wechsel des Jahrtausends spielt eine Rolle, daß das Jahr 2000 ein Schaltjahr ist. Weitere Probleme entstehen, wenn Zahlen wie 99, 00 oder 01 als Platzhalter für andere Ereignisse dienen sollten. Solche Fälle sowie die Art der zu testenden Komponente entscheiden über die erforderlichen Prüfungen.
Die einzelnen Maßnahmen ergeben sich aus den definierten Zielen, die ihrerseits von der Funktionalität der einzelnen IT-Komponente bestimmt werden. Erzeugt sie ein Systemdatum, ist sowohl der Wechsel von 1999 auf 2000 als auch der Schaltjahr-Übergang vom 28. auf den 29. Februar 2000 zu testen.
Bei Dateiverwaltungssystemen und Sortier- beziehungsweise Mischvorgängen kann nur die Jahrhundertgrenze gefährlich werden und muß entsprechend getestet werden. Es ist dabei wichtig zu verifizieren, ob sich eine in (19)99 erzeugte Datei im Jahr (20)00 noch umwandeln läßt oder das System das Datum dieser Änderung eventuell als kleiner als das Datum der Erstellung interpretiert.
Auch bei IT-Komponenten, die einen Zeitraum durch Vorgabe von Anfangs- und Enddatum verarbeiten, sollte man sich vergewissern, ob - auch bei nur zweistelliger Jahreszahl - ein Jahrhundert-übergreifender Zeitraum möglich ist. Wird ein Kalender aufgebaut, muß die Anzahl der Tage in 2000 (366) und der Tag des Jahres 29. Februar 2000 (60) überprüft werden:
Beim sogenannten Regressionstest handelt es sich um einen Vergleich zwischen der unveränderten Anwendung und der für den Jahrtausendwechsel angepaßten Version - unter heutigen Bedingungen. Das Prüfverfahren soll bestätigen, daß erstens Modifikationen die Funktionalität der Anwendung nicht verändert haben und zweitens keine neuen Bugs implementiert wurden.
Hierfür kann man eventuell auf bereits vorhandene Testdaten, die mit der Millennium-Thematik nichts zu tun haben, zurückgreifen. Der "Output" des Regressionsverfahrens läßt sich gegebenenfalls für Vergleichszwecke mit der Ausgabe des eigentlichen Millennium-Tests nutzen.
Die häufig erwähnte Zeitreise soll nachweisen, ob die typischen Jahr-2000-Probleme erkannt und richtig verarbeitet werden. Es muß gewährleistet sein, daß die Funktionalität der Anwendung über den Jahrtausendwechsel hinaus uneingeschränkt gegeben ist.
Für IT-Komponenten, die sich eines internen Maschinendatums bedienen, ist zu checken, ob der 01. 01. 2000 richtig gelesen wird. Wird das Datum als 01. 01. 1900 fehlinterpretiert, wäre ein darauf basierender Kalender ebenfalls fehlerhaft. Ein Kalender ist mit einem Intervall von 28 Jahren identisch. Das heißt im Fall der programminternen Verjüngung des Datums, daß zum Beispiel von 2000 auf 1972 oder 1944 zurückgegangen werden muß, um einen identischen Kalender erstellen zu können.
Soweit IT-Komponenten ein Zeitintervall interpretieren, ist zu verifizieren, ob sie das Jahr 2000 auch bei einer zweistelligen Notation als "größer als 1999" erkennen. Nicht zu vergessen die erforderlichen Tests bei Dateiverwaltungsprogrammen: Lassen sich im Jahr 2000 neue Dateien weiterhin problemlos erstellen oder ersetzen? Denkbar ist, daß ein solches Programm ein im Jahr 20(00) gefertigtes Dokument nicht als neue Version einer bereits 19(99) gefertigten Version erkennt.
Die IT-Komponenten, die einen Kalender generieren gilt es darauf zu untersuchen, ob dem 28. Februar 2000 richtigerweise ein 29. Februar folgt. Das ominöse Jahr 2000 ist ein Schaltjahr nach der Kalenderregel: Schaltjahre sind gerade durch vier teilbar, mit Ausnahme der durch 100, aber einschließlich der durch 400 dividierbaren Jahre.
Generell sollten Anwender auch bereits den Wechsel vom 31. 12. 98 zum 01. 01. 99 sowie den vom 31. 12. 00 auf den 01. 01. 01 simulieren. Denn diese verkürzten Jahreszahlen dienen gelegentlich dazu, ganz andere Ereignisse anzusteuern.
Aus den Testzielen abgeleitet gilt es, wiederverwendbare Testfälle zu fertigen und zu archivieren. Auch die erwarteten Ergebnisse werden definiert und aufgehoben. An diesen Checklisten orientieren sich die Prüfverfahren. Die Ergebnisse müssen sorgfältig dokumentiert und unter Angabe des Datums sowie der Version archiviert werden. So läßt sich der Verlauf des gesamten Testaufkommens überwachen und jederzeit nachvollziehen. Außerdem ermöglicht es die Kontrolle, ob die jeweils aktuelle Version einer Komponente bereits getestet wurde.
Für die meisten Unternehmen bedeutet der gewaltige Aufwand beim Millennium-Projekt und vor allem beim Testing in erster Linie Kosten. Doch das Geld könnte als langfristige Investition wirken: Wer ein methodisches Vorgehen entwickelt, kann mit ihm auch bei künftigen Projekten den Aufwand verringern oder die Qualität sichern.
Der Einsatz eines Test-Tools verringert unter anderem den Aufwand bei der Datenerfassung und die dabei auftretenden Fehler. Die Automatisierung von Testabläufen ist als zukunftsweisende Investition zu sehen. Zwar wäre ein einziges Tool sehr wünschenswert, aber wegen der Vielfalt der zu testenden IT-Komponenten in unterschiedlichsten Umgebungen läßt sich das Prüfverfahren in der Regel nur mit einer Kombination verschiedener Werkzeuge durchführen.
Angeklickt
Möglicherweise weil sie mit einer Analyse der DV-Bestände und der Umstellung von zwei- auf vierstellige Jahreszahlen reichlich spät begonnen haben, sind viele Anwender dabei jetzt sehr engagiert. So sehr, daß sie die Aufgaben und den Aufwand für die Überprüfung der Modifikationen momentan etwas weit nach hinten schieben. Doch werden die Tests der Systeme letztlich den größten Teil von Zeit und Investitionen verschlingen. Da je nach Art und Funktion der umzustellenden Komponenten unterschiedliche Testtypen erforderlich sind, lassen sich durchaus Ablaufpläne für diese Nagelproben erstellen.
Claus Hirsch ist als Berater und Projektleiter in der Service Line "Business Continuing Services" der Origin Deutschland GmbH, Hamburg, für den Bereich Millennium-Testing verantwortlich.
Abb: Fast die Hälfte des Aufwands in einem durchschnittlichen Jahr-2000-Projekt beansprucht das Testing. Quelle: Origin