Testaspekte multipler Umsetzungen in der IT-Landschaft

Tadeusz Skolka Foto: PPI AG

Die Umsetzung der Abgeltungssteuer, die jetzt wieder zur Disposition steht, die Einführung von MiFID II und auch die noch laufenden Vorbereitungen für die Datenschutzgrundverordnung sind Beispiele für äußerst umfangreiche Eingriffe in die IT-Landschaft von Banken. 50 oder gar 100 Systeme an die Neuregelungen anpassen zu müssen, ist bei solchen Großprojekten keine Seltenheit. Am Beispiel eines MiFID-II-Projektes verweist der Autor bei der praktischen Umsetzung auf diverse Koordinationsschwierigkeiten im fachlichen als auch im technischen Bereich. Die Kunst sieht er darin, die Testvorbereitung und -durchführung in den heutigen komplexen IT-Architekturen auf wenige auffallende Parameter zu beschränken und kostspielige Trial-and-error-Ansätze zu vermeiden. (Red.)

Im Laufe der letzten Jahre wurden mehrere regulatorische Anforderungen im Finanzwesen formuliert, deren Umsetzung sich nicht nur auf ein einzelnes, sondern auf mehrere IT-Systeme gleichzeitig ausgewirkt hat. Dabei konnte es sich, je nach Größe des Finanzinstituts und abhängig von der Komplexität der IT-Landschaft, um Anpassungen an zirka 100 Systemen handeln. In umfangreichen Tests musste festgestellt werden, ob die Systeme nach der Implementierung der Änderungen sich entsprechend den Anforderungen verhalten oder eine weitere Systemadjustierung notwendig ist.

Erfahrungen aus einem MiFID-II-Projekt

Die Testkomplexität in solchen Projekten wird vor allem durch die Parallelität der Umsetzung und der Tests einzelner IT-Systeme erzeugt. Als Beispiel für solche Projekte kann die Umsetzung der Abgeltungssteuer vor ein paar Jahren beziehungsweise aktuell die MiFID-II-Implementierung aufgeführt werden.

Leider bietet die einschlägige Testliteratur derzeit nur sehr geringe methodische Unterstützung bei Projekten mit multiplen Umsetzungen innerhalb einer IT-Landschaft. Sie konzentriert sich aus Gründen der Praktikabilität nahezu zu 99 Prozent auf Tests von Einzelsystemen. Der vorliegende Aufsatz über Testaspekte multipler Umsetzungen basiert auf Erfahrungen aus einem MiFID-II-Projekt mit Anpassungen einer IT Landschaft von zirka 50 Systemen.

Das Ziel der EU-Richtlinie und somit der Überarbeitung von MiFID II ist die Verbesserung des Anlegerschutzes und des Wettbewerbs innerhalb der EU. Ausdrücklich erwünscht war die Verlagerung des gesamten Handels auf regulierte Handelsplätze, insbesondere bei Derivaten, die bisher außerbörslich gehandelt und von den bisherigen Regulierungen nicht erfasst wurden.

Erweiterung des Umfangs (neue Finanzinstrumente), Beschleunigung der Meldezeiten und weitere Detaillierung der Meldungen an die Aufsichtsbehörden (insbesondere Vor- und Nachhandelstransparenz) stellten neben der Anreicherung der Systeme um MiFID-II-Attribute (sogenannte Sicherstellung der MiFID-II-Fähigkeit) den Hauptschwerpunkt der IT-mäßigen Anpassung dar.

Ständig wachsende IT-Komplexität

Die bestehenden IT-Architekturen der Finanzinstitute werden kontinuierlich weiterentwickelt, verbessert und erweitert, um Fehler der Verarbeitung zu beseitigen, fehlerhafte Prozesse zu eliminieren und neu geforderte innerbetriebliche Prozesse zu integrieren. Das Ergebnis ist eine ständig wachsende integrierte IT- Komplexität. Bei der Umsetzung neuer gesetzlicher Anforderungen ist generell ein Teil der relevanten IT-Architektur betroffen, wobei die Wirkungen der Komplexität auf die Umsetzung (und umgekehrt) meist zu Anfang nicht überschaubar/einsehbar sind.1) Der gewählte Testansatz muss dazu geeignet sein, die Komplexität des Software-Portfolios berücksichtigen zu können, indem passende organisatorische Maßnahmen vorgeschlagen, technische Testunterstützung aufgebaut und adäquate methodische Richtlinien für das Projekt verabschiedet werden.

