Die Bemühungen des ISTQB haben dazu geführt, dass es eine gute Beschreibung dessen gibt, was ein Softwaretester an Grund- und weiterführendem Wissen haben sollte oder muss. Auch eine Beschreibung der Testphasen und wie sie mit den Entwicklungsphasen im V-Modell der Softwareentwicklung zusammen hängen, ist in den entsprechenden Standard aufgenommen worden.
In diesem Modell gibt es einen Integrationstest und einen Systemtest. Im Integrationstest wird das Zusammenspiel der einzelnen Softwaremodule untereinander getestet, im Systemtest die Funktionsweise der Gesamtsoftware mehr von “außen” betrachtet.
Nur in noch keinem Projekt, was ich mitbetreuen durfte, wurde das so gelebt. Immer gibt es eine Testphase, die man Systemintegrationstest nennen könnte, ein Zwischending zwischen System- und Integrationstest, auf das Unternehmen bezogen. Was das nun heißen soll, will ich in diesem Artikel beschreiben.
Größere Unternehmen und Konzerne setzen nicht die eine Software ein, sondern dutzende. Und ein Großteil davon kommuniziert in der einen oder anderen Form miteinander und das über z.T. verworrene und sich gegenseitig widersprechende Wege.
Zentrale Systeme sind oftmals das zentrale Kundenverwaltungssystem, das Billing System und auf die jeweilige Branche bezogene System (Abrechungs- und Rating Systeme in der Telekommunikation, Shop- und Kassensysteme im Handel usw.). Datenveränderungen, z.B. im Rahmen eines Geschäftsprozesses, müssen an alle daran beteiligten Systeme weitergereicht werden. Und das sollte so schnell geschehen, dass es nicht zu Dateninkonsistenzen zwischen den Systemen kommt.
Wenn ich also in einem Telekom-Irgendwas-Shop einen neuen Vertrag abschließe und mir ein ordentliches Smartphone dazu bestelle, dann geschieht jede Menge im Hintergrund. Die buchhalterischen Daten werden an die Finanzbuchhaltung übermittelt, ein Auftrag für die interne Logistik zum Versand des Handys erstellt, die Lagersoftware muss den Bestand um 1 erniedrigen (bzw. zunächst einmal prüfen, ob überhaupt noch ein Gerät vorrätig ist …). Das Kundensystem muss darüber informiert werden, dass es einen neuen Kunden mit bestimmten Konditionen gibt (und allen zugehörigen Daten), die technischen Systeme müssen die neue Telefonnummer und die aktivierte Karte kennen und richtig behandeln. Und vieles, vieles mehr …
Dieser Datenaustausch ist extrem komplex und sehr fehleranfällig. Steht nur ein System nicht zur Verfügung (aus welchen Gründen auch immer …), so kann das ganze fragile Konstrukt in sich zusammenbrechen.
Dieses komplexe Gebilde ist also einem Test zu unterziehen. Und weil in der einschlägigen Literatur nichts gescheites dazu zu finden ist, nennt ihn jeder anders: Systemintegrationstest, Geschäftsprozesstest, Gesamtsystemtest, Unternehmenstest, Geschäftstest. Alles weiter kein Problem, solange klar bleibt, worum es geht. Es handelt sich eben nicht um einen Systemtest oder Integrationstest, sondern etwas genau dazwischen, oder von mir aus darüberstehend. Meiner Meinung nach eben ein Systemintegrationstest.
Dazu mal ein paar Betrachtungen in Bezug auf den Test:
Testumgebung
Um ein Gesamtsystem unternehmensweit testen zu können, müssen die daran beteiligten System in einer Testumgebung vorhanden und zugänglich sein. In letzter Konsequenz benötigt man also die Unternehemensinfrastruktur zweimal, was aus naheliegenden Gründen nicht machbar ist. Also muss man gute Annahmen und Näherungen machen, um das Testsystem so produktionsnahe und so einfach und kostengünstig wie möglich betreiben zu können.
Systeme, die nur als Datenquelle und nicht als Datensenke dienen, müssen nur einmal vorhanden sein. In der Regel greift man direkt auf die Produktionssysteme zu, was insofern unkritisch ist, als das keine Daten manipuliert werden.
Das den Geschäftsprozess auslösende System muss in der tatsächlich zu testenden Version in einer testumgebung vorliegen. Nach Möglichkeit benötigt man dann auch Zugriff auf die direkt anliegenden Schnittstellen zu den nächsten Systemen. Z.B. über Logfiles, Tools die den Netzverkehr protokollieren usw. Ist dies nicht möglich, führt das zu einem großen Abstimmungs- und Koordinationsaufwand mit den die benachbarten Systeme betreuenden Kollegen.
Ein Zugriff auf alle Schnittstellenprotokolle ist kaum realisierbar. Deswegen sollte man die entsprechenden Kollegen für den Test mit ins Boot holen und bei Bedarf um Unterstützung bitten. Oftmals ist es für sie eine Kleinigkeit in das Logfile zu schauen und einen Fehler zu lokalisieren oder auszuschließen.
Oft liegen die Testsysteme auf recht leistungsschwachen Maschinen und/oder ihnen sind entsprechend wenige Hardwareresourcen zugewiesen. Das ist insofern zu beachten, als dass z.B. Antwortzeiten in Bereichen von einigen Sekunden liegen können. Time Out Parameter sind gegenüber des Life Betriebs entsprechend anzupassen. Ein Time Out Fehler nach mehr als einigen 10 Sekunden deutet auf ein Problem in einem entfernt liegenden System hin.
Testdaten
Ein weiterer zu betrachtender Aspekt sind die Testdaten. Jedes am Test beteiligte Softwaresystem hat eine eigene Datenbasis und in den wenigsten Fällen sind die Daten in einer Testumgebung konsistent. Das führt zu merkwürdigen Phänomenen und Fehlern, die letztlich nicht auf die Software an sich zurückführbar sind. Um aber solche Probleme in den Grriff zu bekommen bzw. auszuschließen, müssen Testdaten frühzeitig zusammengestellt werden.
Dabei nimmt man Rücksicht auf die Systeme, deren Daten nicht verändert werden können bzw. auf die man keinen direkten Zugriff hat. Benötigt man beispielsweise einen “aktiven Kunden”, so fragt man diese Form der Daten frühzeitig an (z.b. im zentralen Kundenverwaltungssystem).
Für das eigene zu testende System bestehen immer bestimmte Restriktionen: der zu testende Vorgang kann wohl mit den nun bekannten Testdaten angestoßen werden, zu fragen bleibt aber: an welche Systeme wird dies weitergemeldet (Datensenken) und welche Systeme müssen ergänzende Informationen in den Geschäftsprozess einbringen (Datenquellen).
Zu überprüfen bleibt also: kommen alle Daten in den Datensenken an und werden alle benötigten Daten zur Verfügung gestellt.
Fazit
Anhand eines konkreten Beispiels lassen sich die hier eher allgemein verfassten Hinweise sicherlich besser nachvollziehen. Aber verständlicherweise werde ich keine interne Strukturen meiner Auftraggeber darstellen.
Was man aber sagen kann, ist, dass es sich um eine höchst komplexe Angelegenheit handelt, die ein Höchstmaß an Koordination und Kommunikation erfordert.
Außerdem ist fundiertes Wissen bzgl. der am Test besteiligten Systemlandschaft erforderlich. Jedem Beteiligten kann nur geraten werden über den Tellerrand seines “eigenen” Systems hinwegzuschauen und das Zusammenspiel im Unternehmensverbund zu verstehen. So weit es eben möglich ist.