Bei der Optimierung der technologischen Infrastruktur bei Finanzinstituten werden Systeme oftmals auf neue Hardwarelösungen migriert. Eine besondere Eignung für Migrationen haben dabei Systeme, die bereits einheitliche Hardwarestrukturen aufweisen, wie zum Beispiel SAP-Systeme, bei denen heutzutage typischerweise Sun/ Solaris die Infrastruktur der Systemlandschaft bildet. Eine besondere Rolle bei der Validierung der Migrationen vor dem Hintergrund der Systemkomplexität fällt den Migrationstests zu.
Die technischen Vorteile einer Migration sind vor allem im Bereich der Produktivität, der Performance und der Effizienz zu finden.1) Es gibt bereits mehrere Beispiele für Migrationen am Markt, die eindeutig belegen, dass mit den technischen Verbesserungen ökonomische Vorteile einhergehen.2) Es wird erwartet, dass sich die Kosten des Betriebs reduzieren. Diese und auch weitere Vorteile gilt es in Migrationsprojekten durch geeignete Projektstrategien und Vorgehensweisen sicherzustellen. Im vorliegenden Artikel werden wesentliche Aspekte anhand eines Beispiel-Migrationsprojektes aus der Perspektive des Testmanagements beleuchtet und analysiert.
Arbeitspakete pro Systemlandschaft
Als Beispiel wird hier ein Migrationsprojekt von SAP-Systemen angeführt, wobei jeweils zwei Installationen von Solution Manager, Portal, Middleware Process Integration (PI), Portfolio Manager (PM), Customer Relationship Management (EIC), Rechnungswesen/Logistik (ReLo), Konsolidierung (ECCS) und Human Resource (HR) mit rund 30 verschiedenen Anwendungen betroffen waren. Eine gesonderte Migration in der Londoner Zweigstelle involvierte weitere drei SAP-Systeme.
Das ganze Migrationsvorgehen basierte auf drei Hauptaktionen:
- Erstellung einer Systemkopie,
- Export der Daten aus dem alten System,
- Import der Daten in das neue System.
Das Projekt wurde in Arbeitspakete pro Systemlandschaft unterteilt (siehe Abbildung 1), die in der Regel von einem Mitarbeiter aus dem Bereich System Delivery Management sowie aus der Produktion gemeinsam verantwortet wurden. Zwei dieser Arbeitspakete hatten dabei einen übergreifenden Charakter: die Infrastruktur und das Testmanagement.
Standardisierte Teststruktur
Für das Testkonzept wurde eine bankenweit standardisierte Struktur vorgegeben, welche den Fortschritt der Konzepterstellung gesteigert und die Konzeptionierung im Laufe der Migrationen nach anfänglichen Einarbeitungsschwierigkeiten eindeutig beschleunigt hat. Mit der Erstellung des ersten Testkonzepts haben Gespräche zum Inhalt eines jeden nächsten Testkonzeptes mit den Verantwortlichen für das jeweilige SAP-Paket einen standardisierten Verlauf genommen. Dies hat zu einer wesentlichen Effizienzsteigerung in der Konzeptionsphase geführt.
Im Laufe der Tests stellte sich heraus, dass diverse technische Probleme (zum Beispiel fehlende Zugriffe auf die Testplattform, Testdaten, Datenbank et cetera) gelegentlich außerhalb des Testrahmens behandelt wurden. Es war für die technischen Tester einfacher, technische Schwierigkeiten in bilateraler Kommunikation zu klären, ohne sie noch als Fehler zu definieren und formell im Testsystem HPQC zu dokumentieren. Der Testmanager musste aus diesem Grund zwischen technischen "Schwierigkeiten", die durch bloße Kommunikation beseitigt werden konnten, und echten technischen Fehlern unterscheiden, welche im Testsystem revisionssicher dokumentiert werden mussten.
Test-Kickoff
Der Testmanager hat laut Teststandards kurz vor dem Start der Testdurchführung einen Test-Kickoff zu organisieren. Auch dann, wenn die Tester bereits mehrere Testvorgänge im SAP-Bereich absolviert haben, erweist es sich als sinnvoll, den Testern gewisse Grundsätze der Tests in einer kurzen Veranstaltung (Dauer etwa 30 bis 60 Minuten) noch einmal in Erinnerung zu rufen. Im Test-Kickoff werden für gewöhnlich die wesentlichen Punkte des Testkonzepts inklusive Testplanung (das heißt Anfang und Ende der einzelnen Teststufen) herausgestellt. Des Weiteren werden Gesprächspartner für technische Probleme und Verarbeitungsfehler (defects) genannt, Anforderungen an die Testdokumentation gegeben und der Testprozess wird erläutert.
Während der Test-Kickoffs für einzelne SAP-Pakete wurden vor allem Fragen zu Testinhalten, eigener Verantwortung der Tester und erwarteter Testaktivität gestellt und gleichzeitig mögliche Antworten/Optionen im Team diskutiert. Besonders das Thema Testdokumentation wurde genau beleuchtet, um eine revisionssichere Ablage aller Ergebnisse im Testsystem sicherstellen zu können. Themen, die im Test-Kickoff nicht genug Aufmerksamkeit erfahren konnten, wurden für weitere Analysen mitgenommen. Es kam auch vor, dass der Testmanager ein Test-Kickoff mit einer Liste der Aufgaben/Fragen verließ, die kurzfristig geklärt werden mussten.
Reibungslose Abläufe sicherstellen
Mit dem Start der Testdurchführung müssen die Tester über Kontaktdaten relevanter Testverantwortlicher verfügen (eine Beispielliste der notwendigen Kontaktpersonen enthält Tabelle 1).
Insbesondere war der Dispatcher für einen reibungslosen Ablauf der Defect-Verarbeitung verantwortlich. Der Dispatcher sorgte dafür, dass die zuständigen Entwickler nach einer Fehlermeldung den Fehler bearbeiten, Verbesserungsmaßnahmen identifizieren und nach Anpassung der Programme/Abläufe den Testfall zur Wiederholung melden. Die abschließende Kommunikation zwischen Programmierer und Tester erfolgte im Testsystem HPQC. Entsprechende Statusfelder über gemeldete Fehler geben den Testern Aufschluss über die Notwendigkeit einer erneuten Testdurchführung.
Die Verfügbarkeit der Testplattformen wurde im Laufe der Tests ständig überwacht. Insbesondere bei speziellen Testfällen (zum Beispiel Performance Tests) stand die Testplattform nicht für alle Tester zur Verfügung. Aus diesem Grund wurden die Tester regelmäßig über die Verfügbarkeit der Testplattformen informiert. Dies gab ihnen mehr Sicherheit für Testaktivitäten in der komplexen und dynamischen Umgebung vieler gleichzeitig zu testender technischer Komponenten.
Technische Schwierigkeiten
Im Laufe der Migrationen der einzelnen SAP-Pakete konnte festgestellt werden, dass es Zusammenhänge und technische Elemente/Komponenten gibt, die bei nahezu allen Migrationen beachtet werden müssen. Daher wurden die folgenden Testobjekte zu den wichtigsten Testgegenständen im Bereich der SAP-Technik zusammengefasst:
- Ein korrekt funktionierender TMS-Anschluss.
- Ein abgeschlossenes iface-Verzeichnis.
- Signierte und implementierte Zertifikate.
- Angepasste RFC-Verbindungen in externen Partnersystemen.3)
- Ein funktionierender Zugriff auf Webservices aus dem migrierten System via Webdispatcher.4)
Häufig entstehen Fehler aus rein technischer Komplexität heraus, zum Beispiel kann der Webdispatcher auch bei einer korrekten Installation und Ausstattung mit Zertifikaten nicht vollständig funktionieren, wenn eine entsprechende Firewalleinstellung noch nicht angepasst worden ist. Die Prüfung der Funktionsfähigkeit der Links kann beispielsweise erst dann stattfinden, wenn der Webdispatcher bereits funktioniert, da die zu testenden Links auf Webservices zugreifen. Bei der Link-Umstellung kann es wiederum sein, dass man nicht die Alias-Namen der ABAP-Server nutzen kann, sondern die der Webdispatcher verwenden muss.
Organisatorische Herausforderungen
Reihenfolge der Tests: Aufgrund der Komplexität und der typischerweise kurzen Projektzeiten für SAP-Migrationen stehen viele der notwendigen Testaktivitäten erst kurz vor dem Teststart fest. Dies führt gelegentlich zu kurzfristigen Anpassungen der Testplanung, welche sich automatisch auf eine große Anzahl technischer und fachlicher Tester (zum Beispiel im Bereich SAP HR oder SAP ReLo) auswirken. Des Weiteren haben die Anpassungen auch eine Auswirkung auf die Testdatenbasis, weswegen bei der Planung der Testdurchführung eine gewisse Reihenfolge gilt:
- Tests, die einen stabilen und gegebenenfalls unveränderten Datenbestand benötigen, sollten zuerst durchgeführt werden,
- Tests, in deren Verlauf die Daten einer Änderung unterliegen, sollten im zweiten Schritt durchgeführt werden.
Auch dann, wenn die technischen Möglichkeiten es erlauben, den Testdatenbestand immer wieder in den originalen Zustand zurückzuführen, reduziert die Einhaltung der obigen Reihenfolge die Komplexität der Planung der Testfalldurchführung (insbesondere bei mehrstufigen Testfällen).
Generell unterscheiden sich die Inhalte der fachlichen Testfälle (Teststufe Systemtest) der einzelnen Migrationen stark voneinander, da die fachlichen Schwerpunkte der einzelnen SAP-Pakete weitgehend divergieren. Der Teil der technischen Tests dagegen, der sich mit der grundsätzlichen SAP-Technik (SAP-Basistests) auseinandersetzt, weist dagegen solide Stabilität der Inhalte auf. Die SAP-Basistests stellen in jeder Systemmigration vor allem die Fehlerfreiheit der migrierten SAP-Installation durch die Prüfung der Aufrufe der Haupttransaktionen, Backup/Restore- und Disaster/Recovery-Prozeduren sicher. Für gewöhnlich initiieren die SAP-Basistests die geplanten Teststufen5), erst dann folgen die restlichen technischen und fachlichen Systemtests (nicht selten parallel, sofern sich dies auf die Abarbeitung der Testfälle nicht störend auswirkt).
Nebeneffekte der Fehlerbearbeitung entdecken
Die fachlichen Abnahmetests haben primär die Aufgabe, mögliche Nebeneffekte der Fehlerbearbeitung, die in Retests nicht direkt festgestellt wurden, zu entdecken. Je nach Anzahl und Schwere der in den Systemtests festgestellten Defects, werden passende Testfälle aus dem Testportfolio ausgewählt und im Rahmen der Abnahmetests noch einmal durchgeführt. Abschließend werden mit dem sogenannten Annahmetest die bereits im Systemtest getesteten Hauptfunktionalitäten im Produktionssystem erneut grob überprüft.
Die Reihenfolge der Testfalldurchführung wird zusätzlich durch die Verarbeitungsschritte im System bestimmt. So kann zum Beispiel keine Prüfung der Gehaltsabrechnung stattfinden, solange keine Batchverarbeitung der Gehaltsabrechnung stattgefunden hat. Wenn diese jedoch nur einmal im Monat stattfindet und dadurch nur einmal im Test angetriggert wird, müssen die dafür relevanten Tests auf der Zeitschiene sorgfältig eingeplant werden. Einen ersten Eindruck von der zeitlichen Staffelung am Beispiel eines Basistests gibt Abbildung 2.
Analyse der Software-Umgebung
Für die Einsatzplanung der Tester ist die technische Verfügbarkeit des Testsystems Grundlage. So können die geplanten Testfälle zum Beispiel diverse Batchprozesse und -verarbeitungsschritte überprüfen. Allerdings kann während intensiver Batchverarbeitungsläufe der Zugriff auf das Testsystem gesperrt werden und damit den Test anderer Testfälle unmöglich machen. Daher ist es sinnvoll, gewisse batchbezogene Testfälle zu gruppieren und gegebenenfalls in der nächtlichen Verarbeitung zu platzieren, damit die Tester am Tag ungestört arbeiten können.
Die Migrationen der SAP-Systeme erfolgen selten parallel, normalerweise geschieht dies nacheinander entlang der Zeitschiene, um die Komplexität der einzelnen Verarbeitungsschritte und Schnittstellen zu entflechten. In vielen Fällen werden auch die Schnittstellen zwischen den unterschiedlichen SAP-Paketen gesondert getestet. Daher ist es wichtig herauszufinden, ob die Prüfung einer Schnittstelle voraussetzt,
a) dass sich die beiden über die Schnittstelle verbundenen SAP-Systeme bereits auf der neuen, migrierten Plattform befinden müssen,
oder
b) ob die Schnittstelle zwischen dem migrierten und dem noch nicht migrierten SAP-System in der alten Umgebung getestet wird.
Eine unzureichende Analyse der notwendigen Software-Umgebung ist in Migrationsprojekten als potenzielles Risiko anzusehen. Wenn die Anforderungen für die Testdurchführung im Bereich der Schnittstellenverfügbarkeit im Vorfeld nicht ausreichend analysiert werden, kann es passieren, dass es in diesem wichtigen Segment schließlich gar nicht zur Testdurchführung kommt.
Performancemessung: Einer der Gründe für die Durchführung technischer Migrationen ist die Aussicht auf eine Performanceverbesserung, die durch den Einsatz neuer, dem SAP-System zugrunde liegender Hardware eintritt. Mithilfe spezieller Tools kann die Performance gemessen werden, wobei die Simulation des Zugriffs auf eine der Eingabe/Ausgabe-Masken eine aufwendige Option darstellt. Einfacher kann die Performance durch den Vergleich der Verarbeitungszeit, zum Beispiel Verarbeitung der Gehaltsabrechnung von Alt- mit Neusystemen, gemessen werden. Bei dieser zweiten Option müssen mehrere wichtige Punkte bedacht werden, um eine aussagefähige Vergleichbarkeit sicherzustellen - so muss beispielsweise die Anzahl der Batchprozesse auf beiden zu vergleichenden Systemen identisch sein.
Als potenzielles Risiko für die Performancemessung gilt der mögliche Mismatch der Vergleichsbedingungen, zum Beispiel wenn in der Gehaltsabrechnung auf dem Altsystem für jede Personalnummer mehrere Tage abgerechnet werden müssen, während auf dem neuen System nach der Systemkopie nur ein Tag verarbeitet wird und dies dann miteinander verglichen wird. Ähnlich würde der Vergleich zwischen Tages- und Nachtverarbeitung misslingen, da im Nachtbetrieb doppelt so viele Batches wie in der Tagesverarbeitung laufen.
Eine technisch ungünstige Lastverteilung verringert die Performance - eine Anpassung der Instanzverteilung kann die Infrastruktur wesentlich performanter machen. Gelegentlich kann auch die Anpassung der Serverkonfiguration oder die Identifizierung einer fehlenden Portfreischaltung auf der Datenbankebene des migrierten Systems die Performance erhöhen.
Testfortschrittsbericht
Die Literatur im SAP-Umfeld fordert in Berichten eine gewisse Stringenz über den Testfortschritt. Vivenzio & Vivenzio6) schlagen eine zeitbezogene Überwachung des Testtempos über eine Verhältniszahl vor: "(...) diese Kennzahl setzt eine detaillierte Planung voraus. Es ist nicht ausreichend nur die Anzahl getesteter Testfälle im Verhältnis zur Gesamtzahl der Testfälle zu betrachten. Vielmehr müssen die Testfälle in ihren zeitlichen Bezug gebracht werden. Dies bedeutet, dass beispielsweise auch zu planen ist, welche Testfälle wann getestet werden sollen. Die Planung kann je nach Projekterfordernissen auf täglicher, wöchentlicher oder monatlicher Basis erfolgen. Die Kennzahl ermittelt sich aus: Anzahl geplanter Testfälle je Zeiteinheit/ Anzahl tatsächlich durchgeführter Testfälle je Zeiteinheit."
Diese Verhältniszahl wurde zwar ermittelt, hatte im Migrationsprojekt aber ausschließlich informativen Charakter für das Testmanagement, jedoch keinen direkten Einfluss auf die bestehenden Ziele/Testfortschritt im Projekt. Die geforderte Stringenz resultiert vor allem aus der folgenden Annahme: "Durch die Zeitplanabweichungen des Testprojekts (Testfortschritt} wird unweigerlich auch das gesamte Projekt (Projektfortschritt) beeinflusst. Diese Aufgabe obliegt dem Testmanager, der wiederum dadurch den Projektmanager unterstützt, den Zeitplan fürs Projekt einzuhalten."7)
Lessons learned
Die Erfahrung im Beispielprojekt hat gezeigt, dass die genaue Überwachung der Zeitplanung aller einzelnen Testaktivitäten auf der Zeitschiene bei großen SAP-Migrationsprojekten recht komplex ist. Um die Komplexität des Testmonitorings zu reduzieren, galten bei der Testplanung vielmehr die allgemeineren Testmeilensteine (zum Beispiel Ende Testvorbereitung, Ende Testdurchführung, Testabnahme) als besonders wichtig, weswegen diese täglich überwacht und besprochen wurden. Auf diese Weise konnten Projekt- und Programmmeilensteine erfolgreich eingehalten werden, während auftauchende Probleme und Schwierigkeiten meist direkt und zeitnah im Team bewältigt wurden (siehe Tabelle 2).
Schnittstellen: Das Problem der Schnittstellen betraf einerseits die Schnittstellen in der Kommunikation und andererseits technische Schnittstellen in der Systemwelt. Es wurde bei jeder Migration erneut die Frage gestellt, wer denn involviert ist. Eine Abhilfe verschaffte das Zentrale Registrierungssystem aller Anwendungen mit fachlichen und technischen Ansprechpartnern. Mit dessen Hilfe konnten notwendige Teilnehmer der Migration, die wegen Schnittstellenverantwortung mitwirkten, identifiziert werden als auch alle eingebundenen Parteien zum rechten Zeitpunkt in das Migrationsgeschehen integriert werden. Anschließend war es erforderlich, die Aktivitäten der identifizierten Parteien sinnvoll zu überwachen, um potenzielle Verzögerungen kurzfristig zu identifizieren und entsprechende Maßnahmen zu entwickeln.
Die Thematik der Schnittstellen gewinnt im Hinblick auf die Multinationalität von SAP-Installationen noch mehr an Bedeutung. Im Beispielsprojekt waren drei nationale Einheiten (Deutschland, Großbritannien und Tschechien) involviert, deren Ansätze trotz globaler Standards aufgrund von kulturbezogenen Begebenheiten und unterschiedlichem Verständnis der Regeln stark voneinander abwichen.
Mengenproblematik: Das Problem der Mengen ist mit dem Schnittstellenproblem eng verbunden. Die SAP-Systemmigration betraf viele IT-Bereiche des Kreditinstituts. Je nach Arbeitspaket wurden weitere verschiedene Bereiche (Archivierung, externe Partner, technische Bereiche wie SAP-Basis, UC4, ComDirekt, Firewalls, Links et cetera) involviert, wobei die Notwendigkeit der Zusammenarbeit mit den jeweiligen Bereichen zu Anfang des Projektes nicht immer ersichtlich war. Ähnlich war es mit den involvierten Mitarbeitern. Während nur selten Spezialisten für Performance-Messung, Firewalls oder Archivierung benötigt wurden, wirkten SAP-Basis, Delivery Management und UC4-Spezialisten in jedem Teilprojekt mit.
Lehrreiche Erfahungen
Bereits am Anfang der Projektarbeit kristallisierten sich wesentliche technische Erkenntnisse heraus, welche für darauffolgende Migrationen effektiv genutzt wurden:
- Zugriff auf SAP-Systeme beim Einsatz einer Firewall: in einzelnen Fällen wurden Tests durch Firewalleinstellungen verhindert. Es hat sich gezeigt, dass eine reine Systemmigration auch eine neue Parametrisierung der Firewall nach sich ziehen kann.
- Autorisierung für IP-Adressen: Die Tester müssen über eine geeignete Autorisierung für eigene IPs bei dem Zugriff auf die verlinkten Programme verfügen.
- Der Test des Datenaustauschs mit externen Partnern erfordert zusätzliche organisatorische Maßnahmen und eine genaue Zeitplanung. Es muss bedacht werden, dass die externen Parteien gelegentlich über keine Testsysteme für den Datenübertragungstest verfügen.
- Die eingebetteten Links in E-Mails, Programmen und Scripts stellen grundsätzlich eine Gefahr für eine rechtzeitige Produktionsübernahme eines migrierten Systems dar. Für gewöhnlich gibt es keine Listen der verwendeten Links und diese können nur durch umfangreiche und gegebenenfalls lückenhafte Analysen gefunden werden. Erst in Tests werden mehrere relevante Links identifiziert, die eventuell angepasst/umgestellt werden müssen. Daher wurde empfohlen, die Nutzung der Links zentral zu registrieren und zu verwalten.
- Namensänderungen der Verzeichnisse, Programme, Datenbestände, Skripte und Jobs führten gelegentlich zu unvorhersehbaren Verarbeitungsabbrüchen. Daher sollten alle denkbaren Namenänderungen im Rahmen einer Migration im Vorfeld in Sitzungen zwischen dem technischen Team und den Testern abgestimmt werden.
Es gab auch organisatorische Stolpersteine, deren Erkenntnis die Effizienz der Projektarbeit wesentlich verbessert hat:
- Die Vertretung von Testmanagern, Dispatchern und Verantwortlichen für die Testplattformen im Falle einer Krankheit beziehunsgweise eines Urlaubes sollte von vornherein geklärt sein.
- Parallel agierende Migrationsarbeitspakete generierten für das Projekt- und Testmanagement eine signifikante Anzahl an zusätzlichen Projektsitzungen. Es sollte frühzeitig eine Priorisierung der Arbeitstreffen eingeführt werden, damit die Zeit für Sitzungen die effektive Linienarbeit im Projekt nicht übersteigt.
- Die Analyse der Schnittstellen sollte gleichzeitig die Frage beantworten, ob das angeschlossene System ebenfalls auf der neuen Hardware-Plattform erwartet wird oder ob die Schnittstelle die alte Hardware-Plattform des angeschlossenen Systems voraussetzt.
- Es ist sinnvoll, einen zentralen Testcontainer mit Testfällen für alle SAP-Migrationen im Testsystem zu nutzen (zum Beispiel nur ein einziges HPQC-Projekt), da ansonsten die Defektbearbeitung fragmentiert und aufwendig werden kann. Gleichzeitig wird die Nutzung der Erkenntnisse aus den bearbeiteten Defects in den unterschiedlichen Migrationsprojekten durch die Zentralisierung der Testdurchführung und Defektbearbeitung erheblich erleichtert.
Werden die soeben besprochenen Aspekte nicht berücksichtigt, kann sich das negativ auf ein SAP-Migrationsprojekt auswirken. Im Laufe des Beispielprojekts wurden Erkenntnisse aus den bereits abgeschlossenen Einzelmigrationen direkt in den nächsten Migrationen berücksichtigt. Um die Fehler vergangener Migrationen bei weiteren Migrationen nicht zu wiederholen, wurden die identifizierten technischen Problempunkte zu Anfang der jeweils neuen technischen Tests sorgfältig ausgetestet. Dadurch konnten ein reibungsloser Ablauf der anschließenden fachlichen Tests und eine termingerechte Testabnahme gewährleistet werden.
Es gab natürlich auch positive Erkenntnisse aus der Migrationsarbeit, die ebenfalls in den Bereich Lessons learned gehören. Sie stellen quasi die Basis für den Erfolg in der komplexen Umgebung der Systemmigrationen dar, die in keinem Migrationsprojekt fehlen darf.
- Der sehr persönliche Einsatz der Projektverantwortlichen war vor allem in der guten Kommunikation über involvierte Abteilungen und im guten Teamwork bei Abstimmungs- und Problemlösungsrunden spürbar.
- Die Struktur der regelmäßigen Projekttreffen und eingespielten Projektprozesse trugen wesentlich zur Transparenz im Projektfortschritt und bei deren Dokumentation bei.
- Die Verwendung eines zentralen Testsystems als Kommunikationsschnittstelle und Basis der Testprozesse erlaubte eine effizienzsteigernde Wiederverwendung von Teststrukturen und Testfällen.
Fußnoten
1) http://www8.hp.com/h20195/V2/getpdf.aspx/ 4AA5-5334ENW.pdf?ver=1.0; SAP batch transactions now run up 10x faster, improving user productivity and efficiency
2) http://www.lynx.de/deutschemessemigriertsap.html; Die Kennziffern zu Auslastung, Leistungsfähigkeit und erwartetem Wachstum der Vorstudie nutzte die Deutsche Messe AG als Grundlage, um Angebote verschiedener Hersteller für beide Zielplattformen einzuholen und zu vergleichen. "Es zeigte sich schnell, dass Linux auf Intel eindeutig die kostengünstigere Alternative ist", berichtet Marcus Kleen. Im Vergleich zu den bisherigen Systemen bot eine Linux-/Intel-Plattform die vierfache SAPS-Leistung zu einem Drittel der damaligen Kosten. Der Kostenvorteil hat auch bei aktuellen SPARC-Servern mit vergleichbarem Leistungsniveau Bestand.
3) Hier spielt der Test eine wesentliche Rolle, um die jeweils relevanten RFC-Verbindungen zu identifizieren und in der produktiven Umgebung zu berücksichtigen.
4) Es muss zuerst der Webdispatcher installiert und mit Zertifikaten ausgestattet werden. Darüber hinaus darf er keine Fehler in seinen Logs aufweisen.
5) Die im Kreditinstitut verwendeten Teststufen umfassen Modultests, Systemtests (fachlich und technisch), Abnahmetests als Bestandteil der Testabnahme und Annahmetests für die Plausibilisierung der Produktionsversion des Systems.
6) Testmanagement bei SAP-Projekten: Erfolgreich Planen Steuern ·Reporten bei der Einführung von SAP-Banking. Alberto Vivenzio, Domenico Vivenzio, Springer-Verlag, December 13, 2012, S. 33.
7) Software - Test it profession@lly!: Ausbildung für Softwaretester basierend auf ISTQB- & IREB-Standards, Anja Kribernegg, Cyberpublishing E-Verlag GmbH, January 14, 2014, S. 162.