Die Implementierung neuer Anforderungen in komplexen IT-Architekturen darf natürlich aus einer Vielzahl von Gründen2) keine negativen Konsequenzen auf die Datenqualität haben. Die erwartete Datenqualität kann wiederum nur durch geeignete Tests herbeigeführt und erhalten werden.

Neben den System- und Abnahmetests innerhalb der Einzelsysteme, die nach jeder Systemänderung notwendig sind, wird in Projekten mit multiplen Änderungen der IT-Landschaft ein strategisches Testmanagement auf der Gesamtprojektebene benötigt. Im ersten Schritt müssen die Verantwortlichen und deren Testaufgaben identifiziert werden. Welche Aufgaben fallen im Bereich der Releasetests (das heißt System- und Abnahmetests einzelner IT-Systeme) an? Welche Aufgaben übernimmt das zentrale Testmanagement? Das Ergebnis der Aufgabenanalyse ist in Abbildung 1 anschaulich dargestellt.

Im Rahmen des MiFID-Projektes hat es zirka 60 bis 65 Produktionsübernahmen der geänderten IT-Systeme (Release) gegeben. Die Tatsache, dass die Anzahl der Release, die Anzahl der involvierten Systeme (50) um zirka 20 bis 30 Prozent übersteigt, weist darauf hin, dass es im Laufe des Projektes einzelne Systeme mit mehreren Releases gab, während es sich bei den meisten IT-Systemen um ein einziges Release für MiFID-II-Anforderungen handelte.

Es gab größere beziehungsweise intensiver genutzte Systeme, wie zum Beispiel die, die aufgrund der Anforderungen aus MiFID II sowie aus Anforderungen aus anderen Projekten mehrerer Releases bedurften, während für andere Einzelsysteme lediglich ein Release für die Umsetzung der MiFID-Anforderungen notwendig war.

Bei jedem Release handelte es sich um eine der drei Arten:

- MiFID-II-Release - ein Release mit der Umsetzung der MiFID-II-Anforderungen,

- Mischrelease - ein Release mit der Umsetzung von sowohl MiFID II als auch anderen Anforderungen (aus sonstigen Projekten),

- "not relevant" - ein Release, das keine Umsetzung der MiFID-II-Anforderungen beinhaltet.

Die Unterscheidung in die verschiedenen Releasearten half dabei, die Intensität der Projektunterstützung beim jeweiligen Releasetest einzuschätzen. Während bei MiFID-Releases die aktive Teilnahme der Projektmitarbeiter an System- und Abnahmetests Voraussetzung war, wurde bei "Not relevant"-Releases lediglich darauf geachtet, dass Regressionstests zur generellen Überprüfung der Funktionsfähigkeit des jeweiligen Systems zum Einsatz kamen und Fehler mit einer hohen Priorisierung erfolgreiche Retests erfuhren (Abbildung 2).

Fachliche Testabnahme

Bei der Betrachtung der MiFID-II-Testkomplexität stellte sich die Frage, wie und wann die fachliche Gesamtabnahme der kompletten technischen Umsetzung erfolgen soll. Drei Alternativen standen zur Debatte: Am Ende des Projektes für alle Systeme mit der Implementierung aller MiFID-II-Anforderungen; Stufenweise, also nach jedem Releasesystem- und Abnahmetest mit teilweiser Implementierung der MiFID-II-Anforderungen oder nach erfolgreichem Ergebnis der Gesamtintegrationstests.

Die erste Alternative würde bedeuten, dass zuerst alle Anforderungen vollständig in den relevanten Systemen implementiert werden, bevor eine fachliche Abnahme aller implementierten Anforderungen erteilt werden kann. Die Alternative wurde nach einer eingehenden Analyse verworfen, da die Komplexität der vollständigen MiFID-II-Implementierung in Systemen eine übermäßig große Anzahl etwa der technischen Betreuer, fachlichen Tester, Testdatenbestände und Testmanager über eine lange Zeit erfordern würde. Die relevanten Testplattformen wären für andere Projekte nicht verfügbar. Zusätzlich müssten Anforderungen in der technischen Implementierung in den einzelnen Systemen untereinander unbedingt abhängig sein (dies war meist nicht der Fall).

