INTEGRATIONSTEST - Sigs Datacom
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
– Verlagsbeilage –
INTEGRATIONSTEST
DER INTEGRATIONSTEST
IM KONTEXT DES
ENTWICKLUNGSPROZESSES
KOMPATIBILITÄTSTESTS
MIT CONSUMER-DRIVEN
CONTRACTS
KONKRETE LEARNINGS
AUS EINEM AGILEN INTE-
GRATIONSTESTING-PROJEKT
INTEGRIERTES TESTEN VON CONNECTED-CAR-LÖSUNGEN BEI DER RENAULT-NISSAN- MITSUBISHI-ALLIANZ
www.GermanTestingDay.info
#GermanTesting
GERMAN TESTING DAY 2020
Die unabhängige Konferenz zu Software-Qualität
SAVE THE DATE
06. + 07. Mai 2020 | Kap Europa | Frankfurt am Main
Jetzt Termin vormerken und auf diese Themen freuen!
PERFORMANCE
TESTING
AGILITÄT
OPTIMIERUNG DIGITALISIERUNG
ANALYSE
QUALITY
AUTOMATION
INTEGRATION
EDITORIAL / INHALT
INTEGRATIONSTESTS
Wer von Ihnen hat früher nicht auch mit LEGO gespielt und auf Seite 95 definieren. Für Projekte, die auf einer Microservice-Architektur basie-
der Anleitung den eigenen Fehler von Seite 4 verflucht? Schon damals ren und über eine Vielzahl von Schnittstellen verfügen, ist das Thema
war instinktiv klar, dass sich kleine Fehler in der Anfangsphase zum Integrationstest besonders relevant.
Ende hin dramatisch äußern können. Ein perfektes Gegenmittel für die
eigenen Fehler war nicht bekannt und außerdem wollten wir alle schnell Wir wünschen Ihnen viel Spaß bei der Lektüre, neue Ideen, Inspirati-
fertig werden – genau wie heute. Bei LEGO Technik wird es nicht besser onen und Anregungen für Ihre eigenen Integrationsprojekte – sei es
und mit echter Software oder gar eingebetteten Systemen können die eines mit Software oder mit LEGO.
Wirkungen katastrophal werden. Diese Zusammenhänge zwischen
Entstehen und Entdecken eines Fehlers sind hinlänglich bekannt. Wann
jedoch werden die in der Testphase von Teilsystemen unentdeckten
Fehler oft entdeckt? In der Integration dieser zu einem Gesamtsystem.
Der Integration eines Systems kommt daher eine besondere Bedeutung
zu. Vielen Testmanagern steht zu Beginn der Integration (zurecht) der
Schweiß auf der Stirn, da vor der ersten erfolgreichen Durchführung
eines funktionalen Tests durchaus viel Zeit mit der Suche nach Inkon-
sistenzen in Schnittstellen, Teilsystemspezifikationen oder Testdaten
verbracht werden kann.
Diese Ausgabe des German Testing Magazins haben wir entsprechend
dem Integrationstest gewidmet. Neben Querschnittsthemen wie Test-
automatisierung und Erfahrungsberichten aus der Praxis haben wir Ihre
den Schwerpunkt auf Consumer-Driven Contracts (CDC) gesetzt, die
ein Vorgehen für den Test von Schnittstellen zwischen Microservices Dr. Stephan Weißleder und Richard Seidl
INHALT
Editorial 3 Integrationstests von Microservices
in CI/CD-Deployment-Pipelines
Die Komplexität der Integration Stefan Friese 21
Richard Seidl und Stephan Weißleder 4
Continuous Everything (jetzt mit Cloud™ ;))
THEMA: INTEGRATIONSTESTS Tom Vollerthun 24
Wie viele Integrationstests kann es geben?
Matthias Hamburg 6 THEMA: TESTS VON INTEGRIERTEN SYSTEMEN
Testen der integrierten, hyperverbundenen Welt
V-Modell++ – das Modell für die Entwicklung
Vimmi Walia, Rajni Singh und Helmut Pichler 28
und den Test von Multisystemen
Mohsen Ekssir 8
Integriertes Testen mehrerer Komponenten
zur Simulation des vernetzten Fahrzeugs
Agiler Integrationstest mit Mehrwert
Gregor Mayer 32
Thomas Klein und Carsten Negrini 11
Der Integrationstest im Kontext des Entwicklungsprozesses KONFERENZBERICHT
Joachim Schulz 14
Grumplexity Theory trifft die Frage,
ob Frösche Zähne haben
THEMA: CONSUMER-DRIVEN CONTRACTS Rudolf Grötz 36
Kompatibilitätstests mit CDC
Antoniya Atanasova und Sebastian Letzel 18 Impressum 39
3
DIMENSIONEN DER INTEGRATION RICHARD SEIDL UND STEPHAN WEISSLEDER
»DIE KOMPLEXITÄT DER INTEGRATION«
Der Duden definiert Integration als „[Wieder]herstellung einer Einheit [aus Differenziertem]; Vervollständigung“ und somit
ein großes Ziel, auf das dieser Prozess zusteuert. Die konkreten Ausprägungen gerade in der Softwareentwicklung könnten
unterschiedlicher kaum sein: horizontal, vertikal, Microservices, APIs, lose gekoppelt, Schichten, Silos, eng verzahnt, als Inte-
grationsplattform oder dateibasiert, Kapselung usw. – die Integration dessen hat umso mehr Ziele, da hier zusätzlich noch
integrationsspezifische Aspekte wie die Integrationsstrategie inklusive Anforderungen an die Testumgebung hinzukommen.
Um hier den Überblick zu behalten, braucht und mehr in den Fokus rücken und sollten › Units: Hier gibt es meist eine gute
es Struktur. Und wir möchten an dieser Stelle entsprechend berücksichtigt werden. Test-Unterstützung durch die Entwick-
ein paar Dimensionen aufzeigen, die bei der lungsumgebung bzw. durch das Frame-
Klassifikation der eigenen Integrationstests Dimension: Testobjekte work.
oder bei der Prüfung auf weitere notwendige
Dimensionen helfen können. Das zu prüfende Testobjekt beeinflusst maß- › Systemkomponenten: Eingebundene Bib-
geblich die Ausgestaltung der Tests und der liotheken oder Datenbanken unterstützen
Dimension: Testziele Testumgebung: Schnittstellen, Services, APIs, den Test.
Datenbanken, Subsysteme, aber auch Infra-
Ein typisches Testziel des Integrationstests struktur und Hardware. › Systeme: Selbst wenn Schnittstellen von
ist der Nachweis der korrekten Kommunikati- Softwaresystemen gut dokumentiert sind,
on zwischen den zu integrierenden Objekten. Wesentlich für den Erfolg der Integrations- ist die Integration komplex und fehler-
Dabei geht es wie so oft vorrangig um die tests ist, dass die einzelnen Integrationsob- anfällig.
Minimierung des Risikos unentdeckter Fehler jekte unabhängig von der Kommunikation an
und um das frühzeitige Finden von Fehlerwir- den Schnittstellen bereits als Produkt oder › Integration von Software und Hardware:
kungen. Teilsystem getestet wurden. Ansonsten lässt Hier besteht für Tests eine besondere
sich im Fehlerfall nicht feststellen, ob die Pro- Herausforderung, auch nicht-funktionale
Meist stehen die funktionalen Aspekte im bleme von für Schnittstellen relevanten oder Aspekte zu berücksichtigen.
Vordergrund. Aber auch nicht-funktionale irrelevanten Fehlern herrühren. So kann viel
Aspekte spielen eine wesentliche Rolle: Zu- Zeit für die Fehlersuche eingespart werden. › Integration von Software und Daten: Beide
verlässigkeit, Gebrauchstauglichkeit, Infor- beschreiben Informationen, die zusam-
mationssicherheit (Security), Kompatibilität, Dimension: Testebene menpassen müssen. Meist beschreibt Ers-
Übertragbarkeit, Änderbarkeit, Performanz/ teres einen generischen Teil und Letzteres
Effizienz (siehe ISO 25010). Je nach Branche, Je nach Testobjekt spielt der Integrationstest den projektspezifischen Teil. Hier ist der
Anwendungszweck und Kundenwünschen auf einer anderen Ebene, auf einem anderen Spagat zwischen allgemeingültiger und
können die nicht-funktionalen Aspekte mehr Abstraktionsniveau: projektspezifischer Prüfung wichtig.
4
DIMENSIONEN DER INTEGRATION
Auch Ebenen übergreifend kann es komplex
werden: Findet die Integration auf der System-
ebene (oftmals Black Box) statt, fokussiert WEITERFÜHRENDE L ITERATUR
aber auf Eigenschaften, die nur bei einer
White-Box-Betrachtung erkennbar sind, ist
dieser Spagat für viele Entwicklungsteams Der Integrationstest –
eine besondere Herausforderung. Von Entwurf und Architektur
zur Komponenten- und Systemintegration
Auf jeden Fall müssen bei der Integration
verschiedene Teams von verschiedenen Ebe- M. Winter, M. Ekssir-Monfared, H. M. Sneed,
nen mit verschiedenen Betrachtungswinkeln R. Seidl, L. Borner
zusammenspielen, um die effiziente Integra-
tion zu ermöglichen. Hanser-Verlag, 2012,
ISBN: 978-3-446-42564-4
Dimension: Testbasis
Als Testbasis können zum Beispiel dienen:
Schnittstellenspezifikationen, Definitionen zum Beispiel: falsche Datenstrukturen, feh- Und auch in dem Etablieren der Testautoma-
von Kommunikationsprotokollen, Sequenz- lerhafte Schnittstellen, falsche Annahmen tisierung selbst liegt eine große Herausfor-
diagramme, Modelle wie Zustandsdia- zu den übergebenen Daten, fehlende Daten, derung, da dieser Schritt oft Anpassungen in
gramme, Architekturbeschreibungen, Soft- Probleme bei der Performanz oder der Si- den Frameworks oder die Entwicklung eige-
ware- und Systementwürfe, Workflows, cherheit (Verschlüsselung). ner Testwerkzeuge benötigt – ein Aufwand,
Anwendungsfälle oder Beschreibungen von der nicht zu unterschätzen ist.
Datenstrukturen. Diese Dimensionen können in fast beliebiger
Kombination betrachtet werden und spannen Fazit
Generell gilt: Je höher der Grad der Forma- somit ein großes Feld an möglichen Integra-
lisierung desto eher kann man sich auf die tionstests auf. Während Komponenten oder Erschlagen von der Fülle der Möglichkeiten
Ergebnisse verlassen. Wenn wir sicher sein Systemtests eher homogen sind, ist dieses möchte man als Testmanager oder Tester
können, dass die Schnittstellenspezifikati- Feld der Integrationstests sehr unterschied- fast den Kopf in den Sand stecken. Aber
onen der kommunizierenden Produkte kon- lich in Umsetzung, Technologie und Metho- lassen Sie sich nicht entmutigen und fangen
sistent zueinander sind, dann ist bereits viel dik. Viele Tests, insbesondere nicht-funktio- einfach klein an: Spannen Sie ein Feld mit
gewonnen. nale, sind nur automatisiert sinnvoll testbar. den wichtigsten Dimensionen auf und prü-
Die hier beschriebene Menge an Kombina- fen Sie, wo Sie Integrationstests bereits gut
Dimension: Typische Fehler tionsmöglichkeiten, die auf den Test durch- umgesetzt haben, wo vielleicht noch Lücken
schlagen, legt die Notwendigkeit der Effi- sind und weitere Tests einen echten Mehr-
Mit Integrationstests können viele verschie- zienzsteigerung über Testautomatisierung wert bringen würden, und starten Sie danach
dene Arten von Fehlern entdeckt werden, ebenfalls nahe. die Verbesserung. Viel Erfolg dabei!
Richard Seidl
mail@richard-seidl.com
hat in seiner beruflichen Laufbahn schon viel Software gesehen und getestet: gute und schlechte, große und kleine, alte und neue,
Schokolade und Grütze. Sein Credo: Qualität ist eine Haltung. Wer heute exzellente Software kreieren möchte, denkt den Entwicklungs-
prozess ganzheitlich: Menschen, Methoden, Tools und Mindset – wenn alles in einem Flow zusammenspielt, entsteht Potenzialentfal-
tung und Innovation.
Dr. Stephan Weißleder
stephan.weissleder@gmail.com
kennt die Mühen der Systemintegration aus eigener Erfahrung. Das Zusammenspiel von liefernden und integrierenden Akteuren spielt
die Hauptrolle für den Erfolg. Mit ausreichenden Tests vor der Integration scheitert diese nicht mehr an zuvor nicht entdeckten Fehlern.
Weitestgehende Gleichheit zwischen der Komponententestumgebung und der Integrationstestumgebung sorgt für belastbare Tester-
gebnisse. Die Unterstützung der automatisierten Integration schon mit entsprechenden Komponentenschnittstellen kann die Integration
zusätzlich beschleunigen.
5
GLOSSAR-KOLUMNE MATTHIAS HAMBURG
»WIE VIELE INTEGRATIONSTESTS
KANN ES GEBEN?«
In dieser Kolumne diskutiert der Autor Themen rund um die Terminologie beim Softwaretesten. Heute geht es um den Integra-
tionstest.
Als ich angefangen habe, mich mit Testma- zuerst die grundlegende Frage beantworten, Für Testexperten ist es von großem Vorteil,
nagement systematisch zu beschäftigen, ob der Integrationstest eine Testart oder eine den Unterschied zwischen Teststufen und
habe ich die Testmethode TMap gelernt Teststufe ist. Testarten zu verstehen. So machen sie nicht
[Koo07]. Darin kamen zwei grundlegende den Fehler, eine Testart wie den Integrati-
Integrationsteststufen vor: die Unit-Integ- Testart oder Teststufe? onstest prinzipiell auf nur eine Teststufe zu
rationstests und Systemintegrationstests. beschränken, oder anders herum eine Test-
Hingegen war im damaligen ISTQB® Certi- Was überhaupt ist eine Teststufe und was stufe auf eine bestimmte Testart.
fied Tester Foundation Level nur von einem ist eine Testart? Eine aktuelle Antwort finden
(einheitlichen) Integrationstest die Rede. wir im ISTQB-Glossar [GTB-a]: In der Projektpraxis bin ich diesem Fehler oft
Obwohl inzwischen auch ISTQB® zwischen begegnet. Dadurch haben sowohl die Effek-
Komponentenintegrationstests und System- › Testart: Eine Gruppe von Testaktivitäten ba- tivität der Fehlerfindung als auch die Effizienz
integrationstests unterscheidet [GTB-b], sierend auf bestimmten Testzielen mit dem des Testens gelitten.
wird im allgemeinen V-Modell (siehe Abbil- Zweck, eine Komponente oder ein System
dung 1) immer noch oft nur ein Integrations- auf spezifische Merkmale zu prüfen. Gibt es nur einen oder mehrere
test als Teststufe dargestellt [Spi19]. Integrationstests?
› Teststufe: Eine spezifische Instanziierung
Eine solche Platzierung weist den Integrati- eines Testprozesses. Während der Integrationstest eine grund-
onstest klar als Teststufe aus. Die aktuelle legende Testart ist, sind bei komplexeren
Definition des Integrationstests in [GTB-a] In diesem Sinne ist der Integrationstest, so Systemen mehrere Integrations-Teststufen
klingt aber eher nach einer Testart: wie oben definiert, tatsächlich eine Testart. üblich. Ein Komponentenintegrationstest,
Er ist eindeutig durch Testziele geprägt. In das heißt der Test der Kompatibilität der
› Integrationstest: Testen mit dem Ziel, der Terminologie der ISO-Norm für Software- einzelnen Komponenten untereinander, ist
Fehlerzustände in den Schnittstellen und qualität [SQuaRE] wird das Qualitätsmerkmal die erste dieser Teststufen. Ein Systeminte-
im Zusammenspiel zwischen integrierten Kompatibilität getestet. Im ISO-Modell der grationstest (d. h. der Test der Kompatibilität
Komponenten aufzudecken. Produktqualität hat die Kompatibilität zwei von Systemen untereinander in einer Anwen-
Untermerkmale: die Interoperabilität und die dungslandschaft) könnte eine Stufe nach
Wenn wir die Frage, ob es einen oder meh- Koexistenz. Meist spielt die Interoperabilität dem Abnahmetest sein, oder aber eine Un-
rere Integrationstests gibt, methodisch fun- beim Integrationstest die wesentliche Rolle, terstufe des Abnahmetests. In der eingebet-
diert beantworten möchten, müssen wir also aber die Koexistenz kommt manchmal auch vor. teten Software kommt typischerweise auch
der Hardware-Software-Integrationstest als
weitere Teststufe hinzu.
Solche Teststufen haben alle ihre spezifi-
schen Testziele, Testplanung, Steuerung und
Berichtswesen, Verantwortlichen, Testver-
fahren usw. Aber diese Teststufen haben
auch gewisse Eigenarten, die sie voneinan-
der unterscheiden. Im Systemintegrations-
test ist es zum Beispiel eine typische Heraus-
forderung, dass die Testabläufe besonders
sorgfältig koordiniert werden müssen, da
sich mehrere Organisationseinheiten an den
Testaktivitäten beteiligen.
Diese Überlegungen zeigen, dass das, was
in Abbildung 1 Integrationstest genannt
wurde, eigentlich der Komponentenintegra-
Abb. 1: Ein allgemeines V-Modell mit einer Integrationsteststufe
tionstest ist.
6
GLOSSAR-KOLUMNE
Referenzen
› [GTB-a] ISTQB®/GTB Standardglossar der Testbegriffe, Version 3.2 vom 27.9.2018, siehe: http://glossar.german-testing-board.info/v3.2/
› [GTB-b] ISTQB®/GTB Lehrplan Certified Tester Foundation Level, Version 2018, siehe:
https://www.german-testing-board.info/wp-content/uploads/2018/09/Lehrplan-Certified-Tester_Foundation-Level_Version2018.pdf
› [Koo07] T. Koomen, L. van der Aalst, M. Vroon, B. Broekman, TMap® Next – ein praktischer Leitfaden für ergebnisorientiertes Softwaretesten,
dpunkt.verlag, 2007
› [Spi19] A. Spillner, T. Linz, Basiswissen Softwaretest – Aus- und Weiterbildung zum Certified Tester – Foundation Level nach ISTQB-Standard,
6., überarbeitete und akt. Auflage 2019, dpunkt.verlag
› [SQuaRE] ISO/IEC Standard 25010. Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) –
System and software quality models, 1st Edition, 2011
Die Situation ist hier ähnlich wie bei anderen in der Umgangssprache meist eine Teststufe prozess wird in einer Instanz für verschiede-
Testarten. Die Testart wird in der Umgangs- auf einem voll integrierten System gemeint. ne Aggregationsstufen durchlaufen.
sprache mit einer Teststufe identifiziert, in
der diese Testart größtenteils ausgeführt Ist der Integrationstest Andererseits ist die Kompatibilität von Kom-
wird. Auch bei Last- und Performanztests, noch aktuell? ponenten, Systemen oder Software und Hard-
IT-Sicherheitstests oder Gebrauchstauglich- ware nach wie vor relevant, oft sogar noch
keitstests handelt es sich um Testarten, die In agilen oder DevOps-Softwareentwick- wichtiger als vorher. Deshalb spielt der Inte-
prinzipiell in verschiedenen Teststufen durch- lungslebenszyklen sind die Testaktivitäten grationstest als Testart unbestritten eine gro-
geführt werden können. Zum Beispiel kann für mit den übrigen Entwicklungsaktivitäten ße Rolle. Aus dem allgemeinen V-Modell der
Komponenten die Performanz der verschie- sehr stark integriert und verzahnt. Im Sinne alten Schule können wir trotzdem lernen, dass
denen Ressourcen wie Datenbank, Speicher der obigen Definition spielen die Teststufen ein effektiver und effizienter Integrationstest
oder Netzwerk-Bandbreite getestet werden. deshalb keine so große Rolle mehr. Sie wer- für jede Aggregationsstufe seine differenzier-
Dennoch ist mit dem Last- und Performanztest den oft als „alte Schule“ abgetan. Der Test- ten Testziele und Testverfahren haben soll.
Dr. Matthias Hamburg
matthias.hamburg@german-testing-board.info
war bis zu seiner Pensionierung im September 2019 Managing Consultant bei der Sogeti Deutschland GmbH. Im German Testing Board
(GTB) engagiert er sich ehrenamtlich und ist sein stellvertretender Vorsitzender. Als Leiter der GTB-Arbeitsgruppe Glossar gibt er das
ISTQB®/GTB Standardglossar der Testbegriffe heraus. Darüber hinaus leitet er die Glossary Working Group beim International Software
Testing Qualifications Board (ISTQB®).
NovaCarts Hybrid-Tests
HW-Karten für den Hybrid-Einsatz – von
der Baugruppe bis zum schlüsselfertigen
Hybrid-HiL » Batterie-Zellsimulation
» Hochspannungsquelle
» Widerstandssimulation
» Karten optimiert für NovaCarts-HiL
» Isolationsfehleraufschaltung
» Standalone-Betrieb möglich
» Shunt-Simulation
» Betrieb der Karten mit NovaCarts-SW
» Pilot-, Crash- und
und unter Windows
Interlock-Simulation
» Ruhestrommessung
» E-Maschinen-Simulation
Tel.: +49 8139 9300-0
sales-testing@micronova.de
www.novacarts.de
7
MULTISYSTEME & MULTI-INTEGRATIONSTEST MOHSEN EKSSIR
»V-MODELL++ –
DAS MODELL FÜR DIE ENTWICKLUNG
UND DEN TEST VON MULTISYSTEMEN«
Durch die verstärkte Vernetzung der menschlichen Gesellschaft werden heutzutage die einzelnen Softwaresysteme zuneh-
mend miteinander zusammengeschweißt und integriert in Betrieb genommen. Die System-Size wird immer größer und diese
Tatsache verleiht der Integration und dem Integrationstest eine neue Dimension. Das gilt sowohl für Fertigsysteme, die gekauft
werden, als auch für Services, die in der Cloud gemietet werden. Kompatibilität, Systemintegration und IoT sind die Schlagwör-
ter. Die Qualitätssicherung (QS) bewegt sich dementsprechend in den letzten Jahren immer mehr in Richtung QS von integrier-
ten Softwaresystemen, um die erforderliche Qualität der neuen Geschäftsprozesse und Anwendungsfälle beziehungsweise
Services, nach dem Standard ISO 25010, zu sichern.
Dabei geht es hauptsächlich um die Inte- nachdem das V-Modell bereits erfolgreich Abbildung 1 zeigt das V-Modell++-Vorge-
gration einzelner Softwaresysteme, die im umgesetzt worden ist. hensmodell. Die drei neuen spezifizierenden
Stand-alone-Betrieb lebensfähig sind und Entwicklungsschritte und die drei korrespon-
als einzelne Systeme verkauft und einge- Das V-Modell++ erweitert das V-Modell dierten Teststufen für einen Verbund von meh-
setzt werden können. Im Digitalisierungs- ([Spi05], Seiten 39, 40) um drei weitere Ent- reren Systemen sind farbig hervorgehoben.
zeitalter werden die Systeme, die bereits wicklungsschritte auf dem linken und drei
als Stand-alone-Lösungen getestet und entsprechende Teststufen auf dem rechten Aus Testsicht verkörpern die hellblauen Be-
eingesetzt worden sind, nach Bedarf, auf Ast des Vs: reiche in der Grafik die sogenannte Teststufe
unterschiedliche Arten (System-Interaktion, Unittest für einen Verbund von integrierten
Frontend-, Backend- und Webservice-Inte- › Anforderungsdefinition für Verbund – Mul- Systemen. Es geht hier ausschließlich um
gration) [Win12] miteinander integriert, um ti-Abnahmetest, den Test einzelner Applikationen. Der eigent-
den Stakeholdern und Endbenutzern neue liche Test von integrierten Systemen beginnt
Services anzubieten. Dabei reicht das Spek- › funktionaler Systementwurf für Verbund – erst nach der Freigabe oder nach dem Abnah-
trum der Heterogenität der verwendeten Multi-Systemtest, metest der einzelnen Systeme.
Technologien meistens von unterschiedli-
chen Betriebssystemen, Datenbanken bis hin › technischer Systementwurf – Multi-Inte- Die neuen Teststufen und deren Aktivitäten
zu verschiedenen Programmiersprachen und grationstest. sollen für den Test eines Multisystems nach
Webbrowsern.
Das V-Modell++
Um den Bedürfnissen der QS für ein Multi-
system oder einen Systemverbund besser
gerecht zu werden, hat der Autor die ersten
Ideen bezüglich des V-Modells++ im Jahre
2012 vorgeschlagen. Dieses Modell versucht
als Entwicklungsmodell sowohl die Entwick-
lung als auch die QS der zu integrierenden
Systeme in einem Verbund, vorausschauend
und planbar zu gestalten und damit die Kom-
plexität besser beherrschen zu können und
die Übersichtlichkeit zu erhöhen.
Wenn das V-Modell ein Modell für die Ent-
wicklung und den Test der Systeme bis zur
Freigabe und zum Einsatz ist, ist das V-Mo-
dell++ ein Modell, um die bereits freigegebe-
nen Systeme, die im Produktivbetrieb sind, zu
integrieren und als einen Verbund in Betrieb
Abb. 1: V-Modell++, das erweiterte V-Modell für Multisysteme
zu nehmen. Das V-Modell++ beginnt erst,
8
MULTISYSTEME & MULTI-INTEGRATIONSTEST
dem vorgeschlagenen V-Modell++ eingeplant verbundenen Systemen aufzudecken. Diese der Schnittstellen bei den integrierten einzel-
und durchgeführt werden. Dem Heftschwer- Stufe spielt eine enorm wichtige Rolle in nen Systemen erforderlich sind. Es ist aber
punkt entsprechend wird hier nur auf den der gesamten Kette der QS insbesondere für oft nicht sehr einfach, diese Anpassungen
Multi-Integrationstest näher eingegangen. Qualitätsmerkmale wie funktionale Eignung, bei den Systemen, die möglicherweise von
Tiefere Einblicke in die Entwicklungsschritte Sicherheit, Benutzbarkeit, Zuverlässigkeit, unterschiedlichen Herstellerfirmen geliefert
sowie die Teststufen Multi-Systemtest und Kompatibilität und Effizienz der zusammen- werden, durchzuführen. Diese stellen sowohl
Multi-Abnahmetest sind dem Buch „Der Inte- gesetzten Funktionalitäten und Geschäfts- organisatorisch als auch technisch eine gro-
grationstest“ [Win12] zu entnehmen. prozesse. ße Herausforderung dar, weil oft bei solchen
Integrationsprojekten konkurrierende Firmen
Teststufe Multi-Integrationstest Das Ziel des Multi-Integrationstests ist es, in die Implementierung von Multisystemen
die Abweichungen in den gemeinsamen involviert sind und dabei nicht selten gewis-
Die Qualität der Integration und Kommunika- Schnittstellen und im Zusammenspiel der se politische und wirtschaftliche Aspekte so-
tion zwischen unterschiedlich voneinander integrierten Systeme zu finden. Die Ab- wie Geheimhaltung der technischen Details
entwickelten Systemen mit einer Vielzahl weichungen können durch den manuellen eine wichtige Rolle spielen.
gemeinsamer Schnittstellen im Verbund zu oder automatischen Abgleich der Soll- und
sichern, ist die Aufgabe des Multi-Integrati- Istwerte sowie durch die visuelle Überprü- Die Errichtung der erforderlichen Testumge-
onstests. Bei diesem Test wird systematisch fung der Schnittstellenzustände gefunden bung für die Durchführung des Multi-Integra-
die Kommunikation zwischen den Systemen werden. In dieser Teststufe werden die in- tionstests ist eine weitere Herausforderung
auf Protokollebene untereinander und im tegrierten Systeme gegen den detaillierten bei dem Test von Multisystemen. Die Anfor-
Verbund über ihre gemeinsamen spezifizier- spezifizierten technischen Systementwurf, derungen an die notwendige Testumgebung
ten Schnittstellen erprobt und getestet. Die meistens die Schnittstellendefinitionen für sind oft sehr speziell und dies kann den
Teststufe Multi-Integrationstest soll dazu das Multisystem, validiert. Aufbau der Testumgebung erschweren. Um
dienen, Inkonsistenzen, wie falsche oder die Integrationstests trotz unterschiedlicher
fehlerhafte Parameter- oder Werteübertra- Es ist oft durch den Test ersichtlich, dass ge- Herausforderungen effizient durchführen zu
gung, sowie Timing-Fehler zwischen den wisse Neuentwicklungen oder Anpassungen können, werden üblicherweise Mock-Objek-
Know-how für Tester
A. Spillner · T. Linz
Basiswissen Softwaretest
Aus- und Weiterbildung zum Certified Tester –
Foundation Level nach ISTQB®-Standard
6. Auflage · 2020 · 378 Seiten
komplett in Farbe · Festeinband
€ 39,90 (D) · ISBN 978-3-86490-583-4
obte
praxiserpr 9.
Ergänzt um n aus der ISO 2911
re
Testverfah
F. Simon · J. Grossmann · C. A. Graf ·
J. Mottok · M. A. Schneider M. Unterauer
Basiswissen Sicherheitstests Workshops im Requirements Engineering
Aus- und Weiterbildung zum ISTQB® Advanced M th d Ch
Methoden, Checklisten
kli t unddBBestt P
Practices
ti
Level Specialist – Certified Security Tester für die Ermittlung von Anforderungen
2020 · 414 Seiten 2. Auflage · 2020 · 226 Seiten
Festeinband komplett in Farbe · Broschur
€ 39,90 (D) · ISBN 978-3-86490-618-3 € 29,90 (D) · ISBN 978-3-86490-695-4
dpunkt.verlag GmbH · Wieblinger Weg 17 · D-69123 Heidelberg
fon: 0 62 21 / 14 83 40 · fax: 0 62 21 / 14 83 99
e-mail: bestellung@dpunkt.de · www.dpunkt.de 9
MULTISYSTEME & MULTI-INTEGRATIONSTEST
te und/oder Testtreiber definiert, implemen-
tiert und eingesetzt. Referenzen
› [Spi05] A. Spillner, T. Linz, Basiswissen Softwaretest, dpunkt.verlag, 3. Auflage, 2005
Teilintegrationstests › [Win12] M. Winter, M. Ekssir-Monfared, H. M. Sneed, R. Seidl, L. Borner, Der Integrationstest –
Von Entwurf und Architektur zur Komponenten- und Systemintegration, Hanser-Verlag, 2012
Die zentrale Frage bei der Planung und dem
Design des Multi-Integrationstests ist zu klä-
ren, welche Systeme und deren Schnittstel- Um die notwenige „Testtiefe“ in der Kette soweit wie möglich zu finden und dazu beizu-
len als Erste getestet werden müssen. Dabei der zusammengeschalteten Softwaresyste- tragen, diese möglichst einzugrenzen.
können verschiedene Faktoren, wie die inter- me zu erreichen, müssen geeignete Testda-
nen Abhängigkeiten und die zeitliche Verfüg- ten bereitgestellt werden. Die Spezifikation Fazit
barkeit der Systeme, eine wesentliche Rolle und Erstellung der relevanten Testdaten sind
spielen. Es müssen die Systeme zum Test wichtige Aufgaben, die aber oft unterschätzt Der Multi-Integrationstest führt, wenn er
genommen werden, die soweit wie möglich werden. richtig durchgeführt wird, zu einer Komposi-
unabhängig von den anderen Systemen ge- tion von mehreren unterschiedlichen Syste-
triggert und getestet werden können. Mehr als nur die Summe aller men, sozusagen einem „Vertumnus“ (siehe
Teilsysteme Abbildung 2), anderenfalls – wenn der Mul-
Diese Teilintegrationen werden, nach dem ti-Integrationstest unterschätzt und nicht
Zwiebelschalenprinzip, sukzessive um wei- Ein wichtiges Phänomen, das bei der Inte- systematisch durchgeführt wird – kann das
tere Systeme bis zu ihrem Vollumfang er- gration von mehreren Systemen vorkommen Ergebnis zu einem Desaster führen.
weitert und iterativ getestet. Ein großer kann, ist das Auftreten
Vorteil bei Anwendung dieses Ansatzes ist von ungünstigen und
es, dass durch die Iterationen die gefunde- unvorhergesehenen Ne-
nen Abweichungen besser zu lokalisieren beneffekten. Ein Multi-
und somit zu beheben sind. Für die Teilinte- system ist mehr als nur
grationstests müssen sowohl funktionale als die Summe aller kons-
auch nicht-funktionale Testfälle spezifiziert tituierenden Systeme.
und durchgeführt werden. Dabei dürfen Es ist die Summe aller
besonders die Performanztests nicht außer einzelnen Systeme, plus
Acht gelassen werden, um die Engpässe in die Summe aller Bezie-
der Kette der zusammengeschalteten Sys- hungen zwischen diesen
teme zu finden. Hier gilt, dass „ein Multi- Systemen, plus alle Zu-
system nur so stark ist wie das schwächste stände, die durch die Be-
System“. ziehung und Zusammen-
wirkung dieser einzelnen
Gesamtintegrationstest Systeme entstehen. Das
heißt:
Nach erfolgreichem Abschluss der Teilin-
tegrationstests beginnt der Gesamtinte- Multisystem = ∑ aller
grationstest. Dieser ist komplexer als die Systeme + ∑ aller Be-
Teilintegrationstests und muss für den Sys- ziehungen + ∑ aller Zu-
temverbund in seiner Gesamtheit geplant stände
und durchgeführt werden. Es muss sicher-
gestellt werden, dass die übergreifenden Der Multi-Integrations-
Transaktionen über mehreren Systemen spe- test soll auch dazu die-
Abb. 2: Vertumnus von Arcimboldo (Porträt von Kaiser Rudolf II), Quelle: Wikimedia
zifikationskonform ablaufen. nen, diese Nebeneffekte
Dipl.-Ing. Dr. Mohsen Ekssir
mohsen.ekssir@expleogroup.com
ist QA-Manager bei der Firma Expleo Group Austria GmbH und unterrichtet seit dem Jahr 2011 an der Fachhochschule Wiener Neustadt
Software-Qualitätsmanagement. Er leitet die ASQF-Fachgruppe Softwaretest Österreich und ist unter anderem Co-Autor des Buches
„Der Integrationstest“.
10ERFAHRUNG MIT INTEGRATION UND AUTOMATISIERUNG THOMAS KLEIN UND CARSTEN NEGRINI
»AGILER INTEGRATIONSTEST MIT MEHRWERT«
Eine halb agile Insel im Ozean des Wasserfallkonzerns: Für viele Fundamentalisten der Agilität ein Unding, ist sie für die meis-
ten Teams gelebter Projektalltag. Storys als vollintegriertes Inkrement im selben Sprint in den Status „DONE“ zu bringen, wird
durch verschiedene Dienstleister, Systeme und Prozesse für viele Teams im Enterprise-Umfeld nahezu unmöglich. Ein spezi-
eller Integrationstest kann hier viele Probleme der skalierten agilen Delivery abfangen und erheblichen Mehrwert schaffen.
Beim Begriff Integrationstest denkt man un- niert, scheitert spätestens im Konzernum- Die Herausforderungen
willkürlich an die rechte untere Ecke des feld kläglich. Hier fehlen elementare Voraus-
V-Modells, Testfallzahlen und Bürokratie. setzungen, damit ein agiles Team erfolgreich Der Status „DONE“ einer Story bedeutet,
Wie kann das etwas mit agiler Methodik zu ist. Dies ist keine neue Erkenntnis und gera- dass nichts mehr daran zu tun ist: Alles –
tun haben? de bei Fixed-Time-Fixed-Price-Dienstleistern inklusive jeglicher Tests – ist erledigt, das
oder Werklieferverträgen ist daher das Mo- Inkrement produktionsbereit. In der agile
Für dieses Relikt ist doch seit Scrum & Co. dell der agile delivery weit verbreitet. delivery lässt sich das nicht so schnell fest-
und CI/CD kein Platz mehr in unseren agi- stellen: Ob eine Story wirklich DONE ist,
len Teams. Allenfalls als eine Aktivität von Klingt modern und fancy. Die Idee dahinter kann erst final beantwortet werden, wenn
vielen, die während eines Sprints mit einer ist, dass der Auftraggeber problemlos in sei- der Nachweis unter Einbeziehung aller be-
Story passieren – aber doch nicht als dedi- nem Konzernwasserfall und eingefahrenen teiligten Systeme, Komponenten, Daten und
zierte Phase mit Team! Oder doch? Prozessen bleiben kann, bis alle Require- Konfigurationen erbracht wurde, die aber oft
ments (Lasten- und Pflichtenheft lassen grü- fehlen.
Der agile Idealfall ßen) fertig sind. Dann wird ein Dienstleister
mit der Implementierung beauftragt, der Lisa Crispin und Janet Gregory haben in Agile
Ein Team konzipiert, entwickelt, integriert, agil-inkrementell das Produkt herstellt. Dank Testing ([Cri14], Seiten 229, 459) beschrie-
testet und demonstriert ein Inkrement inner- agiler Methodik und Befreiung vom Konzern- ben, was das für die Integration bedeutet.
halb eines Sprints und schiebt am Ende ein ballast geht es schneller. Das fertige Produkt Frei übersetzt:
Sticky Note von „IN PROGRESS“ auf „DONE“. wird in die Konzernlandschaft implantiert.
Soweit die Theorie. › „Wenn Ihr System mit anderen zusam-
Natürlich findet auch hier ein Integrations- menarbeiten muss, kann es sein, dass Sie
test statt. Niemand nennt es aber so, denn In der Praxis ist das Team nun auf einer Insel diese nicht alle in Ihren Testumgebungen
es gibt keine Rolle namens Integrationstes- des agilen Optimismus gestrandet, umgeben darstellen können. [...] Dies ist eine der
ter, keine speziellen Integrationstestfälle und vom Ozean der Widrigkeiten: Feste Release- möglichen Situationen, in denen es un-
keine Spalte Integrationstest auf dem Scrum- termine, autoritäre Prozesse, Schnittstel- vermeidbar ist, dass Sie mit dem Test erst
board (gehört zu „IN PROGRESS“). lenpartner mit anderen Releasezyklen, starten können, wenn die Entwicklung
fehlende Product Owner, unterschiedliche schon vollständig abgeschlossen ist.“
Die Realität – „agile delivery“ Dienstleister und Zuständigkeiten. Eine Story
in nur einem Sprint abzuliefern, ist hier fast › „Simulatoren, Mocks und andere Hilfsmit-
Was im Mikrokosmos von Produkt/Feature- unmöglich, der Sprint wird zum Hindernis- tel für das Testen während der Entwick-
Innovation oder Start-up-Inselleben funktio- parcours. lung können manche Risiken verringern,
11ERFAHRUNG MIT INTEGRATION UND AUTOMATISIERUNG
aber je früher Sie Ihr Produkt in Verbindung
mit den externen Anwendungen testen
können, umso geringer wird das Risiko.“
› „Ihr Team mag agil sein, aber andere Pro-
duktteams in Ihrer Organisation oder Dritt-
anbieter, mit denen Ihr Team zusammenar-
beitet, sind es vielleicht nicht.“
› „Beginnen Sie frühzeitig damit, sich mit
anderen Produktteams oder externen
Partnern zu koordinieren, deren Produkte
mit Ihrem integriert werden sollen.“
Zusammengefasst bedeutet das Risiko ...
› ... aufgrund fehlender End-to-End-Integra-
tion während der Entwicklung.
› ... durch das Auffinden von Fehlern nach
Abschluss des Sprint/Release.
› ... durch Reibungsverluste an den Übergän-
gen zwischen agiler und klassischer Welt.
Abb. 1: Schnittstellen zwischen den Teams
› ... durch Änderungen innerhalb der Part-
nersysteme oder deren Schnittstellen.
lende, fehlerhafte oder unvollständige Kom- die Tester auch exzellente Ansprechpartner
Wie geht man damit um? ponenten, nicht verfügbare Schnittstellen für die Entwicklungs-SMEs waren (SME:
oder Partnersysteme. Wenn sich aus den Subject Matter Expert, hier die „lead“-Ent-
Ein praktisches Beispiel Sprints aller Teams die Testbarkeit einer wickler), die ihrerseits über die Scrum-Teams
Schuld ergab, wurde diese getestet und die verteilt waren (siehe Abbildung 1).
In einem aktuellen Projekt sah die agile deli- Erkenntnisse daraus wurden zurück in das
very so aus: Mehrere Scrum-Teams mit unter- Entwicklungsteam oder an den zuliefernden Um das Potenzial ausschöpfen zu können,
schiedlicher Erfahrung in agilen Prozessen, Partner gegeben (IT-Abteilung des Kunden, wurden organisatorische Maßnahmen getrof-
unzureichendes Ownership durch den Kunden Drittanbieter). fen und Prozesse definiert oder angepasst:
bei Anforderungen und Lieferantenmanage-
ment sowie überlastete kundenseitige IT. Organisation/Prozesse Es war klar, dass wir Fehler finden würden,
nachdem die Entwicklung des entsprechen-
Dass unsere Teams dennoch „abliefern“ Unsere Integrationstester als eigenes Team den Codes längst abgeschlossen wäre. Also
konnten, lag zu einem Großteil an unseren In- in einem Raum: Das war zu Beginn eine lo- machten wir aus der Not eine Tugend und
tegrationstestern, die als Mitglieder ihrer je- gistische Notlösung, die wir zugunsten inte- passten die Workflows so an, dass die Test-
weiligen Scrum-Teams an den Sprints betei- grierter Scrum-Teams abschaffen wollten, schulden fester Bestandteil unserer Back-
ligt waren und gemeinsam als Service-Unit entpuppte sich dann aber als Glücksgriff: logs wurden: Statt auf frühe Fehlerfindung
teamübergreifend agierten: zu hoffen, planten wir späte Fehler fest ein,
Da sie bei sämtlichen Scrum-Events und da sie sich ohnehin nicht vermeiden ließen.
Im Scrum-Team häufig während eines Sprints bei ihrem je-
weiligen Scrum-Team saßen, konnten sie Wir verzichteten darauf, den Integrations-
Die Testaktivitäten innerhalb des Sprints Erkenntnisse zentral sammeln und wieder test als Bestandteil der Definition of Done
wurden so weit getrieben, wie es unter Ein- in die Teams verteilen. Der Integrationstest zu schreiben. Sobald Unittests und Code-Re-
satz von Mocks/Simulatoren sinnvoll mög- entwickelte ein team- und scopeübergreifen- view erledigt waren, galt „DONE“. War et-
lich war. Alles Weitere (wir nannten es „Test- des Verständnis, quasi das „big picture“. was davon direkt testbar, feature oder bugfix,
schuld“) wurde in die Service-Unit geschoben. wurde es sofort so tief wie möglich getestet.
Der tägliche Umgang mit mehreren Umge- Alle fehlenden Testanteile wurden auf den
In der Service-Unit bungen, den builds, Partnersystemen und Parkplatz der Service-Unit geschoben.
deren Schnittstellen ergab eine enge Verbin-
Hier bestand die Hauptaufgabe darin, die dung zu DevOps und den Drittparteien. Der Natürlich entstanden daraus auch Nachteile.
team- und sprintübergreifenden Testschul- direkte Zugang zu Informationen, Problemen Diese wurden in Kauf genommen, denn die
den und deren Ursachen zu verfolgen: feh- und Lösungen in den Teams führte dazu, dass Vorteile waren wichtiger: Die Entwickler hat-
12ERFAHRUNG MIT INTEGRATION UND AUTOMATISIERUNG
Referenzen
› [Coh09] M. Cohn, The Forgotten Layer of the Test Automation Pyramid, 2009, siehe:
https://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid
› [Cri14] L. Crispin, J. Gregory, Agile Testing – A practical guide for testers and agile teams, Addison-Wesley, 2014
ten mehr Bandbreite für Backlog Grooming von elementarer Wichtigkeit ist. Ihr Fehlen Rolle des Release-Managements in unserer
oder Bugfixing und die Tester hatten mehr führt dazu, dass notgedrungen rasch unter- Integrationstest-Service-Unit zu verankern.
Bandbreite, um sich um Themen zu kümmern, schiedliche Packages ad hoc kreierter Daten
die mehr als nur ihr jeweiliges Team betra- kursieren. Extrapoliert auf mehrere Scrum- Der Integrationstest stellte fortan den Ent-
fen: den Mehrwert. Teams führte das zu einem Datenwildwuchs, wicklungsteams abgestimmte Pakete zur
in dem derselbe Code funktionierte oder Verfügung – seien es Konfigurationen, Work-
Der Mehrwert auch nicht funktionierte. flows, Testuser oder JSON/XML-snippets.
Automatisierung Hier konnten unsere Integrationstester aus Learnings
dem Vollen schöpfen: Sie saßen bei Proble-
Dadurch, dass die Integrationstester direkt men im jeweiligen Team direkt an der Quelle. Der Mehrwert entstand durch zusätzlichen
mit den Schnittstellen und Partnersystemen Andererseits hatten sie als Service-Unit den Aufwand. Also Aufwand, der zusätzlich zur
in den jeweiligen Umgebungen zu tun hatten, gesamten Überblick. Der Integrationstest Testaktivität im Sprint anfällt. Dieser Auf-
lag es nahe, dies zu instrumentalisieren. Au- hatte den „Rundumblick“, auf bestimmten wand verteilte sich zu 50 Prozent auf das In-
tomatisierte Schnittstellentests verifizierten Umgebungen, die jeweils gültige und kor- sprint-Testen (inklusive manueller Regressi-
die Funktionsfähigkeit der Partnersysteme in rekte Kombination von Software, Konfigura- onstestanteil) und 50 Prozent auf den Anteil
den integrierten Umgebungen. tion und Content zu bestimmen. der Service-Unit.
Dies war für alle Beteiligten ein enormer Ge- Das funktionierte so gut, dass gemeinsam Bei uns hat dieses Modell funktioniert, weil
winn: Fehler wurden aufgedeckt, bevor auch mit dem Kunden beschlossen wurde, die es durch alle Beteiligten getragen wurde,
nur der erste Code unserer Teams involviert wir die Prozesse entsprechend gestalten
war. Die ansonsten komplexe Fehleranalyse konnten, und weil wir bei Bedarf auf einen
(und Ressourcenbindung unserer Entwickler) Im Zusammenhang mit Automatisierung erfahrenen Testautomatisierer zurückgreifen
entfiel größtenteils. sei auf den Beitrag von Mike Cohn „Die konnten, der primär im kundenseitigen Ab-
vergessene Schicht der Testautomati-
nahmetest tätig war. Und zu guter Letzt, weil
onspyramide“ [Coh09] verwiesen: Hier
Qualitätsgesicherte Testware wir mit den richtigen Leute arbeiteten. Denn
liegt erhebliches Potenzial, das leider im
Kreuzfeuer agiler Methodik und dem Silo- es braucht einen guten Mix aus technischen
Während der ersten Sprints existiert noch denken einer umgebenden Plattformwelt Skills, persönlichen, diplomatischen und pla-
keine qualitätsgesicherte „Testware“ (user, oft brach liegt. nerischen Fähigkeiten, etwas Erfahrung und
configs, content, …), die für die Entwickler Fingerspitzengefühl und eine dicke Haut.
Thomas Klein
thomas.klein@redbots.de
ist Senior Consultant bei der redbots. Als Testmanager und Scrum Master betreut er die Projekte der redbots in den Bereichen
Softwarequalitätssicherung und agiler Methodik.
Carsten Negrini
carsten.negrini@redbots.de
ist Geschäftsführer der redbots und arbeitet daran, die Effizienz von IT-lastigen Organisationen zu optimieren.
13ANFORDERUNGEN UND TESTS NICHT VERNACHLÄSSIGEN JOACHIM SCHULZ
»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.
Eine Problematik liegt darin, dass die Sys- Drittherstellern, sei es Hardware (HW) oder Begründet wird dies meist damit, dass die
teme unserer Zeit immer mächtiger und Software (SW). Weiterhin wird in vielen Pro- bewährten Entwicklungsprozesse „nicht
komplexer werden. Softwareanwendungen jekten eine Middleware eingesetzt, welche passend“ für das jeweilige Projekt seien und
sind nur selten noch Stand-alone-Program- die einzelnen Komponenten zu einem kom- deshalb ein eigener Prozess genutzt wird.
me, sondern vernetzen Informationen aus pletten System verbindet. Dieser ist dann meist nicht näher definiert,
diversen Quellen (z. B. Apps nutzen zahllose geschweige denn in einem Projekthandbuch
Web-Services Dritter). Hardwareprodukte Diese gestiegene Komplexität erfordert bei dokumentiert.
besitzen komplexe Softwaresteuerungen, der Systementwicklung äußerste Sorgfalt.
welche nun unter dem Schlagwort „Internet Mängel hierbei können heutzutage nicht Gerade in Projekten, die „agil“ sein wollen,
der Dinge“ vernetzt werden (z. B. digitale mehr durch einzelne sehr erfahrene Entwick- wird das agile Manifest geradezu miss-
Stellwerke der Bahn). Selbst vermeintlich ler ausgeglichen werden, denn die Komple- braucht, um ungeplantes Arbeiten auf Zuruf
einfache Alltagsprodukte werden für die be- xität des Gesamtsystems kann in der Tiefe zu rechtfertigen und Dokumentation als ge-
queme Bedienung von überall vernetzt (z. B. nicht mehr von einer Person erfasst werden. nerell überflüssig abzulehnen. Eine erfolg-
Smart-Home-Produkte). reiche Systementwicklung erfordert es aber,
„Mein“ Entwicklungsprozess dass die Spezialisten eines Teams Hand-in-
Mächtig komplex Hand zusammenarbeiten, damit der Entwick-
Erprobte Entwicklungsprozesse sind bereits lungsprozess gelingen kann.
Häufig handelt es sich auch nicht mehr um ausgiebig beschrieben, sei es das klassische
ein homogen entwickeltes System eines ein- Vorgehensmodell (V-Modell) oder agile Ent- sepp.med empfiehlt:
zigen Entwicklungsteams, sondern es wird wicklungsprozesse wie Scrum. In der Praxis
von verteilten Spezialistenteams entwickelt. stößt man jedoch nicht selten auf lücken- › Definieren Sie Ihren Entwicklungspro-
Ferner beinhaltet das System oft ältere Vor- hafte Prozesse, bei denen häufig nur die zess (z. B. Projekthandbuch, „Sprint 0“ in
gänger-Subsysteme und Subsysteme von Programmiertätigkeit im Vordergrund steht. Scrum).
› Nutzen Sie bewährte Ent wicklungsme-
thoden.
› Dokumentieren und hinterfragen Sie eige-
ne Adaptionen.
System mit Fundament
Konzentrieren wir uns im Folgenden zunächst
auf das V-Modell (siehe Abbildung 1) und
die klassische Entwicklung. Basis eines Sys-
tems ist das kundenseitig erstellte Lastenheft
und darauf aufbauend die Systemspezifikati-
on, das Pflichtenheft. Die Komplexität wird
dann zerlegt über den Systementwurf (Ar-
chitektur & Schnittstellenspezifikation). Für
komplexe Datenschnittstellen ist zu empfeh-
len, diese in separaten Dokumenten zu be-
schreiben, da diese für jedes an der Kommu-
nikation beteiligte Subsystem genutzt wird
und Schnittstellen ebenfalls einer Versionie-
rung unterliegen, wenn sie weiterentwickelt
Abb. 1: Vorgehensmodell (V-Modell) mit den Abstraktionsebenen
werden.
14ANFORDERUNGEN UND TESTS NICHT VERNACHLÄSSIGEN
› Jede Anforderung hat eine Motivation,
das heißt, sie hat mindestens einen Vor-
gänger (kein „Gold-Plating“).
› Jede Anforderung wird weiter verfeinert,
das heißt, sie hat mindestens einen Nach-
folger (keine Umsetzungslücken).
› Stellen Sie klare prüfbare Regeln für die
Verfolgbarkeit (Traceability) durch die Do-
kumente auf (z. B. Verlinkung nur zwischen
benachbarten Ebenen).
Abstraktionsebenen prüfen
Abb. 2: Schematische Darstellung der Anforderungstraceability über drei Abstraktionsebenen
Bei der strikten Umsetzung dieser Regeln
treten im Bereich des Anforderungsmana-
Für jedes Subsystem ist dann eine Subsys- Es ergibt sich schnell eine große Menge an Do- gements teilweise Probleme auf. Ursache
temspezifikation zu erstellen, in der das kumenten mit einer hohen Zahl von Anforde- sind hierfür nicht zu strikte Regeln, sondern
jeweilige Subsystem als „Black Box“ be- rungen. Bei sauber definierten Prozessen und lückenhafte Anforderungen oder die fehler-
schrieben wird. Gegebenenfalls können noch klaren Regeln für das Anforderungsmanage- hafte Zuordnung der Anforderung zur Abs-
weitere Verfeinerungsebenen für Kompo- ment kann nun ein belastbares Fundament für traktionsebene (= Spezifikationsdokument,
nenten und Module folgen. Für diese gelten alle folgenden Entwicklungsschritte gelegt siehe Abbildung 2). Fordert der Kunde in
die weiter unten beschriebenen Grundsätze werden. Idealerweise verfeinern sich die An- seinem Lastenheft zum Beispiel nur eine
selbstverständlich ebenso. forderungen von Ebene zu Ebene wie folgt: spezielle Benachrichtigungsinformation nach
EIN MUSS
FÜR DEN
S-
INTEGRATION
TESTER
Certified Tester Training
zum Testautomatisierungsentwickler
German Testing Board e. V.
info@german-testing-board.info
www.german-testing-board.info 15ANFORDERUNGEN UND TESTS NICHT VERNACHLÄSSIGEN
1000 Betriebsstunden für
die Wartung des Systems,
so meint er vermutlich eine
komplexe Diagnoseschnitt-
stelle über die Statusinfor-
mationen, 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 kor-
rekt dem Spezifikationsdo-
kument zugeordnet ist, kann
sehr gut geprüft werden, in-
dem die korrespondierende
Testphase betrachtet wird.
Lässt sich die Anforderung
wirklich in dieser Phase
testen oder gehört Anfor-
derung und Test in eine
andere Abstraktionsebene?
Wird zum Beispiel in einer
Abb. 3: Schematische Darstellung zum anforderungsbasierten Testen
Schnittstellenspezifikation
gefordert, dass innerhalb
von 100 ms eine Anfrage korrekt beantwor- tion von Schnittstellen und Subsystemen down- oder Botton-up-Integration ermög-
tet werden muss, so ist diese falsch zugeord- sollten nicht nur die funktional erlaubten lichen es, frühzeitig mit Integrationstests
net. Es ist eine Anforderung an das Subsys- Datenwerte im Funktionsbereich betrachtet zu beginnen, allerdings benötigen diese
tem! Für die Schnittstellenspezifikation ist werden, sondern der gesamte Wertebereich, Platzhalter (für die fehlenden Funktio-
zutreffend, dass es einen Timeout nach 100 der technisch über diese Schnittstelle über- nen) oder Testtreiber (für den Aufruf). Die
ms gibt. Das befragte Subsystem soll beim mittelt werden kann. Wahl einer passenden Strategie hängt
Timeout eine qualifizierte Fehlernachricht von den Projektgegebenheiten ab, jedoch
generieren und versenden. Das anfragende Das Subsystem sollte robust ausgelegt sein, sollte die „Big Bang“-Strategie vermieden
Subsystem muss diese Fehlernachrichten sodass im Falle von fehlerhaften Signalen werden.
behandeln sowie eigenständig Timeouts oder inkonsistenten Daten qualifizierte Fehler-
feststellen (falls die Kommunikation unter- meldungen zurückgemeldet werden. Selbst- sepp.med empfiehlt:
brochen ist). verständlich muss das aufrufende Subsystem
adäquat auf mögliche Fehler reagieren. › Nutzen Sie – wenn möglich – inkremen-
sepp.med empfiehlt die Prüfung (s. Abb. 3): telle Integrationsstrategien.
sepp.med empfiehlt:
› Sind die Anforderungen den richtigen An- › Stimmen Sie die Integrationstests mit den
forderungsdokumenten zugeordnet? › Betrachten Sie den kompletten Wertebe- Zeitplänen des Projektes ab und aktuali-
reich der Schnittstellen. sieren Sie diese im Bedarfsfall.
› Sind die Anforderungen in der jeweils kor-
respondierenden Testphase prüfbar? › Legen Sie Subsysteme robust aus. Fokussierung
beim Integrationstest
Robuste Systeme Integrationsstrategie
Fokus des Integrationstests ist die Überprü-
Bei der Definition von Schnittstellen emp- Bereits im Testkonzept sollte festgelegt fung, ob die zu integrierenden Subsysteme
fiehlt es sich, bereits vorhandene, stan- werden, welche Integrationsstrategie an- zusammen korrekt funktionieren. Vorausge-
dardisierte Schnittstellen zu nutzen. Diese gewendet werden soll. Beim „Big Bang“ setzt wird, dass die einzelnen Subsysteme
sind bewährt, gewähren Interoperabilität, werden alle Subsysteme gleichzeitig integ- funktionstüchtig sind, also die Subsystem-
ermöglichen den einfachen Austausch von riert. Nachteilig ist hier, dass die Fertigstel- tests abgeschlossen sind.
Subsystemen (z. B. von einem anderen Her- lung aller Subsysteme abgewartet werden
steller) und vereinfachen die Einarbeitung muss und alle Fehlerwirkungen gleichzeitig Damit gibt es eine strikte Trennung zwischen
von neuen Mitarbeitern. Bei der Spezifika- auftreten. Inkrementelle Strategien wie Top- diesen beiden Testphasen! Beim Integrati-
16ANFORDERUNGEN UND TESTS NICHT VERNACHLÄSSIGEN
onstest muss lediglich geprüft werden, ob
die Systeme korrekt miteinander kommuni-
zieren. Typische Fehler sind zum Beispiel das
Vertauschen von Pins bei der Verkabelung
der Subsysteme, das Nichtbeachten von
eingeschränkten Wertebereichen, welches
ein Subsystem voraussetzt oder neue bezie-
hungsweise geänderte Nachrichten, da die
Subsysteme unterschiedliche Versionen ei-
ner Schnittstellenspezifikation nutzen. Kurz-
um: Es ist beim Integrationstest zu prüfen, ob
die Subsysteme sich „verstehen“ und zusam-
menspielen – nicht mehr und nicht weniger
(siehe Abbildung 4).
sepp.med empfiehlt:
› Trennen Sie strikt die Testphasen zwi-
schen Subsystem- und Integrationstest
voneinander ab.
› Beachten Sie die Testreihenfolge – zuerst
Abb. 4: Beispiel für Integrationsstrategie mit den Subsystemtests und Integrationstests
die Subsystemtests abschließen!
Frühzeitig testen – sepp.med empfiehlt: Inkrement des Systems durchgeführt werden
auch beim Integrationstest können.
› Beplanen Sie die Testaktivitäten ab Pro-
Wie bei anderen Testphasen auch sollten jektstart. In der Praxis anzutreffen sind Projekte, deren
die Aktivitäten für den Integrationstest Subsysteme agil entwickelt werden, formale
frühzeitig beginnen (Projektplanung – Test- › Führen Sie die jeweiligen Testaktivitäten Abnahmen mit Integrations- und System-
konzeption – Anforderungsermittlung & -ab- so früh wie möglich durch. tests sowie weitere Aufgaben für die Auslie-
stimmung – Systemarchitektur). Die Spezifi- ferung (Dokumentationen, Inbetriebsetzung)
kation der Integrationstests kann sofort nach › Sichern Sie mit Vorabtests die generelle jedoch „klassisch“ zu bestimmten Zeitpunk-
Abschluss der Anforderungsspezifikation Funktion der Schnittstellen. ten stattfinden.
begonnen werden. So können Fehler oder Lü-
cken der Anforderungsspezifikation zeitnah Agil? – Alles anders? Fazit
aufgedeckt werden.
Nein! Prinzipiell gibt es die Testphasen auch Zusammenfassend lässt sich feststellen,
Auch wenn für die finale Durchführung des bei der agilen Entwicklung. Insofern sind dass die Entwicklungsprozesse vieler Pro-
Integrationstests zuerst auf den Abschluss auch die Integrationstests mit zu betrachten. jekte ausschließlich die Programmierung fo-
der Subsystemtests gewartet werden muss, Oft werden diese aber implizit im Rahmen kussieren. Anforderungen und Tests werden
können vorab durchgeführte Integrations- des Systemtests mit durchgeführt. Werden gerne vernachlässigt. Dies stellt jedoch ein
tests von Vorversionen der Subsysteme (mit aber Integrationstests explizit gefordert unnützes Projektrisiko dar, welches insbe-
eingeschränkter Funktionalität) sinnvoll sein. (z. B. aufgrund der Kritikalität des Systems), sondere in Zeiten von Fachkräftemangel,
Mit diesen Vorabtests kann sichergestellt so müssen diese auch bei der agilen Ent- Fluktuation von Mitarbeitern und dem Willen
werden, dass die Subsysteme mindestens wicklung explizit berücksichtigt und doku- nach Wiederverwendung von (Sub-) Syste-
bei den grundlegenden Funktionen korrekt mentiert werden. Automatisierte Tests sind men unverständlich ist.
zusammenspielen. unverzichtbar, damit Tests zügig für jedes
Joachim Schulz
joachim.schulz@seppmed.de
ist als Senior Berater für die sepp.med gmbh tätig. Der Diplom-Informatiker nutzt sein branchenübergreifend erworbenes Wissen, um
in den Bereichen Requirements Engineering, Test und Qualitätssicherung praxisorientierte Lösungen zu finden. Sein Tätigkeitsspektrum
reicht von der Schärfung von Entwicklungsprozessen, Einführung von Methoden und Tools bis hin zur fachlichen Projektarbeit.
17Sie können auch lesen
