Der Integrationstest im Kontext des Entwicklungsprozesses
Das System steht kurz vor der Fertigstellung – nur noch schnell testen und dann kann es produktiv eingesetzt werden. Häufig starten die Aktivitäten zum Integrationstest sehr spät in der Entwicklung. Völlig überraschend treten dann Probleme auf, deren Ursachen in vorgehenden (vermeintlich abgeschlossenen) Entwicklungsphasen liegen.
Mächtig komplex
Eine Problematik liegt darin, dass die Systeme unserer Zeit immer mächtiger und komplexer werden. Softwareanwendungen sind nur selten noch Stand-Alone-Programme, sondern vernetzen Informationen aus diversen Quellen (z.B. Apps nutzen zahllose Web-Services Dritter). Hardwareprodukte besitzen komplexe Softwaresteuerungen, welche nun unter dem Schlagwort „Internet der Dinge“ vernetzt werden (z.B. digitale Stellwerke der Bahn). Selbst vermeintlich einfache Alltagsprodukte werden für die bequeme Bedienung von überall vernetzt (z.B. Smart-Home-Produkte). Häufig handelt es sich auch nicht mehr um ein homogen entwickeltes System eines einzigen Entwicklungsteams, sondern es wird von verteilten Spezialistenteams entwickelt. Ferner beinhaltet das System oft ältere Vorgänger-Subsysteme und Subsysteme von Drittherstellern, sei es Hardware (HW) oder Software (SW). Weiterhin wird in vielen Projekten eine Middleware eingesetzt, welche die einzelnen Komponenten zu einem kompletten System verbindet. Diese gestiegene Komplexität erfordert bei der Systementwicklung äußerste Sorgfalt. Mängel hierbei können heutzutage nicht mehr durch einzelne sehr erfahrene Entwickler ausgeglichen werden, denn die Komplexität des Gesamtsystems kann in der Tiefe nicht mehr von einer Person erfasst werden.
„Mein“ Entwicklungsprozess
Erprobte Entwicklungsprozesse sind bereits ausgiebig beschrieben, sei es das klassische Vorgehensmodell (V‑Modell) oder agile Entwicklungsprozesse wie Scrum. In der Praxis stößt man jedoch nicht selten auf lückenhafte Prozesse, bei denen häufig nur die Programmiertätigkeit im Vordergrund steht. Begründet wird dies meist damit, dass die bewährten Entwicklungsprozesse „nicht passend“ für das jeweilige Projekt seien und deshalb ein eigener Prozess genutzt wird. Dieser ist dann meist nicht näher definiert, geschweige denn in einem Projekthandbuch dokumentiert.
Gerade in Projekten, die „agil“ sein wollen, wird das agile Manifest geradezu missbraucht, um ungeplantes Arbeiten auf Zuruf zu rechtfertigen und Dokumentation als generell überflüssig abzulehnen. Eine erfolgreiche Systementwicklung erfordert es aber, dass die Spezialisten eines Teams Hand-in-Hand zusammenarbeiten, damit der Entwicklungsprozess gelingen kann.
Wir empfehlen:
- Definieren Sie Ihren Entwicklungsprozess (z.B. Projekthandbuch, „Sprint 0“ in Scrum)
- Nutzen Sie bewährte Entwicklungsmethoden
- Dokumentieren und hinterfragen Sie eigene Adaptionen
Abb. 1: Vorgehensmodell (V‑Modell) mit den Abstraktionsebenen
System mit Fundament
Konzentrieren wir uns im Folgenden zunächst auf das V‑Modell (siehe Abb. 1) und die klassische Entwicklung. Basis eines Systems ist das kundenseitig erstellte Lastenheft und darauf aufbauend die Systemspezifikation, das Pflichtenheft. Die Komplexität wird dann zerlegt über den Systementwurf (Architektur & Schnittstellenspezifikation). Für komplexe Datenschnittstellen ist zu empfehlen diese in separaten Dokumenten zu beschreiben, da diese für jedes an der Kommunikation beteiligte Subsystem genutzt wird und Schnittstellen ebenfalls einer Versionierung unterliegen, wenn sie weiterentwickelt werden. Für jedes Subsystem ist dann eine Subsystemspezifikation zu erstellen, in der das jeweilige Subsystem als „Black Box“ beschrieben wird. Ggf. können noch weitere Verfeinerungsebenen für Komponenten und Module folgen. Für diese gelten die folgenden Grundsätze selbstverständlich ebenso.
Es ergibt sich schnell eine große Menge an Dokumenten mit einer hohen Zahl von Anforderungen. Bei sauber definierten Prozessen und klaren Regeln für das Anforderungsmanagement kann nun ein belastbares Fundament für alle folgenden Entwicklungsschritte gelegt werden. Idealerweise verfeinern sich die Anforderungen von Ebene zu Ebene wie folgt:
- Jede Anforderung hat eine Motivation, d.h. mindestens einen Vorgänger (kein „Gold-Plating“)
- Jede Anforderung wird weiter verfeinert, d.h. hat mindestens einen Nachfolger (keine Umsetzungslücken)
- Stellen Sie klare prüfbare Regeln für die Verfolgbarkeit (Traceability) durch die Dokumente auf (z.B. Verlinkung nur zwischen benachbarten Ebenen)
Abb. 2: Schematische Darstellung der Anforderungstraceability über drei Abstraktionsebenen
Abstraktionsebenen prüfen
Bei der strikten Umsetzung dieser Regeln treten im Bereich des Anforderungsmanagements teilweise Probleme auf. Ursache sind hierfür nicht zu strikte Regeln, sondern lückenhafte Anforderungen oder die fehlerhafte Zuordnung der Anforderung zur Abstraktionsebene (= Spezifikationsdokument, siehe Abb. 2). Fordert der Kunde in seinem Lastenheft z.B. nur eine spezielle Benachrichtigungsinformation nach 1000 Betriebsstunden für die Wartung des Systems, so meint er vermutlich eine komplexe Diagnoseschnittstelle über die Statusinformationen, Wartungs- und Fehlermeldungen. Schnell lässt sich erahnen, dass hierfür plötzlich ein großes Bündel an Anforderungen auf System‑, Subsystem- und Schnittstellenebene benötigt wird.
Ob eine Anforderung korrekt dem Spezifikationsdokument zugeordnet ist, kann sehr gut geprüft werden, indem die korrespondierende Testphase betrachtet wird. Lässt sich die Anforderung wirklich in dieser Phase testen oder gehört Anforderung und Test in eine andere Abstraktionsebene? Wird z.B. in einer Schnittstellenspezifikation gefordert, dass innerhalb von 100ms eine Anfrage korrekt beantwortet werden muss, so ist diese falsch zugeordnet. Es ist eine Anforderung an das Subsystem! Für die Schnittstellenspezifikation ist zutreffend, dass es einen Timeout nach 100ms gibt. Das befragte Subsystem soll beim Timeout eine qualifizierte Fehlernachricht generieren und versenden. Das anfragende Subsystem muss diese Fehlernachrichten behandeln sowie eigenständig Timeouts feststellen (falls die Kommunikation unterbrochen ist).
Wir empfehlen die Prüfung (siehe Abb. 3):
- Sind die Anforderungen den richtigen Anforderungsdokumenten zugeordnet?
- Sind die Anforderungen in der jeweils korrespondierenden Testphase prüfbar?
Robuste Systeme
Bei der Definition von Schnittstellen empfiehlt es sich, bereits vorhandene, standardisierte Schnittstellen zu nutzen. Diese sind bewährt, gewähren Interoperabilität, ermöglichen den einfachen Austausch von Subsystemen (z.B. von einem anderen Hersteller) und vereinfachen die Einarbeitung von neuen Mitarbeitern. Bei der Spezifikation von Schnittstellen und Subsystemen sollten nicht nur die funktional erlaubten Datenwerte im Funktionsbereich betrachtet werden, sondern der gesamte Wertebereich, der technisch über diese Schnittstelle übermittelt werden kann. Das Subsystem sollte robust ausgelegt sein, so dass im Falle von fehlerhaften Signalen bzw. inkonsistenten Daten qualifizierte Fehlermeldungen zurückgemeldet werden. Selbstverständlich muss das aufrufende Subsystem adäquat auf mögliche Fehler reagieren.
Wir empfehlen:
- Betrachten Sie den kompletten Wertebereich der Schnittstellen
- Legen Sie Subsysteme robust aus
Integrationsstrategie
Bereits im Testkonzept sollte festgelegt werden, welche Integrationsstrategie angewendet werden soll. Beim „Big-Bang“ werden alle Subsysteme gleichzeitig integriert. Nachteilig ist hier, dass die Fertigstellung aller Subsysteme abgewartet werden muss und alle Fehlerwirkungen gleichzeitig auftreten. Inkrementelle Strategien wie z.B. Top-down- bzw. Botton-up-Integration ermöglichen es frühzeitig mit Integrationstests zu beginnen, allerdings benötigen diese Platzhalter (für die fehlenden Funktionen) bzw. Testtreiber (für den Aufruf). Die Wahl einer passenden Strategie hängt von den Projektgegebenheiten ab, jedoch sollte die „Big-Bang“-Strategie vermieden werden.
Wir empfehlen:
- Nutzen Sie – wenn möglich – inkrementelle Integrationsstrategien
- Stimmen Sie die Integrationstests mit den Zeitplänen des Projektes ab und aktualisieren Sie diese im Bedarfsfall
Fokussierung beim Integrationstest
Fokus des Integrationstests ist die Überprüfung, ob die zu integrierenden Subsysteme zusammen korrekt funktionieren. Vorausgesetzt wird, dass die einzelnen Subsysteme funktionstüchtig sind, also die Subsystemtests abgeschlossen sind. Damit gibt es eine strikte Trennung zwischen diesen beiden Testphasen! Beim Integrationstest muss lediglich geprüft werden, ob die Systeme korrekt miteinander kommunizieren. Typische Fehler sind z.B. das Vertauschen von Pins bei der Verkabelung der Subsysteme, das Nichtbeachten von eingeschränkten Wertebereichen, welches ein Subsystem voraussetzt oder neue bzw. geänderte Nachrichten, da die Subsysteme unterschiedliche Versionen einer Schnittstellenspezifikation nutzen. Kurzum: Es ist beim Integrationstest zu prüfen, ob die Subsysteme sich „verstehen“ und zusammenspielen – nicht mehr und nicht weniger (siehe Abb. 4).
Wir empfehlen:
- Trennen Sie strikt die Testphasen zwischen Subsystem- und Integrationstest voneinander ab
- Beachten Sie die Testreihenfolge – zuerst die Subsystemtests abschließen!
Abb. 4: Beispiel für Integrationsstrategie mit den Subsystemtests und Integrationstests
Frühzeitig testen – auch beim Integrationstest
Wie bei anderen Testphasen auch, sollten die Aktivitäten für den Integrationstest frühzeitig beginnen (Projektplanung – Testkonzeption – Anforderungsermittlung & ‑abstimmung – Systemarchitektur). Die Spezifikation der Integrationstests kann sofort nach Abschluss der Anforderungsspezifikation begonnen werden. So können Fehler oder Lücken der Anforderungsspezifikation zeitnah aufgedeckt werden.
Auch wenn für die finale Durchführung des Integrationstests zuerst auf den Abschluss der Subsystemtests gewartet werden muss, können vorab durchgeführte Integrationstests von Vorversionen der Subsysteme (mit eingeschränkter Funktionalität) sinnvoll sein. Mit diesen Vorabtests kann sichergestellt werden, dass die Subsysteme mindestens bei den grundlegenden Funktionen korrekt zusammenspielen.
Wir empfehlen:
- Beplanen Sie die Testaktivitäten ab Projektstart
- Führen Sie die jeweiligen Testaktivitäten so früh wie möglich durch
- Sichern Sie mit Vorabtests die generelle Funktion der Schnittstellen
Agil? – Alles anders?
Nein! Prinzipiell gibt es die Testphasen auch bei der agilen Entwicklung. Insofern sind auch die Integrationstests mit zu betrachten. Oft werden diese aber implizit im Rahmen des Systemtests mit durchgeführt. Werden aber Integrationstests explizit gefordert (z.B. aufgrund der Kritikalität des Systems), so müssen diese auch bei der agilen Entwicklung explizit berücksichtigt und dokumentiert werden. Automatisierte Tests sind unverzichtbar, damit Tests zügig für jedes Inkrement des Systems durchgeführt werden können. In der Praxis anzutreffen sind Projekte, deren Subsysteme agil entwickelt werden, formale Abnahmen mit Integrations- und Systemtests sowie weitere Aufgaben für die Auslieferung (Dokumentationen, Inbetriebsetzung) jedoch „klassisch“ zu bestimmten Zeitpunkten stattfinden.
Fazit:
Zusammenfassend lässt sich feststellen, dass die Entwicklungsprozesse vieler Projekte ausschließlich die Programmierung fokussieren. Anforderungen und Tests werden gerne vernachlässigt. Dies stellt jedoch ein unnützes Projektrisiko dar, welches insbesondere in Zeiten von Fachkräftemangel, Fluktuation von Mitarbeitern und dem Willen nach Wiederverwendung von (Sub-) Systemen unverständlich ist.
Sie möchten mehr erfahren? Nehmen Sie gerne Kontakt zu mir auf.