Die zweite Alternative erlaubte die parallelen Tests von mehreren Anwendungen und eine direkte fachliche Testabnahme nach jeder Implementierung in einem Einzelsystem.

Gleichzeitig mussten die funktionellen Abhängigkeiten der Implementierungen der MiFID-Anforderungen in Einzelsystemen durch Gesamtintegrationstests validiert werden. Somit ist zwangsläufig die dritte Alternative der Gesamttestabnahme mit der Geltung eines fachlichen Gütesiegels für das Gesamtprojekt entstanden. Sowohl die zweite als auch die dritte Alternative bestimmte im Endeffekt die fachliche Testabnahme im Projekt MiFID II.

Als eine wesentliche Gefährdung des Testfortschritts hat sich die unstabile Terminierung der Einzelsystemreleases entpuppt. Die Releaseplanung für Einzelsysteme der MiFID-IT-Landschaft konnte nur für kurze Zeit (zirka 1,5 Monate) eine akzeptable Verlässlichkeit aufweisen. Alle Releasetermine in weiterer Zukunft (alles über 2 Monate) wurden meistens nur als Platzhalter betrachtet und wurden mit hoher Wahrscheinlichkeit im Laufe der Zeit sowohl terminlich als auch inhaltlich (Releaseumfang) mehrmals angepasst.

Die häufige Änderung der Releasetermine stellte ebenfalls ein Problem für die Stabilität der Testplanung dar und erzwang häufige und langwierige Reviews.

Zentrales Testmanagement im MiFID-II-Projekt

Die Einrichtung des zentralen Testmanagements in einer komplexen IT-Umgebung war stark kontext-sensitiv und musste daher sorgfältig konstruiert werden. Es wurde grundsätzlich zwischen Monitoring und operativen Aufgaben unterschieden.

Monitoring: Einen relativ umfangreichen Anteil der Aufgaben des zentralen Testmanagements großer Projekte mit multiplen Änderungen innerhalb der IT- Landschaft bildet die Ausübung der Monitoring-Funktion. Es werden dabei Fragen gestellt, wie sichergestellt werden kann, dass alle Anforderungen lückenlos umgesetzt, rechtzeitig getestet und durch relevante Fachabteilungen abgenommen werden.

Eine eingehende Analyse des Informationsbedarfs führte zur Identifizierung folgender Aufgabenbereiche für das Monitoring im zentralen Testmanagement: Testkonzepte, Testobjekte, Releasetermine, Testfälle, Verknüpfungen in HPQC und Defekte.

Bei jedem Release mussten im Rahmen der Testvorbereitung die in Abbildung 3 dargestellten Aktivitäten im Testsystem HPQC durchgeführt werden. Besonders die Sicherstellung einer lückenlosen Verknüpfung zwischen Anforderungen, Releases und Testfällen im Rahmen des Monitoring stellte einen wesentlichen Beitrag zur Erreichung der erforderlichen Qualität der Testvorbereitung dar. Durch die Verknüpfungen konnte jederzeit überprüft werden, welche MiFID-Anforderungen in einem bestimmten Release geplant beziehungsweise umgesetzt wurden oder durch welche Testfälle die Umsetzung einer gegebenen Anforderung getestet wurde.

Von der Erfassung bis zur Überwachung

In der Testdurchführung beinhaltete dagegen das Monitoring vor allem die Erfassung, Dokumentation und Behandlung der identifizierten Defekte, Prüfung der erstellten Testdokumentation nach erfolgreichen Tests und Überwachung der fachlichen Testabnahmen einzelner Releases.

Grundsätzlich betrifft das Monitoring in der Phase der Testvorbereitung alle betroffenen Systeme gleichzeitig. Im Testmanagement ergab sich aber keine Zeitabhängigkeit zwischen Testvorbereitung- und Testdurchführung, wie das bei Einzelsystemtests der Fall ist. Die Testvorbereitung für einen Teil der Systeme wurde zur gleichen Zeit wie die Testdurchführung in anderen Systemen durchgeführt. Diese Situation dauerte nahezu bis zum Ende des MiFID-Projektes. Lediglich bei der Durchführung der Gesamtintegrationstests ergab sich eine zeitliche Abhängigkeit - die meisten Releasetests mussten vor dem Start der Systemintegrationstests abgeschlossen sein.

Das Monitoring der Testdurchführung hatte auch die Aufgabe, die Revisionsfähigkeit der Tests zu gewährleisten. Moniert wurde dabei vor allem die gelegentlich fehlende Testdokumentation der durchgeführten Tests.

Im Hinblick auf zu erstellende Testkonzepte wurde entschieden, dass im ersten Schritt eine Testvorgabe (MiFID-II-Testkonzept) geschrieben wird, mit dem Charakter - eines Testrahmens für alle Testaktivitäten an Einzelsystemen und gleichzeitig - eines Testkonzepts für alle wesentlichen Systemtestintegrationen im Projekt.

Meldungserstellung als der wichtigste Testgegenstand

Dieses zentrale Testkonzept beinhaltete auch Testobjekte für alle Releases der Einzelsysteme, die als "MiFID only"-Release galten, das heißt, sie enthielten ausschließlich die Umsetzung der MiFID-II-Anforderungen. Für Mischreleases, die nicht ausschließlich MiFID-II-Anforderungen enthielten, sowie für vier neue Systeme, die im Zuge des MiFID- Projektes entstanden sind, mussten relevante Systembetreuer separate Testkonzepte erstellen. Diese hatten häufig den Charakter eines rein formellen Dokumentes mit Referenzen auf das zentrale MiFID-Testkonzept.

Operative Aufgaben: Zusätzlich zum Monitoring galt es zu überprüfen, welche Testaufgaben im Gesamtprojekt nicht innerhalb der einzelnen Systemtests wahrgenommen werden und deswegen durch das zentrale Testmanagement operativ organisiert und durchgeführt werden müssten. Eine Analyse und mehrere Gespräche mit relevanten Stakeholdern haben schnell ergeben, dass alle Testaufgaben im Rahmen der Teil- und Gesamtintegration in diese Kategorie fallen.

Im Rahmen der Gesamtsystemintegration, die eine Voraussetzung für die Abnahme des gesamten MiFID-Projektes dar stellte, wurden die Prozesse der MiFID- Meldungserstellung als der wichtigster Testgegenstand ausgewählt.

Identifizierung und Zuordnung der Meldestrecken

Zu den MiFID-Meldungen gehörten neben Nach- und Vorhandelstransparenzberichten, auch EMIR- und Transaktionsberichte. In Gesprächen mit dem zu ständigen IT-Architekten musste die systemtechnische Abbildung der sogenannten technischen "Meldungsstrecken" samt dazugehörigen Schnittstellen innerhalb der IT-Architektur zunächst eindeutig identifiziert werden.

Anschließend wurden die Meldungsstrecken den dedizierten Projekt-Testanalysten zugeordnet, die mit der Aufgabe betraut wurden, den Ablauf der Meldestreckentests mit technischen Systembetreuern und Vertretern der relevanten Fachbereiche zusammen in Workshops zu analysieren, Testobjekte zu identifizieren und Testfälle zu konzipieren. Folgende Aufgabenbereiche mussten dafür in den jeweiligen Workshops konkretisiert werden:

- Technische Abstimmung der Datenweiterleitung/-anreicherung für Meldungen,

- Vorgehensweise beim Testen der individuellen Meldungserstellung, - Prozessumfang und Länge des technischen Datenablaufs ,

- Verfügbarkeit der Testdaten3) ,

- Terminierung der Testdurchführung (Ver fügbarkeit der individuellen Testsysteme innerhalb der Meldungsstrecken).

Insbesondere stellte die Frage nach dem zu testenden Prozessumfang eine Herausforderung für die Teilnehmer der Workshops. Es ging darum zu entscheiden, ob in den Tests die kompletten Meldungsstrecken oder lediglich Teile davon summarisch berücksichtigt werden sollten. Der Anfang und das Ende der technischen Prozesse zur Meldungserstellung, inklusive Datenübergänge zum Meldungsersteller (zum Beispiel Deutsche Börse AG oder DWP-bank) mussten entsprechend identifiziert und hinsichtlich Umfang bestimmt werden.

Rollen

Die Standardtestorganisation sieht die Rolle eines Testanalysten vor, der unter anderem für die Erstellung der Testfälle zuständig ist. Seine Verantwortung beschränkt sich aufgrund des notwendigen Know-hows typischerweise auf den Bereich eines einzelnen IT-Systems. Für die Betreuung der im beispielhaften MiFID- Projekt identifizierten Meldungsstrecken hingegen, die sich über mehrere IT-Systeme (bis hin zum externen Meldungsersteller) erstreckten, musste eine neue Testrolle konzipiert werden. Neben den Testanalysten, die in Tests der einzelnen Releases tätig waren, übernahmen weitere Mitarbeiter, in der Rolle der sogenannten Projekt-Testanalysten, eine wichtige systemübergreifende Koordination.

Entsprechend der Erkenntnisse des neuen Wissenschaftszweigs "Science of Networks"4) handelt es sich bei der Erweiterung der Testorganisation um die Rolle des Projekt-Testanalysten. Neben der Koordinationsaufgabe geht es um die Stärkung der rechtzeitigen testrelevanten Informationsgewinnung sowie um die Informationsverteilung in der formellen Testmanagement-Umgebung. Das ausdrückliche Ziel ist es, der immer größer werdenden Komplexität der IT-Landschaften eine Grundtransparenz zu verleihen. Auf der Basis der IT-Transparenz können die Produktionseignung und -sicherheit der multiplen Änderungen in der IT-Landschaft sichergestellt und nachvollzogen werden.

Der Projekt-Testanalyst wurde im betrachteten Projekt zum eigentlichen, operativen Koordinator innerhalb der ihm zugewiesenen Meldungsstrecken. Er holte periodische, wesentliche Statusinformationen für das Testmanagement ein, koordinierte die Reihenfolge sowie Durchführung testrelevanter Aufgaben, griff in die Vorbereitung und Abstimmung der Testumgebungen ein und unterstützte die Testfallerstellung durch Fachbereiche inklusive Übernahme der Testfälle in die Module Test Plan und Test Lab des Testsystems HPQC. Vor allem aber stimmte er Termine für die Testdurchführung ab und überprüfte die Verfügbarkeit der notwendigen Testdaten. Auch das Management der Verarbeitungsfehler gehörte zu seinem Verantwortungsbereich. Kurzum stellte der Projekt-Testanalyst innerhalb der ihm zugewiesenen Meldungsstrecken einen verlängerten operationellen Arm des Testmanagers dar.

Methodischer Ansatz durch die Nutzung eines Testsystems

Tests multipler Änderungen einer IT- Landschaft benötigen zwingend eine technologische Unterstützung, die meist durch Standardtestsysteme sichergestellt wird. Das bekannte Testsystem HPQC bildete im Beispielsprojekt eine geeignete Grundlage, die die gesamte Teststruktur abbilden konnte. Eine integrative Sicht entlang der wesentlichen testrelevanten Aktivitäten ließ sich in HPQC relativ vollständig abbilden. Es handelte sich dabei konkret um Anforderungen, Releases, Testfälle (Test Plan) und Testinstanzen (Test Lab).

Verpflichtende Grundsätze

Es war von Anfang an klar, dass das Volumen der Statusinformationen allein eine Schwierigkeit darstellte, da die Informationen kontinuierlich gewonnen werden mussten. Nur durch die stringente Nutzung eines zentralen Testsystems durch alle Systemverantwortlichen/Manager der Einzelsysteme, Testanalysen und Tester konnte der Informationsbedarf zum Teststatus gesättigt werden. Anders wäre die zentrale Überwachung des gesamten Testgeschehens im Projekt MiFID II nur durch einen unverhältnismäßig großen (ökonomisch unangemessenen) Ressourcenaufwand möglich. Aus dem Portfolio der verfügbaren Tools für das Testmanagement wurde das System HPQC ALM aufgrund des Umfangs der Funktionen als das für das Projekt MiFID II geeignete Tool identifiziert.

Für alle Testbeteiligten wurden folgende verpflichtende Grundsätze der Testaktivitäten im MiFID-Projekt aufgestellt, um eine effektive und reibungsfreie Arbeit mit HPQC zu ermöglichen:

1.) HPQC ist das einzige zu nutzende Test Management Tool.

2.) Alle Releasetermine müssen kurzfristig (direkt) in HPQC eingestellt werden.

3.) Alle Anforderungen müssen in HPQC mit Releases verbunden werden.

4.) Alle Testfälle im Testplan müssen MiFID-Projektinformationen enthalten.

5.) Alle Testfälle müssen in HPQC mit den Anforderungen verbunden werden.

6.) Defekte aus System- und Abnahmetests müssen Projektinformationen und Releaseangaben enthalten.

Auf die Einhaltung dieser Grundsätze wurde im Laufe des Projektes streng geachtet. Sie brachten ein gewisses Sicherheitsniveau in die sich ständig ändernde Umgebung der Inhalte, Termine und Umsetzung der Testaktivitäten in den zirka 50 Einzelsystemen. Rückblickend kann man sagen, dass die Einhaltung dieser Grundsätze in der breiten Basis aller Testbeteiligten einen Großteil zum Gesamterfolg des Projektes beisteuerte.

Defektmanagement

Für den Erfolg der MiFID-II-Tests war eine effektive Vorgehensweise für die Bearbeitung der identifizierten Fehler unabdingbar. Die Durchsetzung der neuen effektiven Prozesse war von großer Relevanz, denn es hat sich historisch bedingt eine IT-Kultur in Einzelbereichen der Bank etabliert, die für die Ziele der MiFID-II-Tests nicht immer förderlich war. So kam es bei der Betreuung der Einzelsysteme im Endeffekt vor, dass ein Teil der Verarbeitungsfehler während der System- und Abnahmetests nicht immer beziehungsweise selten dokumentiert wurde und die Fehlerbehandlung sich sogar außerhalb des Monitorings bewegte. Das Problem hatte meist folgende Ursachen:

- Die Betreuung einzelner Systeme erfolgte außerhalb der vorgegebenen automatisierten Testprozesse (statt HPQC wurden zum Beispiel Excel beziehungsweise E-Mail-Nachrichten für die Fehlerkommunikation verwendet).

- Die Geschwindigkeit der Entwicklung/ Fehlerbearbeitung machte die zum Teil aufwendige Dokumentation der Fehler in Defektsystemen überflüssig.

Die Transparenz der im Test identifizierten Verarbeitungsfehler wurde aus dem Grund wichtig, weil Ansätze der agilen Entwicklung in der IT verfolgt wurden. Die agile Entwicklung zieht die unmittelbare, informelle (und zugegebenermaßen effiziente) Kommunikation zwischen IT- und Fachabteilung dem formellen dokumentierten Entwicklungsprozess vor. Die gewonnen Erkenntnisse aus der engen Zusammenarbeit der IT und der Fachbereiche werden nicht immer lückenlos dokumentiert. Die Entwicklung ist aus diesem Grund effektiv, aber gleichzeitig schwierig nachzuvollziehen. Die Transparenz der Fehlersituation und -bearbeitung im Test hilft Strukturen in die Flexibilität der Agilität zurückzugewinnen.

Im Laufe der Testvorbereitungen wurde festgestellt, dass die bankenweit implementierten Testprozesse inklusive Methodik in einzelnen Bereichen nicht wie angenommen einheitlich, sondern recht unterschiedlich ausgelegt und angewendet wurden. Es gab deshalb Bereiche in der Bank, in denen sie kaum angewendet wurden, und es gab andere Bereiche, in denen sie musterhaft funktionierten. Die unterschiedliche Implementierung der Testprozesse verursachte gelegentlich auch menschliche Reibungsverluste und verringerte darüber hinaus die Effizienz der Testaktivitäten in einigen Systembereichen.

Konfliktpotenzial zwischen Projekt- und Testmanagement

Häufig entsteht in großen Projekten ein generelles Problem in der Zusammenarbeit zwischen Projektleitung einerseits und dem Testmanagement andererseits. Die Ursache liegt meist in der unzureichenden Erfahrung der Projektleitung in Teststandards, -methodik, -vorgehensweise und -prozessen.

Die Komplexität des Testgeschehens kontrastiert stark mit anderen Projektbereichen und kann gelegentlich von Projektmanagement, die über keine eigene Testerfahrung verfügen, kaum vollständig nachvollzogen werden. Dies kann zu unrealistischen Forderungen an das Testmanagement und damit zu Konfliktsituationen führen.

Die Missverständnisse können bereits auf der Ebene der Testterminologie beginnen, da diese von Haus zu Haus unterschiedlich sein können. Dies führt dazu, dass Gespräche zur Teststrategie und Vorgehensweise zum Teil verschieden verstanden werden. Das sind Situationen, die leider oft zu Konflikten führen können. Vom Testmanager wird dann ein hohes Maß an Belastbarkeit und Widerstandsfähigkeit erwartet, das gelegentlich über das der anderen Rollen im Projekt hinausgeht. Dies ist gelegentlich auch der Grund, warum die Position des Testmanagers häufig durch externe Mitarbeiter besetzt wird.

Ein potenzielles Heilmittel gegen Missverständnisse, das heutzutage leider in der Projektarbeit der Finanzhäuser kaum Berücksichtigung findet, sind gezielte Schulungen der Testmethodik nach ISTBQ für Programm- und Projektleitung. In Projekten mit einem hohen Anteil von Testinhalten sollte Testerfahrung beziehungsweise eine ISTQB Schulungsteilnahme als eine Voraussetzung für die Zulassung als Projekt- und Programmleitung gelten. Die Erfahrung zeigt eindeutig, dass Projekt- und Programmmanager mit Testerfahrungen beziehungsweise ISTQB-Kompetenzen, die durch Spezialisten erarbeitete Testplanung, -vorbereitung und -durchführung in großen Projekten mit multiplen Umsetzungen an vielen Systemen besser nachvollziehen und zum erfolgreichen Abschluss bringen können.

Die in der letzten Zeit häufiger auftretenden Hinweise über Probleme mit MiFID-II-Projekten deuten auf diverse Koordinationsschwierigkeiten komplexer Zusammenhänge sowohl im fachlichen als auch im technischen Bereich. Fehlende theoretische Grundlagen für parallele Systemanpassungen und effektive Testvorgehen in komplexer IT-Architekturen lassen zwangsläufig viele Freiräume für kostenintensive "Trial-and-Error"- Ansätze, die einem möglichen Erfolg eher im Wege stehen. Der Artikel weist auf wenige auffallende Parameter der Testvorbereitung und -durchführung hin, deren gezielte Ausgestaltung die erforderliche organisatorische und prozessorientierte Effektivität der Tests komplexer IT-Architekturen sichern kann.

Weiterführende Literatur

Gernot Dern, Management of IT-Architekturen, Springer Verlag, 2013

Christian Schmidt, Management von komplexen IT-Architekturen, Springer Verlag, 2009

Fußnoten

1) "Organisations build or acquire collections of software assets (e.g. applications, data bases, scripts, servers, etc.) with the expectation that these assets will enable the organization to effectively respond to its environment. These assets are frequently integrated with each other so that data and processing can be seamlessly shared. These integrations, however, create dependencies between these assets, which raises the question of whether such dependencies could in any way restrict an organisation's ability to respond to changes in its business and technology environment." David Dreyfus und George M. Wyner, Digital Cement: Software Portfolio Architecture, Complexity and Flexibility, in: AMCIS 2011 Proceeedings, Mai 2011

2) "Als klassische Folge ist die negativ Schlagzeile, sprich schlechte PR zu nennen (...) Als offensichtliche negative Folge schlechter Datenqualität, kann ein finanzieller Schaden auftreten (...) Schwieriger zu bestimmen und auch nicht so leicht zu entdecken sind die Zusammenhänge in Bezug auf entgangenen Umsatz." Jens Bleiholder, Gute Qualität sicherstellen, in: Qualität in IT-Architekturen: Management, Herausgeber Mirko Schrumpp, entwickler.Press, 2012

3) Die Verwendung echter Kundendaten aus den Produktionssystemen, sogenannter personenbezogenen Daten, in Test- und Entwicklungssystemen ist in Deutschland durch das Bundesdatenschutzgesetz verboten.

4) Siehe Duncan Watts, Six Degrees, The Science of a Connected Age, Vintage Books Random House, 2004

Tadeusz Skolka, PPI AG, Frankfurt am Main
Tadeusz Skolka , Managing Consultant, PPI AG, Frankfurt am Main

Weitere Artikelbilder

Noch keine Bewertungen vorhanden


X