TESTAUTOMATISIERUNG

SO WIRD DER GERMAN TESTING DAY – EIN VORBERICHT

– Verlagsbeilage –

(TEST-)AUTOMATISIERUNG: VON DER KÜR ZUR PFLICHT!

TESTEN VON MICROSERVICES

OHNE AUTOMATION?

DAS BERUFSBILD DES TESTAUTOMATI- SIERUNGSEXPERTEN

Smart. Agile. TestBench.TestBench Cloud Services simplifies and improves the testing performance in agile teams.

Try it for free for 90 days: TBGTM01201890days.testbench.com

Raw

pixe

l.com

@fo

tolia

.com

3

EDITORIAL / INHALT

TesTauTomaTisierungEffizienzsteigerung und Digitalisierung sind heute in aller Munde. Dies spürt man besonders deutlich beim Testen von Systemen, das meist unter hohem Zeit- und Kostendruck steht bei gleichzeitig hoher Ver-antwortung für die abgelieferte Qualität. War die Testautomatisie-rung bis jetzt primär ein Mittel zur Effizienzsteigerung, ist sie heute essenzielles Mittel, um Softwaretests überhaupt in entsprechender Qualität zu leisten und gleichzeitig die Komplexität der Systeme zu beherrschen.

Diese Ausgabe des German Testing Magazins behandelt die Auto-matisierung im Test. Als Autoren zu diesem wichtigen Thema konn-ten wir Ina Schieferdecker, Axel Rennoch und Michael Wagner, Rudolf Götz sowie Manfred Baumgartner und Alexandra Sumper gewinnen. Sie bringen uns in verschiedenen Zusammenhängen so-wohl die Wichtigkeit der Testautomatisierung im Kontext als auch die Ausbildung in diesem Bereich näher. Darüber hinaus enthält diese Ausgabe auch eine Vorschau auf den German Testing Day 2018 in Frankfurt.

Wir wünschen den Lesern dieses Heftes viel Vergnügen, Inspiratio-nen und neue Anregungen zu den täglichen Herausforderungen im Test. Weitere Informationen zu diesen und anderen testbezogenen Fragen finden Sie auf den Seiten des German Testing Board.

sponsoren inhalT(Test-)Automatisierung: Von der Kür zur Pflicht!

Stephan Weißleder und Richard Seidl  4

Das Internet der Dinge digitalisiert den Mittelstand

Axel Rennoch, Ina Schieferdecker und Michael Wagner  6

So wird der German Testing Day - ein Vorbericht

Thomas Rinke und Melanie Wohnert  10

Testautomatisierung, Ja! Doch wer macht’s?

Manfred Baumgartner und Alexandra Sumper  12

Testen von Microservices mit Consumer-Driven Contracts

Rudolf Grötz  17 Impressum 23

Ihre

Dr. Stephan Weißleder und Richard Seidl

GTB-Lehrpläne

4

TESTAUTOMATISIERUNG 2018

Qualitätssicherung muss nicht nur effektiv, sondern auch effizient sein. Automatisierung ist hier das Mittel der Wahl zur Effizi-enzsteigerung und längst den Kinderschuhen entwachsen. Neue Herausforderungen an die Qualitätssicherung und insbeson-dere an die Testautomatisierung lassen jedoch nicht auf sich warten: Höhere Effizienz, bessere Integration in agile und kontinu-ierliche Ansätze, komplexere Systeme mit mehr Schnittstellen gepaart mit Anforderungen an Safety, Security und Robustheit sind nur ein paar Aspekte, denen sich Testautomatisierer heute stellen müssen.

»(TesT-)AuTomATisierung: Von der Kür zur PflichT!«

Zu den Grundlagen der Softwareentwicklung gehört neben dem Design und dem Schrei-ben der Software auch die Qualitätssiche-rung dieser. Der Test ist das am häufigsten angewandte Mittel der Qualitätssicherung und vergleicht das tatsächliche Verhalten der Software mit dem erwarteten Verhalten.

Diese Prüfung kann jedoch sehr aufwendig sein. Insbesondere ist der Aufwand für Re-gressionstests nach kleineren Änderungen in der Software vergleichsweise hoch: Regres-sionstests müssen beispielsweise ausge-führt werden, um nachzuweisen, dass Ände-rungen in der Software keine unerwünschten Nebeneffekte haben. Da hierbei gerade auch Funktionalität getestet wird, die durch die Änderungen nicht betroffen sein soll, wird leicht offensichtlich, dass der Anteil der aus-zuführenden Tests an der Gesamtmenge der Tests den Anteil der Softwareänderungen an der Gesamtmenge der Software übertrifft. Entsprechend aufwendig kann der Test ge-genüber der Softwareerstellung werden, insbesondere wenn er manuell durchgeführt wird.

Da es sich bei der Durchführung von Tests und insbesondere von Regressionstests oft um Wiederholungen handelt, drängt sich die automatische Durchführung dieser Tests als Mittel der Effizienzsteigerung förmlich auf.

Von der Kür zur Pflicht

Lange Zeit war automatische Testdurchfüh-rung ein Add-on zur manuellen Testdurch-führung – manchmal sogar nur Spielerei: Passende Testfälle wurden ausgewählt und mithilfe von Automatisierungswerkzeugen wurden entsprechende Testskripte aufge-zeichnet oder implementiert. Das hat dann mehr oder weniger gut funktioniert und war auf Dauer eher weniger als gut wartbar. Oft-

mals auf Initiative Einzelner wurden Lösun-gen geschaffen, damit Werkzeuge und Test-skripte weiterhin nutzbar waren.

Diese Zeiten liegen hinter uns. Nicht zuletzt durch Paradigmenwechsel wie agile Soft-wareentwicklung oder durch die zunehmen-de Komplexität der entwickelten Systeme ist Testautomatisierung heute unabdingbar. In vielen Projekten werden Tests über alle Ebenen mit verschiedensten Werkzeugen automatisiert durchgeführt und die Testüber-deckung sukzessive erhöht. Dies hat auch zu einem deutlichen Sprung bei der Werk-zeugunterstützung geführt: Die Werkzeuge für die Testautomatisierung sind heute sta-biler, bieten mehr Komfort, bieten leichtere Wartbarkeit der Testskripte und lassen sich allgemein den Bedürfnissen der Testautoma-tisierer besser anpassen.

Testautomatisierung ist mehr als Testdurchführung

Der Begriff Testautomatisierung wird oft-mals mit automatischer Testdurchführung gleichgesetzt. Es gibt darüber hinaus natür-lich den automatisierten Testentwurf. Um die mit steigender Anzahl von Testfällen ebenfalls steigenden Wartungskosten für die Testskripte überhaupt handhabbar zu halten, muss auch der Testentwurf automatisiert werden: Durch zusätzliche Abstraktions-ebenen wird von Unwesentlichem abstra-hiert – Testskripte können automatisch auf Basis von Modellen generiert werden.

Doch damit ist das Potenzial, welches die Au-tomatisierung für den Test heute bietet, bei Weitem nicht ausgeschöpft – im gesamten Prozess lassen sich unzählige Aktivitäten fin-

RICHARD SEIDL UND STEPHAN WEISSLEDER

5

TESTAUTOMATISIERUNG 2018

den, die automatisiert oder teilautomatisiert erstellt, durchgeführt oder geprüft werden können. Dabei verschwimmen die Grenzen zwischen Test, Qualitätssicherung und Ent-wicklung zusehends. Ein paar Beispiele fin-den sich im Kasten.

Testautomatisierung als Integrationsfaktor

Gerade in agilen Projekten zeigt sich unse-rer Erfahrung nach ein interessantes Bild. Hier muss Testautomatisierung von Beginn an gelebt werden, da andernfalls eine hohe Qualität in der Software nicht zu halten ist. Doch hat die Testautomatisierung hier noch einen sozialen Aspekt, denn die notwendige Formalisierung vorab bringt verschiedene, auch (bislang) autark arbeitende Teilnehmer dazu, sich früher über ein gemeinsames The-ma auszutauschen als zuvor – gerade wenn hybride Projektstrukturen vorherrschen, wo zum Beispiel der Fachbereich nicht Teil des Teams ist. So kann man überschwänglich sogar Testautomatisierung als teambildende Maßnahme sehen.

Fazit

Stand 2018 ist die Testautomatisierung schon deutlich den Kinderschuhen entwach-sen, auch wenn es immer noch genug Luft nach oben gibt. Testautomatisierung schafft es nun, die Versprechungen an Effizienz und Wiederholbarkeit zu erfüllen und ist in der Anwendung deutlich einfacher und pflege-

leichter geworden. Aber nicht zuletzt lässt sich Testautomatisierung in Projekten dazu nutzen, verschiedene Rollen in Kontakt und ins Gespräch zu bringen, die bis dato eher autark agiert haben. Zum Beispiel um fest-zulegen, wo Automatisierung auch aus Risi-kosicht sinnvoll ist oder zum Value beiträgt.

Doch auch wenn die Unterstützung der Au-tomatisierung in den letzten Jahren deutlich besser geworden ist, lauern immer noch Fall-stricke: Inkompatibilitäten, Schnittstellen-probleme, instabile Umgebungen oder feh-lende Datenqualität können den Aufwand für Erstellung und Wartung der Testskripte in die Höhe treiben. So sind immer mit ei-nem Auge auch der Nutzen und die Risiko-abschätzung im Blick zu behalten, damit die Testautomatisierung nicht zum Selbstzweck wird.

Die nächsten Jahre werden hier sehr span-nend. Durch den Einsatz von Machine-Lear-ning und Artificial Intelligence stehen ganz neue Felder und Einsatzmöglichkeiten offen, die gerade erst im Ansatz genutzt werden. Fakt ist, dass es diese Mechanismen brau-chen wird, um die Qualität der Software und der Daten weiterhin hochzuhalten. Denn eines ist heute schon eingetreten: Oftmals überblickt keiner mehr die komplette Soft-ware, die Architektur oder die benötigten Da-ten. Hier sind intelligente Systeme gefragt, die uns diese Informationen verständlich präsentieren und automatisch Widersprüche aufdecken.

»Beispiele für automatisierBare aktivitäten«

› Statische Analyse: › Codeanalyse, › Artefaktprüfungen und › Unterstützung beim Refactoring.

Testdatenmanagement:

› Generieren von Testdaten, › Anonymisieren von produktionsnahen

Testdaten, › Befüllen und Leeren von Datenbanken und › Archivierung von Testdaten.

Testumgebung:

› Setup von Betriebssystemen, › Konfiguration von virtuellen Maschinen

und › (Wieder-)herstellen eines definierten

Zustands der Testumgebung.

Bereitstellung:

› Quality-Gates, › Build-Pipeline und › Deployments und automatisierte Tests.

Dokumente:

› Generieren von Reports, › Auswerten von Metriken und › Analyse von Anforderungen.

Nicht-funktionale Tests:

› Security-Tests, › Last- und Performance-Tests, › Stresstests und › Usability-Tests.

Dr. Stephan Weißlederstephan.weissleder@gmail.comglaubt an die Erneuerung durch Digitalisierung. In der smarten Automatisierung liegt die Chance, hocheffiziente Prozesse mit der für Innovationen notwendigen Muße zu verknüpfen. Der Test ist hierbei sein Haupttätigkeitsfeld: Als letzter in der Entwicklungskette und somit ständigem Zeit- und Innovationsdruck ausgesetzt, offenbart sich dem Test durch Automatisierung enormes Potenzial. Das fängt bei der Durchführung an und reicht bis hin zu smarter Testerzeugung.

Richard Seidlmail@richard-seidl.comhat sich der Qualität von Software verschrieben. Er hat in seiner beruflichen Laufbahn schon viel Software gesehen und getestet: gute und schlechte, große und kleine, neue und alte. Für ihn ist Qualität eine Haltung, die man wirklich leben kann, anstatt sie nur abzuar-beiten. Sein Schwerpunkt liegt in der Begleitung von agilen und traditionellen Entwicklungs- und Testteams auf dem Weg zu höherer Qualität, mehr Produktivität und mehr Freude am Tun.

6

DIE TESTWARE FÜR DAS INTERNET DER DINGE

Das Internet der Dinge – englisch Internet of Things, kurz IoT – ist heute aus unserem Alltag nicht mehr wegzudenken. Elektro-nische Geräte – von komplexen Produktionsanlagen oder vernetzten Maschinen bis hin zu unserem Smartphone, Fitnessarm-bändern oder Autos – sind immer häufiger miteinander vernetzt. Dabei erzeugen sie Daten und tauschen diese über das Internet miteinander aus. Schätzungen von Cisco Systems zufolge wird es bis 2020 rund 50 Milliarden weltweit vernetzte Geräte geben. Diese digitale Transformation stellt auch Unternehmen vor neue Herausforderungen.

»Das Internet Der DInge DIgItalIsIert Den MIttelstanD«

Vor allem große Unternehmen nutzen das Internet der Dinge, um Prozesse zu automati-sieren und so effizienter arbeiten zu können. Auch Mittelständler müssen sich mit den Chancen des IoT beschäftigen, um wettbe-werbsfähig zu bleiben. Kleine und mittlere Unternehmen (KMU) stehen dabei vor zwei großen Herausforderungen:

› zum einen die finanziellen und zeitlichen Investitionen, die für die Einführung von digitalen Innovationen anfallen,

› zum anderen die hohen Anforderungen an die Sicherheit und Leistungsfähigkeiten der neuen Lösungen.

Letzteres umfasst nicht nur die Vermeidung von Fehlern bei der Entwicklung neuer Sys-teme, sondern auch den ausreichenden Schutz der unternehmenskritischen Daten, beispielsweise vor Hackerangriffen. Daher ist es für Unternehmen aller Größen wichtig, die IoT-Systeme, -Software und -Geräte vor

ihrer Einführung umfassend auf die Aspekte Sicherheit, Vertrauenswürdigkeit, Funktiona-lität, Interoperabilität und Robustheit hin zu testen.

So können noch vor der Anwendung der IoT-Lösungen Fehler bei der Entwicklung ver-mieden und Sicherheits- sowie Datenschutz-anforderungen ausreichend berücksichtigt werden. Solche Tests sparen nicht nur die Kosten für spätere Nachbesserungen, son-dern ermöglichen auch, dass die digitalen Lösungen schneller in den Unternehmen zur Anwendung kommen.

Eclipse IoT-Testware

Bisher gab es kaum Werkzeuge, die KMU nutzen konnten, um ihre IoT-Lösungen aus-reichend zu testen. Daher hat das Fraunho-fer-Institut für Offene Kommunikationssys-teme (FOKUS) in Zusammenarbeit mit der Eclipse Foundation, dem IoT-Spezialisten Relayr und vielen weiteren Unternehmen wie

Ericsson und Spirent die IoT-Testware entwi-ckelt [Sch17].

Die Eclipse Foundation ist eine gemeinnüt-zige Open-Source-Gemeinschaft, die im Rahmen verschiedener IT-Projekte Platt-formen für die Entwicklung von Software, Software-Komponenten und -Werkzeugen bereitstellt [Eclipse]. Software für IoT-Tests wird bei der Eclipse Foundation im Rahmen des Projekts Eclipse Technology [EcTP] ent-wickelt, wozu auch die IoT-Testware gehört. Die IoT-Testware nutzt als Testautomati-sierungswerkzeug Eclipse Titan [EcTitan]. Diese Umgebung wurde zum Kompilieren und Ausführen von TTCN-3-Testcode [Gra14, TTCN3] entwickelt. TTCN-3 (Testing and Test Control Notation) ist eine bei ETSI und ITU offen standardisierte Testautomatisierungs-technologie.

Die Fähigkeiten der IoT-Testware wurden bereits in [Kai17] vorgestellt. Hier wurden mit ca. 50 Testfällen die Unterschiede in

AXEL RENNOCH, INA SCHIEFERDECKER UND MICHAEL WAGNER

7

DIE TESTWARE FÜR DAS INTERNET DER DINGE

verschiedenen Implementierungen von MQTT-Brokern mittels Conformance-Testen untersucht. MQTT ist das „Message Queuing Telemetry Transport“-Protokoll [MQTT]. Es ist ein leichtgewichtiges, offenes Nachrich-tenprotokoll für Machine-to-Machine-Kom-munikation (M2M), das die Übertragung von Telemetriedaten zwischen IoT-Geräten auch bei hohen Verzögerungen oder anderen Ein-schränkungen in Netzen ermöglicht.

Mithilfe der Testsuite wurden zum Beispiel Abweichungen bei der Behandlung von MQTT-Nachrichtenelementen gefunden, unter anderem wurden von den getesteten Brokern sogenannte „reserved“-Flags nicht erkannt beziehungsweise entgegen dem Standard behandelt. „Inconclusive“ Ergeb-nisse ergaben sich bei den Tests mit fehler-haften Zugangsdaten, die auf Einschränkun-gen bei der Konfiguration zurückzuführen waren. Anhand der Ergebnisse können sich Anwender für Implementierungen entschei-den, die einen hohen Grad an Konformität und Zuverlässigkeit ermöglichen.

Basierend auf den funktionalen Testszena-rien entstehen auch Performanz- und Sicher-heitstests. Während die Performanztests insbesondere mit dem freien, von Ericsson entwickelten IoT-Performanz-/Last-Tester RIoT (einer Implementierung mittels Titan-SIM [Böh16]) erfolgen, werden für die Sicher-heitstests die Programme der von FOKUS entwickelten Fuzzing-Bibliotheken Fuzzino [FOKUS] einbezogen. Abbildung 1 zeigt den Einsatz der IoT-Testware in Verbindung mit Fuzzino für die Sicherheitstests an einem

CoAP-Server. Wireshark dient hierbei der (passiven) Gewinnung von Daten zur Para-metrisierung der Fuzzing-Bibliothek.

IoT-Lösungen vor der Einführung testen

Die im IoT-T Projekt entwickelten Testlösun-gen ermöglichen es, Software- und künftig auch Hardwareschnittstellen für das IoT zu testen. Für die Prozessunterstützung stellt das Projekt IoT-T zudem IoT-Testlabs zur Ver-fügung. Diese werden sowohl von der DEK-RA als auch von Fraunhofer IPK und Fraunho-fer FOKUS betrieben. Die Teams der Testlabs unterstützen Unternehmen dabei, eigene Testlabore in ihren Unternehmen einzurich-ten, um zukünftig selbstständig und ohne viel Aufwand IoT-Lösungen vor ihrem Einsatz überprüfen zu können.

Die DEKRA wird nach Ablauf des Projekts in ihrem IoT-Testlab die unabhängige Prüfung und Zertifizierung anhand von nationalen und internationalen Standards anbieten. Dadurch können Entwicklungszeiten und -kosten ge-senkt und abgesicherte IoT-Lösungen in Un-ternehmen eingeführt werden.

Praxistest im Bereich Automotive und Produktion

Aktuell testet das Projekt IoT-T seine Test-lösungen im Automotive-Bereich und in der industriellen Produktion. So nutzt der Au-tohersteller Audi die OPC-UA-Testfälle der IoT-Testware. Konkret werden IoT-Anwen-dungen getestet, bevor sie in der Shopfloor-

IT eingesetzt werden. Dieser Bereich ist zuständig für den Abgleich zwischen Produk-tion und Lagerbeständen. Reibungslose und automatisierte Abläufe sind hier unbedingt notwendig, um den Produktionsfluss nicht zu unterbrechen. Aufbauend auf diesem Praxis-einsatz steht das IoT-Testlab in Berlin den KMUs für die Überprüfung ihrer IoT-Software und -Geräte zur Verfügung.

TST-Arbeitsgruppe des ETSI

Über Eclipse hinaus verfolgt Fraunhofer FO-KUS das Ziel, die IoT-Testware auch mittels europäischer Standards weiterzuentwickeln. So wurde die neue ETSI-Arbeitsgruppe „Testing“ (TST) des Technischen Arbeitsgre-miums „Methods for Testing and Specifica-tions“ (MTS) beim „European Telecommuni-cations Standards Institute“ (ETSI) etabliert [ToR].

Zu den ersten Themen der TST-Gruppe zäh-len die Erstellung von Studien, Empfehlun-gen, Testkatalogen und -spezifikationen für die Ebenen entsprechend der IoT-High-Level Architecture von AIOTI [HLA]: IoT-Netzwerk-schicht, IoT-Schicht und Anwendungsschicht. Für die Beschreibung der Testziele wurde die von ETSI entwickelte Notation TDL-TO [TDL] ausgewählt, deren Beschreibungen sich mittels Open-Source-Werkzeugen sowohl in gebräuchlichen Tabellen im Word-Format darstellen als auch in TTCN-3-Codesequen-zen übersetzen lassen.

Das IoT-Quality-Engineering- Weiterbildungsschema

Da Technologien und Werkzeuge insbeson-dere von Experten erfolgreich angewendet werden können, wurde zudem auf Einladung des ASQF (Arbeitskreis Software-Qualität und Fortbildung) und in Kooperation mit dem GTB (German Testing Board) ein neues Wei-terbildungsschema für die Entwicklung und Absicherung qualitativ hochwertiger IoT-Lö-sungen erarbeitet [CPIoT].

Für den „Certified Professional for IoT“ geht es nicht um die reine Validierung „am Ende“, sondern die vorausschauende Erlangung von Qualitätskriterien von den ersten Entwick-lungsschritten an. So spielt zum Beispiel die Priorisierung der relevanten Qualitätskrite-rien einer IoT-Lösung eine entscheidende Rolle. CPIoT-Zertifikatskurse werden seit Fe-bruar 2018 angeboten. Der Lehrplan umfasst Kapitel unter anderem zu IoT-Qualitätsmerk-

Abb. 1: Fuzzing auf der Basis der CoAP-Tests

8

DIE TESTWARE FÜR DAS INTERNET DER DINGE

malen, IoT-Architekturen, Prozesse und Me-thoden für das konstruktive Quality Enginee-ring, Analytisches Quality Engineering (inkl. Test) sowie Lifecycle-Management für IoT.

Zusammenfassung

Im vom Bundesministerium für Wirtschaft und Energie geförderten Projekt IoT-T [IoT-T] erarbeiten wir auf IoT abgestimmte Teststra-tegien, Lösungen zur Testautomatisierung sowie Testwerkzeuge für individuelle Test-läufe und Interoperabilitäts-Testevents. Die in IoT-T erstellte IoT-Testware ist Teil einer umfassenden Strategie zur Qualitätssiche-rung von IoT-Lösungen. Grundlage ist die konsequente Anwendung von bewährten Methoden und Techniken aus der Standardi-sierung und die Verbreitung über professio-nellen Open-Source-Gemeinschaften.

Unser Dank geht an die Kollegen bei ETSI, der Eclipse Foundation sowie unseren Pro-jektpartnern, insbesondere Alexander Kaiser von Relayr und György Réthy von Ericsson, und an unsere Kollegen von Fraunhofer FO-KUS Dorian Knobloch und Sascha Hackel, die uns insbesondere bei der Implementierung und Testausführung unterstützen.

Referenzen

› [Böh16] T. Böhm et al., Challenges and Trade-offs in Performance Testing, Hustef 2016, siehe: https://www.hustef.hu/hustef_2016/www.hustef.hu/hustef/web.nsf/0/9C4A6E727B5B60E6C1258003004035D2/%24FILE/HUSTEF-2016_Challenges-And-Tradeoffs-In-Performance-Testing.pdf

› [CPIoT] ASQF Certified Professional for IoT (CPIoT), siehe: https://www.asqf.de/asqf/zertifizierungen/asqf-certified-professional-for-iot-cpiot/

› [Eclipse] Eclipse Foundation, siehe: http://www.eclipse.org/

› [EcTitan] Eclipse Titan, siehe: https://projects.eclipse.org/projects/tools.titan

› [EcTP] Projekt Eclipse Technology, https://projects.eclipse.org/projects/technology

› [FOKUS] Fuzzino, Fraunhofer FOKUS, siehe: https://www.fokus.fraunhofer.de/de/sqc/security_testing

› [Gra14] J. Grabowski et al., History, status, and recent trends of the testing and test control notation version 3 (TTCN-3), in: Int. J. on Software Tools for Technology Transfer, vol. 16, no. 3, pp. 215–225, Jun. 2014

› [HLA] AIOTI HLA, High Level Architecture für das Internet der Dinge der Alliance for the Internet of Things Innovation, Release 2.1, 2016, siehe: https://aioti-space.org/wp-content/uploads/2017/03/AIOTI-WG3-IoT-High-Level-Architecture-Release_2_1.pdf

› [IoT-T] Bundesministerium für Wirtschaft und Energie (BMWI), Projekt IoT-T, siehe: http://www.iot-t.de/

› [Kai17] A. Kaiser et al., Eclipse IoT-Testware: Die Open-Source-Testsuite für das MQTT-Protokoll, in: OBJEKTspektrum, Online Themenspecial Testing, September 2017, siehe: http://www.sigs.de/public/ots/2017/OTS_Testing_2017/Kaiser_OTS_Testing_2017.pdf

› [MQTT] Message Queuing Telemetry Transport, siehe: http://mqtt.org/

› [Sch17] I. Schieferdecker et al., IoT-Testware – An Eclipse Project, in: 2017 IEEE Int. Conf. on Software Quality, Reliability and Security (QRS), 2017

› [TDL] ETS TDL, siehe: https://tdl.etsi.org/

› [ToR] Terms of Ref. for ETSI TC MTS TST WG (Testing), siehe: https://portal.etsi.org/TBSiteMap/MTS/MTSTSTToR.aspx

› [TTCN3] ETSI Testing and Test Control Notation, Version 3 (TTCN-3), http://www.ttcn-3.org/

Dipl.-Inform. Michael Wagnermichael.wagner@fokus.fraunhofer.de leitet das Projekt IoT-T, das vom Bundesministerium für Wirtschaft und Energie gefördert wird. Er ist wissenschaftlicher Mitarbeiter am Fraunhofer FOKUS in Berlin.

Prof. Dr.-Ing. Ina Schieferdeckerina.schieferdecker@fokus.fraunhofer.deist Diplom-Mathematikerin und leitet das Fraunhofer FOKUS. Sie war unter anderem maßgeblich an der Entwicklung von TTCN-3 beteiligt und hat das IoT-Testware-Projekt bei Eclipse initiiert.

Axel Rennochaxel.rennoch@fokus.fraunhofer.de ist wissenschaftlicher Mitarbeiter am Fraunhofer FOKUS in Berlin. Als Mitglied des System Quality Centers ist er an Validierungs- und Testprojekten künftiger Kommunikationsnetzwerke und Softwaretechnologien beteiligt.

Besuchen Sie uns unterwww.sogeti.de/2018

ISTQB® CTFL ■ ISTQB® CTFL Agile Tester

ISTQB® CTAL Testmanager ■ ISTQB® CTAL Test Automation Engineer

iSQI’s CAT ■ iSQI’s® CABA ■ iSQI’s® CAE

CMAP Mobile App Testing – Foundation Level ■ Performance Testing ■ Test Automation

TMap NEXT® Test Engineer ■ Test Manager ■ Praxisworkshop

TPI NEXT® Foundation ■ TPI NEXT® für Testmanager

Individuelle Schulungen:u.a. Security ■ Testautomatisierung ■ Agilität

Demnächst ebenfalls akkreditiert:ISTQB® CTAL Security Tester ■ GTB CTFL Test Data Specialist

SECURITY SCHULUNG?ABER SICHER. MIT SOGETI.

Foto

: © ra

ven,

foto

lia.c

om

Anzeige-TESTING-Security2018.indd 1 03.05.18 18:22

9

DIE TESTWARE FÜR DAS INTERNET DER DINGE

Besuchen Sie uns unterwww.sogeti.de/2018

ISTQB® CTFL ■ ISTQB® CTFL Agile Tester

ISTQB® CTAL Testmanager ■ ISTQB® CTAL Test Automation Engineer

iSQI’s CAT ■ iSQI’s® CABA ■ iSQI’s® CAE

CMAP Mobile App Testing – Foundation Level ■ Performance Testing ■ Test Automation

TMap NEXT® Test Engineer ■ Test Manager ■ Praxisworkshop

TPI NEXT® Foundation ■ TPI NEXT® für Testmanager

Individuelle Schulungen:u.a. Security ■ Testautomatisierung ■ Agilität

Demnächst ebenfalls akkreditiert:ISTQB® CTAL Security Tester ■ GTB CTFL Test Data Specialist

SECURITY SCHULUNG?ABER SICHER. MIT SOGETI.

Foto

: © ra

ven,

foto

lia.c

om

Anzeige-TESTING-Security2018.indd 1 03.05.18 18:22

10

VORBERICHT GERMAN TESTING DAY 2018

Bereits zum 7. Mal wird am 7. und 8. Juni 2018 in Frankfurt am Main der German Testing Day (GTD) veranstaltet. Der Schwer-punkt der firmenunabhängigen Konferenz liegt im Austausch von Erfahrungen im Bereich der Software-Qualitätssicherung. Der German Testing Day richtet sich dabei an alle Personen, die in die Qualitätssicherung von Business-IT-Systemen sowie eingebetteten Systemen involviert sind. Der GTD bietet damit eine exzellente Plattform für alle Personen im IT-Bereich.

»Die ganze Breite Der Software-QualitätSSicherung«

Es geht am Donnerstagabend (7. Juni) mit der German Testing Night Casino los. Es gibt die Möglichkeit, zwischen drei Sessions zu wählen:

› Interactive Session 1: Was wir von ent­wicklungspolitischen Projekten in Mada­gaskar, Kenia und Tansania für das Test­ management lernen können.

› Interactive Session 2: Schwarmintelligenz im Testing – Kollaborative Testmethoden in der Praxis.

› Pecha­Kucha­Night: What really matters.

Der anschließende Stehempfang sowie die Casino­Spiele (ohne Geld) runden den Abend ab und die Teilnehmer werden – wie in den Jahren zuvor – sehr unterhaltsame Stunden verbringen.

Für den Konferenztag haben wir einen zu­sätzlichen Track eingerichtet, um eine noch größere Themenvielfalt anzubieten. Insge­samt bietet der GTD nun zwei Keynotes, 24 Sessions in fünf parallelen Tracks sowie Lightning­Talks zum Thema „Testing goes Agile“. Mit den Konferenzsprachen Deutsch und Englisch wollen wir den länderübergrei­fenden Austausch weiter fördern.

Alexandra Schladebeck wird in der Eröff­nungs­Keynote „Dear Future Me …” Briefe an sich und andere Tester präsentieren, die die Themen Testen, Leidenschaft, persön­

liches Wachstum, Karriere und Community adressieren. Alexandra ist eine feste Größe in der Test­Community und wird uns mithilfe ihrer langjährigen Erfahrung aufzeigen, wie wir – auch in schwierigen Projektsituationen – unsere Leidenschaft und Motivation behal­ten können.

Welche Vorträge sollte man nicht verpassen? Das ist beim GTD nicht so leicht zu sagen, da die Konferenz sich als eine „Konferenz der Breite“ versteht. Der GTD liefert mit seiner Vielfalt an Vorträgen einerseits einen sehr guten Überblick über aktuelle Testthemen und ­trends und andererseits die Möglich­keit, einen tieferen Einblick in verschiedenste Testgebiete zu erhalten. Dabei hält der GTD für IT­Leiter und Testmanager ebenso span­nende Vorträge bereit wie für technisch ver­sierte Tester. Mitarbeiter in klassisch entwi­ckelnden Unternehmen kommen ebenso auf ihre Kosten wie agile Tester. Und natürlich sind auch wieder zahlreiche Erfahrungsbe­richte dabei, in denen sich konkret aus den Best Practices und den erlebten Stolperfal­len anderer Unternehmen gut lernen lässt.

Wir haben ein paar Highlights für zwei Teil­nehmerprofile zusammengestellt. Selbstver­ständlich ist auch eine andere Auswahl oder eine abweichende, individuelle Zusammen­stellung sinnvoll.

Tester in der agilen Transformation oder auch in agilen Großunternehmen:

› „Wir können alles außer agil? – Wie ein Tanker seine Schnellboote zu Wasser lässt“: In diesem Vortrag geht Markus Schell auf die Erfahrungen und Schmer­zen auf dem Weg vom Wasserfall zum agilen Projekt mit mehreren Teams bei der Daimler AG ein. Agilität in einem Großkon­zern einzuführen, ist eine ganz besondere Herausforderung. Jahrelang etablierte

Strukturen in Bezug auf Organisation, Vor­gehensweisen und Infrastruktur wurden in diesem Beispiel hinterfragt, um der Kon­kurrenz durch aufstrebende, schlanke Un­ternehmen gewachsen zu sein. Durch die Schilderung der erzielten Erfolge und der aus den Misserfolgen gezogenen Lehren können sicherlich viele Unternehmen ihren Weg in die Agilität optimieren.

› „How do you measure success rate of lar­ge scale agile process?“: Agilität in einem Großunternehmen wird auch in diesem Vortrag adressiert. Bhageerathi Bai schil­dert, wie bei Intel durch ein Common­Qua­lity­Framework die teilweise verschiede­nen Qualitätsvorstellungen verschiedener agiler Teams harmonisiert wurden. Dabei hat sich das Qualitätsniveau insgesamt erhöht und die Orientierung am Bedarf und an den Erwartungen der Kunden stieg. Ein weiterer spannender Aspekt ist die Be­rücksichtigung von Software­, Hardware­ und Systemteams.

› „Qualitätssicherung im Kontext von gro­ßen Agilen Softwareentwicklungspro­jekten – Was ändert sich? Welche Pro­bleme galt es zu lösen?“: Nico Liedl und Thomas Karl schildern, wie sich in einem Java­Entwicklungsprojekt mit 16 Scrum­Teams die Agile Transformation und die damit verbundenen Fallstricke und Erfah­rungen aus der Sicht von Testern dar­stellen. Dabei gehen sie neben „harten“ Faktoren wie Testautomatisierung auch auf „weiche“ Faktoren wie Skillprofile ein. Sie zeigen Techniken auf, die sich in ihrem Kontext bei der Meisterung der Heraus­forderung einer agilen Transformation bewährt haben.

› „Let´s play – the Lego way of agile testing“: In diesem Vortrag schildert Ulf Richter die Herangehensweise von BMW an Agilität.

THOMAS RINKE UND MELANIE WOHNERT

11

VORBERICHT GERMAN TESTING DAY 2018

Er gewährt einen Einblick in die firmenin­ternen Trainings, bei denen in einem inter­disziplinären Team ein Premium­Produkt gebaut (und getestet) wurde. Zugegeben erfolgte die Qualitätssicherung pragma­tischer als in klassischen Projekten, aber ebenso wirkungsvoll. Und wirkungsvoll sind auch die Trainings gewesen, in denen die Teilnehmer spielerisch die neuen Inhal­te vermittelt bekamen.

Technisch orientierte Tester mit Interesse an Last­ und Performanztests:

› „Customer journey through a single page – Wie messe ich die Performance einer SPA?“: Single­Page Applications (SPAs) stellen Performanztester vor neue Her­ausforderungen. Diese clientbasierten Anwendungen, seien sie entwickelt in An­gular, React oder Vue, offenbaren teilwei­se sehr unerwartete Performance­Pitfalls. Nils Kuhn und Stefan Burnicki stellen eini­ge dieser Fallen vor und zeigen, wie zum Beispiel mit auf visuelle Vollständigkeit ausgelegten Metriken der Performanztest realistisch erfolgen kann.

› „Seven proven methods to ruin your Test Automation – A tongue­in­cheek talk on how to avoid capital blunders in test auto­mation“: Aus Fehlern lernt man. Gut, dass man sie nicht alle selbst machen muss. Seretta Gamba stellt sieben grobe Fehler vor, die bereits viele Automatisierungspro­jekte haben scheitern lassen. Somit bietet sie hilfreiche Unterstützung, diese Fehler und somit eine Gefahr für das Automati­sierungsprojekt frühzeitig zu erkennen, da­mit Gegenmaßnahmen ergriffen werden können.

› „Synergien aus Testautomatisierung und Lasttest“: Hier werden die Welten von Testautomatisierung und Performanz­test zusammengebracht – und das ist in der Erfahrung von Dirk O. Schweier auch tatsächlich eine gute Idee, um Synergien

zu nutzen. Er hinterfragte die oft übliche Trennung von Testautomatisierern und Performanztestern und skizziert ein Kon­zept, in dem beide Testarten gemeinsam genutzt werden. Die gemeinsame Her­angehensweise hat das Lösen mancher Aufgabenstellungen sogar teilweise erst möglich gemacht.

Dann möchten wir noch explizit auf die in­teraktive Session hinweisen, welche dieses Jahr erstmalig auch am Konferenztag ange­boten wird:

› „Eye­Tracking Tests – Jetzt und sofort?“: Nicole Charlier und Sarah Ganter geben in dieser Session Einblicke in den Ablauf sowie die Dos und Don‘ts eines Eye­Tracking­Tests. Sie zeigen auf, welche Erkenntnisse aus solchem Test in Bezug auf Optimierungspotenziale von Anwen­dungen gewonnen werden können, die beispielsweise durch Befragungen von Testpersonen kaum zu ermitteln sind. In dieser Session können Sie selbst ein Teil des Tests werden.

Damit sind wir auf einige der Vorträge des GTD näher eingegangen. Dies soll nicht den Eindruck erwecken, dass die nicht genannten Vorträge weniger interessant sind. Weitere Vortragsthemen sind:

› „Microservices erfolgreich testen mit Consumer Driven Contract Testing und Spring Cloud Contract“

› „Immer kürzere Testphasen? Mit Ticket Coverage verhindern, dass wichtige Fea­tures ungetestet bleiben“

› „From Monolith Testing to Micro Service Quality Assurance – a field report from REWE digital“

› „Use­Case­Tests und Endanwenderdoku­mentation – einmal beschreiben – zwei­mal gewinnen!“

› „Was geht uns Soziale Verantwortung an? Viel mehr als wir denken!“

› „Digitales Powerplay durch kontrolliertes Passspiel im Softwaretest“

› Testing languages, generators and run­times for a safety­critical system“

› „ATDD richtig – aus Fehlern lernen“

› „Umgang mit Testdaten in Zeiten von EU­Datenschutzgrundverordnung und Bun­ desdatenschutzgesetz“

› „Emulators go home – Automated testing on real mobile devices“

› „Testautomatisierung ohne Assertions“

Die Abschluss­Keynote wird von Marie Moe gehalten, die ein ganz besonderes Interes­se an Softwaresicherheit hat. In „My heart runs on vulnerable software“ erzählt sie ihre ganz persönliche Erfahrung, wie es ist, von einem Herzschrittmacher abhängig zu sein, der mit einer verwundbaren Software aus­gestattet ist. Sie beschreibt, wie sich unsere Fähigkeit, Technologie sicher zu gestalten, langsamer entwickelt als unsere Abhängig­keit von dieser Technologie und warum sie sich entschlossen hat, ein Hacking­Projekt zu starten, um die Sicherheit ihres Herzschritt­machers zu erforschen.

Das vollständige, aktuelle Programm und alle weiteren Informationen auch zu den Sponsoren und Ausstellern finden Sie unter http://www.germantestingday.info

Wir sind voller Vorfreude auf einen span­nenden Tag (und Vorabend) mit vielen neuen Ideen, tollen Diskussionen und einer Menge Anregungen zur Umsetzung in unseren Pro­jekten nach dem GTD 2018.

Melanie Wohnertmelanie.wohnert@think-y.deist Diplom-Mathematikerin und seit mehr als 15 Jah-ren in der IT-Branche tätig, davon 13 Jahre (auch) als Testerin beziehungsweise Testmanagerin und mehr als 10 Jahre in leitenden Positionen. Als Testmanagerin, Projektmanagerin und Führungskraft begleitete und verantwortete sie auch große agile Projekte mit bis zu 140 Mitarbeitern, on- und offshore. Seit einigen Jahren ist sie als freiberufliche Trainerin und Coach tätig. Melanie Wohnert begleitet den GTD seit seiner Entstehung und ist Conference-Chair des GTD 2018.

Thomas Rinkethomas.rinke@ista.comist seit mehr als 12 Jahren im Testumfeld tätig, zu-nächst als wissenschaftlicher Mitarbeiter im Themen-gebiet „risikobasierter Test“, dann als Tester, Presales und Professional Service Consultant sowie Trainer bei einem Beratungshaus für Softwarequalität. Seit 2011 ist er bei ista, zunächst als Teamleiter Softwaretest und nun als Expert Test Engineer angestellt. Er ist seit 2015 Mitglied des GTD Conference-Boards und Conference-Chair des GTD 2018.

12

TESTAUTOMATISIERUNG! JA!

Digitalisierung – DevOps – Agil! Nicht nur Schlagwörter, sondern real stattfindende Veränderungen, die kreativen Geschäftsideen grenzenlos freien Lauf geben und die Komplexität der IT-Systeme exponentiell ansteigen lassen. Ohne Testautomatisierung ist die laufende Sicherstellung einer angemessenen Qualität nicht möglich. Aber für die Schlüsselqualifikation „Test automatisierer“ gibt es viel zu wenig Spezialisten am Markt. Dieser Artikel widmet sich dieser Problematik und möglicher Gegenmaßnahmen.

»TesTauTomaTisierung, Ja! Doch wer machT’s?«

Wir leben in einer agilen Welt. Alles wird schneller! Auch, oder vor allem, in der IT. Der Weg und die Zeit zwischen Anforderungen aus den Fachbereichen, aus dem Markt oder seitens unterschiedlicher Regulative und deren Umsetzung durch die IT-Abteilungen werden kontinuierlich kürzer. Gleichzeitig nimmt die Komplexität von Anwendungen und Systemlandschaften dramatisch zu. Die hochgradige Vernetzung der Systeme und eine immer größere Zahl an Endgeräten so-wie der Anspruch, stets „real-time“ beliebig viel an Informationen zu liefern, steigern den Druck, schnell und in hoher Qualität neue An-wendungen auf den Markt zu bringen.

Continuous Testing

Um diesen Anforderungen gerecht zu wer-den, haben sich in den letzten Jahren in SW-Entwicklungsprojekten agile Konzepte, Methoden und Werkzeug wie Scrum, Uni-fied Process, Kanban usw. immer mehr durchgesetzt. Das Schlagwort „DevOps“ ist in aller Munde und verspricht blitzschnelle Durchlaufzeiten [Swi18]. Und was den Test betrifft, so bleibt diesem auch in dieser Wortkonstruktion scheinbar nur der Platz zwischen „v“ und „O“. Manchmal liest man auch „DevTestOps“, aber das holpert, dauert zu lange und Test ist sowieso Teil der Ent-wicklung – das kommt einem doch bekannt vor, oder?

Durch ein agiles Vorgehen wird vor allem die Zeit zwischen Anforderungen und Entwick-lung deutlich verkürzt, die Qualitätssiche-rung stellt – auch wenn sie wichtiger Teil des agilen Vorgehens ist – nach wie vor einen gewissen „Engpass“ dar. Testen ist sowohl innerhalb des Sprints in den agilen Teams als auch nachgelagert, wie im Abnahmetest, durchzuführen. Und das immer wieder – Con-tinuous Testing als Teil dieser „Continuous Everything”-Ansätze.

Doch wie ist dieser Spagat zwischen schnel-ler Umsetzung und Erfüllung hoher Qualitäts-erwartung überhaupt zu schaffen? Testen erfordert eine gewisse Zeit – selbst im agi-len Umfeld lassen sich Testaufwände nicht vollständig zur Entwicklung parallelisieren. Ein uneingeschränktes Aufstocken von Test-experten ist nicht nur aus budgetären Grün-den wenig sinnvoll, sondern verursacht auch unnötige Koordinationsaufwände.

Und hier kommt nun „Testautomatisierung“ ins Spiel. Durch das Minimieren von manu-ellen Testaufwänden und das Schaffen ei-nes hohen Automatisierungsgrades soll für schnelle Testdurchlaufzeiten, eine hohe Tes-tabdeckung und gleichzeitig minimale perso-nelle Aufwände gesorgt werden. Doch was gibt es dabei zu beachten [Bau17]?

Die Automatisierungslösung ist nicht immer rasch erhältlich

Viele Jahre lang war Testen eine größten-teils manuelle Tätigkeit. Im klassischen V- oder Wasserfallmodell war im Idealfall der Testexperte bereits in der Anforderungs-erstellung eingebunden, der Testmanager konnte sich frühzeitig mit der Erstellung ei-nes Testkonzeptes und einer Teststrategie beschäftigen, in dem Testobjekte, Kritikali-tät, Priorität, Testabdeckungsgrad, Testen-dekriterien usw. definiert wurden. Darauf aufbauend wurden in der Testvorbereitung in passenden Tools Testszenarien und Test-fälle beschrieben und in der Testdurchfüh-rungsphase die Testfälle manuell durchge-führt und deren Ergebnisse beziehungsweise abweichende Fehler ebenfalls manuell doku-mentiert.

Dies erfordert hohes fachliches und metho-disches Know-how, weniger jedoch Pro-grammierkenntnisse oder tiefer gehende IT-Kenntnisse.

Testautomatisierung ist heutzutage weni-ger das „Bedienen“ eines Testautomatisie-rungswerkzeuges, wie es in den Anfängen der Automatisierung vor allem bei Capture-Replay-Tools der Fall war, sondern vielmehr das Verstehen und Analysieren von System-landschaften, das Konzeptionieren und Ent-wickeln von Automatisierungsframeworks, das Skripten von automatisiert durchlaufen-den Testfällen und das Erstellen von Ergeb-nisberichten. Diese Tätigkeiten werden von einer Vielzahl an Werkzeugen unterstützt. Dennoch braucht es zur Implementierung einer nachhaltigen Automatisierungslösung Spezialisten, die neben einer fundierten IT-Ausbildung gute Programmier- und Archi-tekturkenntnisse sowie ein fachliches Ver-ständnis und einen Sinn für Testmethoden und Qualitätsmerkmale besitzen. [Sne12]

Doch hier wird’s dann schwierig: Wer insbe-sondere die programmiertechnischen Skills mitbringt, will meistens eines nicht: Testen. Technikaffine Informatiker wollen lieber pro-grammieren, Systeme designen, vielleicht Scrum Master, Software- oder Enterprise-Ar-chitekten sein. Auf jeden Fall wollen sie et-was schaffen, das man „nutzen, bedienen, anwenden kann“, etwas, das – wie man so schön sagt – „das Licht der Welt erblickt“ ... Welches Automatisierungsframework hat jemals Beachtung gefunden (auch wenn viel Programmierarbeit darin steckt), welche Testskripts sind in Dankesreden erwähnt oder auch nur in irgendeinem Store „bewertet“ worden? Die Lorbeeren erhält immer das „zu testende Ding“, nicht das „Ding, das testet“.

Da sowohl am Arbeitsmarkt als auch in den IT-Unternehmen kaum bis wenig Mitarbeiter verfügbar sind, die „Testautomatisierungsex-perte“ oder „Testautomatisierungsarchitekt“ als Berufsbild vor Augen haben, hinkt die Um-setzung von Testautomatisierungsvorhaben oft den Wunschvorstellungen hinten nach.

MANFRED BAUMGARTNER UND ALEXANDRA SUMPER

How Smart is Your QA?

With Eggplant Intelligent Automation, you can do just that.

Our revolutionary product suite and approach to testing helps you:

- Test through the eyes of the user.

- Test all aspects of the UX.

- Expand automation beyond test execution with artificial intelligence, machine learning, and analytics.

- Use predictive analytics to report quality status in terms of the UX.

- Take a coherent approach to monitoring and testing.

Experience Intelligent Automation yourself. Request a demo via sales@eggplant.io

These days, you can't simply test that the code works. You have to ensure that your digital experience is delighting users to drive business success.

13

TESTAUTOMATISIERUNG! WER?

Viele fürchten sich vor der Rolle „Testautomatisierer“

Stellen Sie sich eine Gruppe von zehn Ent-wicklern vor, die gefragt werden, ob jemand für die nächsten sechs Monate ein Testau-tomatisierungsprojekt übernehmen möch-te? Sie können sicher sein, dass Sie in zehn angstgeweitete Gesichter blicken werden. Freiwillige Meldungen sind nahezu aus-geschlossen. Ähnliches Verhalten werden Sie vermutlich bei manuellen Testexperten vorfinden – jedoch aus entgegengesetzten Gründen. Entwickler befürchten, unterfor-dert und gelangweilt zu sein, weil die Auf-gabe zu trivial ist, beim Tester ist es genau das Gegenteil.

Testautomatisierung ist eine langfristige Investition

Die Entscheidung, in Entwicklungsprojekten verstärkt auf Testautomatisierung zu setzen, beruht oft auf der Annahme, dass mit dem Einsatz eines Testautomatisierungswerkzeu-

ges sofort massive Ressourceneinsparungen und die Verkürzung der Testzeiten zu erwar-ten sind. Dies ist jedoch selten der Fall. Fakt ist, dass der Einsatz einer Automatisierungs-lösung immer eine langfristige Investition ist, die über den gesamten Lebenszyklus der An-wendung Entwicklungs- und Wartungsauf-wände verursacht. Diese sind aber deutlich geringer als entsprechende manuelle Auf-wände. Vor allem ermöglicht Testautomati-sierung die Durchführung tausender Regressi-onstestfälle in kurzer Zeit, was manuell nicht machbar ist, schon gar nicht im engen Zeit-fenster agiler Projekte im DevOps-Modus.

Testautomatisierung erfordert einiges Geschick und Know-how

Wer als Testautomatisierer tätig ist, benö-tigt sehr gute technische Skills, ein positives Verhältnis zum Softwaretest und die Bereit-schaft, auch „im Hintergrund“ zu arbeiten. Ein Testautomatisierer muss sich vor allem sehr gut in die agilen Entwicklungsteams in-tegrieren. Er muss in der Lage sein, innerhalb

der Sprints bereits erste lauffähige Testfälle zu erstellen, die über den Sprintzyklus hinaus – zum Beispiel in einer späteren Systemin-tegrations- oder Abnahmephase – lauffähig oder zumindest als Basis für automatisierte End-to-End-Tests einsetzbar sind.

Die organisatorischen Auswirkungen sind umfangreicher als vermutet

Die Einführung von Testautomatisierung um-fasst nicht nur den Kauf und die Implementie-rung eines Werkzeugs, sondern bedeutet eine Veränderung der Test- beziehungsweise Ent-wicklungs- und in manchen Fällen auch der Betriebsorganisation. Neben der Erweiterung der Teams um Mitarbeiter mit Testautomati-sierung-Skills muss auch entschieden wer-den, wo diese Mitarbeiter in der Organisation, aber auch im Entwicklungsprozess eingesetzt werden. Automatisierung soll innerhalb von Sprintteams angesiedelt sein, darüber hinaus aber auch im Systemintegrationstest, teilwei-se sogar im Abnahmetest, etwa für die auto-matisierte Erstellung von Testdaten.

How Smart is Your QA?

With Eggplant Intelligent Automation, you can do just that.

Our revolutionary product suite and approach to testing helps you:

- Test through the eyes of the user.

- Test all aspects of the UX.

- Expand automation beyond test execution with artificial intelligence, machine learning, and analytics.

- Use predictive analytics to report quality status in terms of the UX.

- Take a coherent approach to monitoring and testing.

Experience Intelligent Automation yourself. Request a demo via sales@eggplant.io

These days, you can't simply test that the code works. You have to ensure that your digital experience is delighting users to drive business success.

14

TESTAUTOMATISIERUNG! JA!

Wichtig ist auch eine effektive Auswahl und Erstellung von automatisierten Regressions-testfällen, die im Sinne von DevOps – vor allem beim schnellen Ausrollen von Changes, Erweiterungen usw. in die Produktion – die „Fehlerfreiheit“ durch kontinuierliche, auto-matisierte Testdurchläufe sicherstellen soll.

All dies bedeutet Veränderungen in Abläu-fen, Prozessen und der Organisation.

Testautomatisierung ist nicht gratis

Auch wenn Testautomatisierung mit der Überlegung, Geld und Zeit zu sparen, einge-führt wird, darf man nicht übersehen, dass selbst eine sehr gute, wartungsarme Auto-matisierungslösung regelmäßige Aufwän-de verursacht. Aufwände entstehen etwa, wenn Erweiterungen in der Anwendung umgesetzt werden oder bei Änderungen im Betrieb, wie Updates oder Upgrades auf neu-ere Betriebssystemversionen. Dies bedeutet in den meisten Fällen, dass das Regressions-testportfolio erweitert beziehungsweise ad-aptiert werden muss.

Im Idealfall rechnen sich diese Aufwände langfristig. Dieser stellt sich aber nicht au-tomatisch ein. Je umfangreicher das Set an automatisierten Testfällen geworden ist, desto größer ist das Risiko überhöhter War-tungsaufwände bei gewissen Ereignissen im Produktlebenszyklus, wie eines Technolo-giewechsels, eines Werkzeugwechsels oder bestimmten sonstigen technischen und fach-lichen Änderungen (siehe Abbildung 1).

Jede gute Automatisierungslösung braucht einen passenden Rahmen. Das heißt, es

muss die passende (Test-)Organisation ge-funden und gestaltet werden. Testautoma-tisierung alleine löst nicht alle Probleme. Es muss das gesamte Testvorgehen betrachtet und die Automatisierung in dieses Vorgehen eingebettet sein. [Cri09]

Trotz aller Schwierigkeiten ist Testautoma-tisierung in allen Branchen und Produktent-wicklungen immer mehr im Kommen und in der Zukunft unabdingbar. Neben der ei-gentlichen Automatisierungsaufgabe – per Knopfdruck lauffähige Testfälle zu erstellen und das Ergebnis der Testdurchläufe auto-matisiert in lesbaren Report darzustellen – werden künftig auch das automatisierte „Hochziehen“ von unterschiedlichen Ent-wicklungs- und Test-Stages bis hin zur Pro-duktion, die automatisierte Generierung von Testdaten und auch das automatisierte Er-stellen von virtualisierten Schnittstellen mit-tels Service-Virtualisierung ([Lin13], S. 76-78) immer mehr in das Aufgabengebiet von Test-automatisierungsexperten und -architekten rücken. All diese Tätigkeiten unterstützen „Continuous Testing“ im Zuge von DevOps.

Der Mangel an Testautomatisierern

Um alle oben angeführten Herausforderun-gen zu meistern, braucht es eine höhere Zahl an hoch qualifizierten Mitarbeitern, die diese Tätigkeiten gerne übernehmen wollen und da-rin auch eine Karrierechance sehen. Aktuell gibt es das Berufsbild des Automatisierungs-experten [Buc15] mit dem Karriereschritt zum Testautomatisierungsarchitekten, der

› für komplexe Teststellungen maßgeschnei-derte, effiziente, gut wartbare Automati-

sierungslösungen konzeptioniert, entwi-ckelt und implementiert,

› für Testautomatisierungsprojekte sowohl inhaltlich als auch budgetär verantwort-lich ist und

› ganze Automatisierungsteams führt,

noch so gut wie nicht am Berufsmarkt.

Was ist also zu tun, um junge Informatiker für das Berufsbild „Testautomatisierungs-experte“ zu begeistern, und welche bereits im Beruf aktive Mitarbeiter kann man für die Testautomatisierung sinnvoll ausbilden und einsetzen?

Zuerst müssen ein klares Berufsbild und ent-sprechende Karrierepfade dargestellt und ver-mittelt werden. Kaum jemandem ist klar, dass ein Testautomatisierungsexperte im Großen und Ganzen ähnliche Entwicklungsleistungen erbringen muss wie ein Programmierer. Es gilt Frameworks zu entwickeln und zu implemen-tieren, gut wartbare Automatisierungsskripts nach gängigen Coding-Guidelines zu erstellen und eine lauffähige Lösung zu schaffen. Mit dem Unterschied, dass das in der Automati-sierung erstellte SW-Produkt der Qualitätssi-cherung der „eigentlichen“ Applikation dient. Genau genommen sollten jedoch neben der Produktdokumentation sowohl die dokumen-tierten Testfälle als auch das Set an automa-tisierten Testfällen als Bestandteil der Soft-ware betrachtet und geachtet werden.

Ein Automatisierungsarchitekt ist genauso verantwortlich für die Qualität der Archi-tektur seiner Automatisierungslösung wie jeder andere SW-Architekt auch. Darüber hinaus führt und steuert er ganze Automati-sierungsteams, verantwortet – ähnlich wie ein Projektleiter oder Scrum Master – den Fortschritt, das Controlling und Budgets sei-nes Vorhabens – eine tolle Aufgabe; bisher offenbar nur wenig transparent und daher wenig attraktiv.

Hier gilt es, an den Universitäten, techni-schen Schulen und Fachhochschulen ein Be-wusstsein zu schaffen, dass Automatisierung ein hochattraktives und spannendes Feld im SW-Engineering ist. Dieses bietet jedem Absolventen glänzende Berufsaussichten, gute Bezahlung und hohe Chancen am Ar-beitsmarkt. Neben diesen „Marketingmaß-nahmen“ müssen künftig auch die Lehrpläne mehr Inhalte aus dem Test- und Automatisie-

SOFTWARE-SEMINARE 2018 VON EXPERTEN LERNEN

SIGS DATACOM GmbHTel. +49(0)22 41 / 23 41-202E-Mail: julia.seliger@sigs-datacom.de

Tester

Entwickler

Architekten

Entscheider

Projektleiter

JETZT ANMELDEN!Mehr Informationen fi nden Sie unterwww.sigs-datacom.de/seminare

DEVOPS BOOTCAMPmit Michael Hüttermann

DEVOPS ENGINEERING PRACTICES & TOOLSmit Michael Palotas

SELENIUM BOOTCAMP mit Michael Palotas

TESTING@AGILE mit Melanie Wohnert & Florian Halmburger

Abb. 1: Verlauf des ROI in einem Advanced Automation Approach

14

TESTAUTOMATISIERUNG! JA!

15

TESTAUTOMATISIERUNG! WER?

SOFTWARE-SEMINARE 2018 VON EXPERTEN LERNEN

SIGS DATACOM GmbHTel. +49(0)22 41 / 23 41-202E-Mail: julia.seliger@sigs-datacom.de

Tester

Entwickler

Architekten

Entscheider

Projektleiter

JETZT ANMELDEN!Mehr Informationen fi nden Sie unterwww.sigs-datacom.de/seminare

DEVOPS BOOTCAMPmit Michael Hüttermann

DEVOPS ENGINEERING PRACTICES & TOOLSmit Michael Palotas

SELENIUM BOOTCAMP mit Michael Palotas

TESTING@AGILE mit Melanie Wohnert & Florian Halmburger

rungsbereich vermitteln, um die Absolventen rasch im Beruf einsetzen zu können. Bisher gibt es kaum Institute, die diese Inhalte ver-mitteln. Es wird also noch einige Jahre dau-ern, bis diese Maßnahmen wirksam werden.

Als sehr begrüßenswert sind in diesem Zu-sammenhang die Bemühungen des German Testing Boards zu sehen, welches ein Refe-renzschema zum Berufsbild „Tester“ [GTB17]

erarbeitet und veröffentlicht hat. Darin wer-den unter anderem Entwicklungsdimensio-nen, allgemeine Kompetenzen, Rollenbilder und Verantwortungsstufen dargestellt – so auch für das Rollenbild „Testautomatisie-rungs-Spezialist“.

Aus Mangel an verfügbaren Testautoma-tisierern hat das mittelständische öster-reichische Unternehmen ANECON (seit

2018 Nagarro) im Jahr 2015 einen dualen Testautomatisierungslehrgang (TA-Curricu-lum) entwickelt. Seit 2016 werden eigene Mitarbeiter in vier Semestern zu Testauto-matisierungs-Spezialisten und weiteren drei Semestern zu Automatisierungsarchitekten berufsbegleitend ausgebildet.

Dabei handelt es sich um einen modular auf-gebauten Lehrgang, der den Mitarbeitern

Referenzen › [Bau17] M. Baumgartner, M. Klonk, H. Pichler, R. Seidl, S. Tanczos, Agile Testing – Der agile Weg zur Qualität, Carl Hanser Verlag, 2. Auflage, 2017

› [Buc15] T. Bucsics, M. Baumgartner, R. Seidl, S. Gwihs, Basiswissen Testautomatisierung, dpunkt.verlag, 2. Auflage, 2015

› [Cri09] L. Crispin, J. Gregory, Agile Testing – A practical Guide for Testers and agile Teams, Addison-Wesley-Longman, 2009

› [GTB17] Berufsbild Tester, German Testing Board e. V., Erlangen, 2017

› [Lin13] T. Linz, Stubs, Mocks und Dummies, Testen in Scrum-Projekten, dpunkt.verlag, 2013

› [Sne12] H. Sneed, M. Baumgartner, R. Seidl, Der Systemtest, Hanser, 3. Auflage, 2012

› [Swi18] SwissQ Consulting AG, Software Product Development 2018 – Trends & Benchmarks Studie Schweiz, Zürich, 2018

› [Vos16] K. Vosseberg, A. Spillner, M. Winter, Softwaretest in der Praxis – Umfrage 2016, dpunkt.verlag, 2017

TESTAUTOMATISIERUNG! WER?

16

TESTAUTOMATISIERUNG! JA!

mit passenden Skills und Interesse offen-steht und innerhalb der Arbeitszeit besucht werden kann. Es werden Lehrinhalte zu den Themen Test, Basiswissen Testautomatisie-rung, Systemarchitekturen, Programmierung, Frameworks, Automatisierungswerkzeuge, DevOps, Testdatenmanagement usw. ver-mittelt.

Es gibt drei Ausbildungsniveaus für Testauto-matisierer (siehe Abbildung 2). Diese um-fassen:

› TA Senior Expert: Dieser setzt eigenständig Kundenprojekte der Testautomatisierung, Service-Virtualisierung und Performanz-test in unterschiedlichen Technologien um (vgl. GTB TA-Spezialist Junior/Advanced).

› TA Architect: Der Testautomatisierungs- Architekt konzipiert Automatisierungslö-sungen für Kunden und führt und steuert Automatisierungs- und Service-Virtuali-sierungs-Teams in Projekten (vgl. GTB TA-Spezialist Senior/Expert).

› TA Consultant: Er berät Kunden auf Ma-nagementebene in allen Automatisie-rungs-, Service-Virtualisierungs- und Per - formanzfragen (vgl. GTB TA-Spezialist Se-nior/Expert als Berater).

Die Einführung einer solchen Ausbildungs-variante kann ein geeigneter Weg für viele Unternehmen sein, den Mangel an verfüg-baren Testautomatisierungs-Spezialisten in den eigenen IT-Abteilungen auszugleichen.

Dies bedeutet natürlich auch eine Investiti-on, da es sich um keinen kurzfristigen Ansatz handelt und dieser das Risiko birgt, dass gut ausgebildete Mitarbeiter möglicherweise das Unternehmen verlassen. Aber das ist das kleinere Übel gegenüber schlecht ausgebil-deten Mitarbeitern, die bleiben und Automa-tisierungslösungen erarbeiten, die wirklich teuer zu stehen kommen.

Fazit

Testautomatisierung ist im Vormarsch und wird auch in den nächsten Jahren nicht auf-zuhalten sein. Im Gegenteil: DevOps, agiles Vorgehen und enorm kurze Time-to-Market bei gleichzeitig hoher Qualitätserwartung sowie komplexen Anwendungen und Sys-temlandschaften erfordern einen immer hö-heren Automatisierungsgrad. Dafür braucht es Spezialisten, die effiziente, wartungsarme Lösungen schaffen, die über den gesamten Lebenszyklus der Anwendung wirksam sind.

Diese Spezialisten sind rar und am freien Ar-beitsmarkt kaum zu finden. Auch IT-Dienst-leister können derzeit den Bedarf nicht vollständig bedienen. Um die steigende Nachfrage nach Automatisierungsexperten decken zu können, sind neben den Universi-täten und Fachhochschulen auch die Unter-nehmen selbst gefordert. [Vos16]

Es müssen attraktive Karrieremodelle für Testautomatisierer geschaffen werden und Unternehmen müssen selbst in die Ausbil-dung ihrer Mitarbeiter investieren. Mittel-fristig werden idealerweise Absolventen von Universitäten und Fachhochschulen das nötige Rüstzeug und die Motivation, als Testautomatisierer tätig zu sein, vermittelt bekommen. Eine Anleitung dazu könnte das in diesem Artikel dargestellte Modell und das Referenzschema „Berufsbild Tester“ des German Testing Boards geben.

Dipl.-Ing. Manfred Baumgartnermanfred.baumgartner@nagarro.comstudierte Informatik an der Technischen Univer-sität Wien und ist heute Vice President Quality Assurance bei der Nagarro GmbH (vormals ANECON). Seine Erfahrungen umfassen sowohl die klassische als auch agile Softwareentwick-lung. Manfred Baumgartner ist Autor der Bücher „Agile Testing“, „Basiswissen Testautomatisie-rung“ und „Der Systemtest“.

Mag. (FH) Alexandra Sumperalexandra.sumper@nagarro.comist Leiterin des Bereichs „Testautomatisierung“ bei der Nagarro GmbH (vormals ANECON). Sie verfügt über umfangreiche Erfahrung in vielen Projekten als Test- und Qualitätsmanagerin und hat den Automatisierungsbereich in wenigen Jahren von ursprünglich 6 auf mittlerweile über 40 Mitarbeiter ausgebaut.

Abb. 2: Grundstruktur des TA-Curriculums

17

TESTAUTOMATION VON MICROSERVICES

In Zeiten der Digitalisierung ist es für dynamische Unternehmen notwendig, technische Strukturen zu etablieren, die den immer schneller werdenden Marktanforderungen gerecht werden. Der digitale Darwinismus fordert Strukturen, die sowohl agil als auch schnell genug sind, diesen Anforderungen gerecht zu werden.

»TesTen von Microservices MiT consuMer-Driven conTracTs«

Charles Darwin hat in seinen Werken einen wichtigen Punkt erarbeitet: Es sind nicht die Stärksten, die überleben, und auch nicht die Intelligentesten. Es sind vielmehr jene, die sich am schnellsten den neuen Gegebenhei-ten anpassen können.

Microservices als Antwort auf den digitalen Darwinismus

Unternehmen wie Netflix, Amazon und Goo-gle haben schnell erkannt, die notwendigen technischen Strukturen anzupassen und zu implementieren. Geschafft wurde das durch den Einsatz von Microservices als neues Ar-chitekturprinzip. Weg vom Monolithen, hin zu kleinen, schlanken, unabhängigen Services, die über standardisierte APIs kommunizie-ren. Statt einer einzelnen monolithischen Anwendung, die die gesamte Geschäftslogik enthält, erledigt ein flexibles Netzwerk aus Microservices alle komplexen Vorgänge.

Der Trend in der Systemarchitektur geht weg vom Monolithen, hin zu Microservices, um durch kleine überschaubare Programmein-heiten Continuous Delivery zu ermöglichen und Features schneller dem Markt zur Verfü-gung stellen zu können.

Microservices ist ein Architekturmuster, bei dem die Anwendung in Services unterteilt wird und nicht in Schichten (siehe Abbil-dung 1). Die Microservices sind dabei ent-koppelt und laufen in einem eigenen Prozess, damit diese leichter austauschbar sind. Micro-services sind auch technologisch voneinander unabhängig, da sie durchaus mit verschiede-nen Programmiersprachen, Frameworks oder Da tenbanken realisiert werden können.

Microservices lassen sich unter anderem durch folgende Eigenschaften beschreiben:

› Die Anwendung wird in kleine Services unterteilt, die entkoppelt sind, und ver-

wendet diese als Komponenten. Diese Services sind IT-Repräsentationen von in sich abgeschlossenen fachlichen Funktio-nalitäten.

› Microservices enthalten alle Schichten (Datenbank, Middleware und Frontend) ei-ner Funktionalität. Anwendungen werden somit nicht in Schichten unterteilt, son-dern in Funktionalitäten.

› Microservices werden eigenständig und nicht als gesamte Anwendung deployed. Dadurch entsteht selbst bei der Implemen-tierung keine Abhängigkeit zu anderen Services.

› Die Kommunikation von Microservices erfolgt meist über HTTP-basierte Schnitt-stellen, wie beispielsweise RESTful-APIs.

Testautomation, ein Muss

Der Erfolgsfaktor, um die Qualität im Soft-wareentwicklungsprozess zu verbessern, be-steht darin, schnelle Rückmeldung über die Auswirkungen von Änderungen zu erhalten. Microservices sind auch darauf ausgelegt, schnell auf Änderungswünsche der Kunden reagieren zu können, um die Time-To-Market niedrig zu halten.

Der Vorteil von Microservices ist die Fähig-keit, Services einzeln zu entwickeln, bereit-zustellen und anzupassen, ohne das gesamte System zu stören. Diese Tatsachen stellen zusätzliche Anforderungen an das Testen. Hier nimmt Testautomation einen viel höhe-ren Stellenwert ein als in anderen Systemen. Angesichts der Tatsache, dass die Entwick-lung von Microservices verteilt und unabhän-gig ist, sind manuelle Teststrategien, die auf monolithische Architekturen angewendet werden, hier kaum anwendbar.

Microservices-Anwendungen müssen eine hohe Leistung und Funktionalität bieten, die erfordert, dass jede Schicht der Anwendung gründlich getestet wird. Hier ist wenig Platz für manuelle Tests. Testautomation ist hier ein Muss, manuelle Tests ein Kann. Es ist äußerst schwierig, die Auswirkungen einer Reihe von Änderungen auf so ein komplexes Softwaresystem durch manuelle Tests vor-herzusagen. Hier gilt es, viele verschiedene Arten von Tests zu automatisieren.

SunRiseSet – Microservice-Architektur

Am Beispiel einer Microservice-Architektur für eine mobile App wird erklärt, welche Arten von Tests sinnvoll sind. Die App Sun-

RUDOLF GRÖTZ

Abb. 1: Architekturmuster

18

TESTAUTOMATION VON MICROSERVICES

Username Password Name Active Expired Anmerkungrgroetz test123 Rudolf Grötz JA NEIN Zum Testen von gültigen Usersdkukacka test123 Dominik Kukacka NEIN NEIN Zum Testen von inaktiven Usersnnikolic test123 Nebojsa Nikolic JA JA Zum Testen von abgelaufenen Users

Tabelle 1: Testdaten

Abb. 3: Übersicht der Testarten

RiseSet hilft Anglern, ihren Anglerausflug zu planen. Es ist ein großer Vorteil für Angler zu wissen, wann die Sonne auf und wann die Sonne untergeht. Warum? Weil auf man-chen Gewässern das Nachtfischen verboten ist. Nun stellt sich die Frage, von wann bis wann ist es eigentlich Nacht? Die Antwort steht im Fischereigesetz: eine Stunde nach Sonnenuntergang bis eine Stunde vor Son-nenaufgang. Daher muss man wissen, wann die Sonne auf und untergeht.

Dann gibt es ja auch noch die Wetterfrage. Was zieht der Angler an? Überrascht mich

wieder das Wetter und ich muss den Angler-trip abbrechen?

All diese Fragen, beantwortet unsere mobile App SunRiseSet (siehe Abbildung 2). Sie liefert für einen eingegebenen Ort den Son-nenauf- und Untergangszeitpunkt, die Wet-terdaten und die Landkarte.

Das System besteht auf der Backend- Seite aus sechs Microservices (siehe Ab bildung 3). Der Location- und der Wea-ther-Service greifen auf externe APIs zu. Die Services haben folgende Funktiona litäten:

› API-Gateway – dient als Facade. Nur über dieses Gateway kann auf die dahinterlie-genden Services zugegriffen werden.

› AUTH – dient zu Authentifizierung des User und der Tokenverwaltung.

› MariaDB – dient zum Persistieren der Userdaten.

› Location – dient zur Ermittlung der Geo-location via externen Webservice.

› Weather – ermittelt die Wetterdaten für die Geolocation via externen Webservice.

› Sun – berechnet Sonnenauf- und Sonnen-untergang für die Geolocation.

Testaspekt

In unseren Tests betrachten wir die Lo-gin-Funktionalität des AUTH-Service. Um die Tests besser zu verstehen, ist es notwendig, die User-Daten (siehe Tabelle 1) zu kennen, die in der Datenbank vorhanden sind und den Tests zugrunde liegen.

Der Aufruf mit einem gültigen User liefert die JSON-Nachricht aus Abbildung 4 zurück.

Testen von Microservices

Eine Microservice-Architektur besteht aus unabhängig einsetzbaren Diensten, die es erschweren, nur altbekannte Testansätze in der Pipeline anzuwenden.

Durch das Zerteilen eines Systems in klei-ne, eigenständige Services werden zusätz-liche Schnittstellen sichtbar, die in einer monolithischen Architektur nicht vorhanden waren. Zusätzliche Schnittstellen, nicht nur in technischer, sondern auch in organisatori-scher Hinsicht, sind hilfreich, sind doch nun meistens mehrere Teams an der Entwicklung beteiligt.

Die Zusammenarbeit mehrerer Services, so-wohl aus Consumer- als auch Providersicht,

Abb. 2: Die App SunRiseSet

GEMEINSAM DURCHSTARTEN!

So geht Softwarequalität.

sogehtsoftwarequalitaet.de

Wir suchen Köpfe und Könner für unsere Projekte als

TESTMANAGERBewerbungen per Email anjobs@saxsys.de

(m/w)

19

TESTAUTOMATION VON MICROSERVICES

und die reibungslose Integration der Ser-vices untereinander sind daher ein wichtiger Aspekt. Diesem Umstand wird durch zusätz-liche Tests, besser bekannt unter dem Begriff „Consumer-Driven Contracts“, begegnet.

In der Welt der Softwaretests gibt es viele Bezeichnungen für die verschiedensten Ar-ten von Tests. Eine strikte Trennung nach Zielen und Methoden ist sehr schwer. Das ISTQB-Glossar [ISTQB] alleine unterschei-det fünf verschiedene Arten von Acceptan-ce-Tests. Diverse Testpyramiden verschie-denster Testspezialisten [Scot16, Ash14] tragen nicht dazu bei, hier Unklarheiten aus-zuräumen. Zum Test von Microservice-Um-gebungen sollten meiner Meinung nach fol-gende Tests Anwendung finden.

Komponententests

Unit- oder Komponententests sind immer noch anwendbare Testansätze, denn inner-halb seiner Grenzen ist jedes Service noch sehr zusammenhängend. Diese Tests durch-

laufen kleine Code-Abschnitte, also Klassen oder Methoden. Abhängige Komponenten werden dabei durch Mocks ersetzt, um den Service in einer isolierten Umgebung unab-hängig testen zu können.

Integrationstests

Durch die zusätzlichen Schnittstellen wer-den Integrationstests noch wichtiger für das Gesamtgefüge. Wurden bisher die Daten innerhalb eines Monolithen ausge-tauscht, kommt durch Microservices der Datenaustausch, in den meisten Fällen via HTTP, ins Spiel. Die Integrationstests sollen sicherstellen, dass dieses Zusammenspiel funktioniert.

Consumer-Driven Contracts

Mit Consumer-Driven Contracts (CDC) ist ein fast vergessener Testansatz wieder in den Mittelpunkt gerückt. Thoughtworks hat aufgrund des Microservice-Hypes Consumer-Driven Contracts wieder auf den Technology Radar [Thought] zurück-geholt:

… We’ve decided to bring consumer-dri-ven contract testing back from the archive for this edition even though we had allo-wed it to fade in the past. The concept isn’t new, but with the mainstream acceptance of microservices, we need to remind peo-ple that consumer-driven contracts are an

Abb. 4: Loginversuch mit gültigem User

GEMEINSAM DURCHSTARTEN!

So geht Softwarequalität.

sogehtsoftwarequalitaet.de

Wir suchen Köpfe und Könner für unsere Projekte als

TESTMANAGERBewerbungen per Email anjobs@saxsys.de

(m/w)

20

TESTAUTOMATION VON MICROSERVICES

essential part of a mature microservice testing portfolio, enabling independent service deploy ments …

Consumer-Driven Contracts betrachten Microservices aus der Perspektive der auf-rufenden Einheit. Der Contract beschreibt, wie die Antwort des Providers aufgebaut sein muss. Im Grunde genommen definiert der Consumer eines Service zusammen mit dessen Provider einen Kontrakt und prüft in einem Test, ob dieser eingehalten wird. Stellt der Provider nun eine neue Version des Ser-vice zur Verfügung, stellt er durch den Cont-ract-Test aller Consumer sicher, dass alle Ser-viceaufrufe der Consumer noch funktionieren.

End-to-End-Tests

End-to-End-Tests kommen zum Einsatz, um die volle Qualität des Systems zu gewährleis-

ten. Diese Tests prüfen, ob die Geschäfts-fälle, wie sie ein Anwender durchführt, das richtige Ergebnis liefern. Es wird dabei sichergestellt, dass Systemabhängigkeiten und Datenintegrität zwischen verschiedenen Systemkomponenten und Systemen beibe-halten werden.

Lasttests

Lasttests sind eine Unterkategorie von Per-formanztests und prüfen, ob die Leistung der Software unter ungünstigen und extremen Bedingungen zufriedenstellend ist. Diese Be-dingungen können als Folge von starkem Netz-werkverkehr, Prozessorauslastung oder Über-lastung einer bestimmten Ressource auftreten.

In diesem Artikel wird die Umsetzung von Consumer-Driven Contracts erklärt. Weitere Informationen sind in [Grö17] zu finden.

Consumer-Driven Contracts

Consumer-Driven Contracts betrachten Microservices aus der Perspektive der auf-rufenden Einheit. Der Contract beschreibt, wie die Antwort des Providers aufgebaut sein muss. Im Grunde genommen definiert der Consumer eines Service zusammen mit dessen Provider einen Vertrag und prüft in einem Test, ob der Vertrag eingehalten wird. Stellt der Provider nun eine neue Version des Service zur Verfügung, stellt er durch den Contract-Test aller Consumer sicher, dass alle Serviceaufrufe der Consumer noch funk-tionieren.

Der Vorteil dieser neuen Art von Tests ist, dass es im Prinzip Unittests sind, die lokal und unabhängig ausgeführt werden können. Dazu sind sie auch sehr schnell und zuver-lässig.

Listing 1: Auszug AuthServiceSlient.spec.js Listing 2: Auszug aus dem Consumer Contract

21

TESTAUTOMATION VON MICROSERVICES

Wie testen wir?

Im ersten Schritt definieren wir in der Datei AuthServiceClient.spec.js (siehe Listing 1), wie das API-Gateway den AUTH-Service aufruft und welcher JSON-Payload als Ant-wort erwartet wird. Wir definieren in der Datei:

› einen PACT-Mock-Server, der als Ser-vice-Provider fungiert,

› für jeden Request, den wir absetzen, definieren wir den JSON-Payload, der als Antwort zurückgeliefert werden soll,

› Tests, die den PACT-Mock-Server aufrufen und prüfen, ob die Antworten den definier-ten Erwartungen entsprechen.

Den Consumer-Contract starten wir durch:

mocha ../spec/AuthServiceClient.spec.js

Womit testen wir?

Für unseren Test verwenden wir PACT, ein Consumer-Driven-Contract-Testframework, das unter anderem für JavaScript, NodeJS, JVM, .NET, Ruby verfügbar ist.

Was testen wir?

Wir testen das Zusammenspiel des API-Gate ways als Consumer mit dem AUTH- Service, der als Provider fungiert (siehe Ab-bildung 5).

Abb. 5: Ablauf eines Consumer-Contract-Tests

22

TESTAUTOMATION VON MICROSERVICES

besondere Anforderungen an die Testauto-mation und Continuous-Delivery-Initiativen.

Durch die zusätzlichen Schnittstellen bei Microservices werden Integrationstests noch wichtiger für das Gesamtgefüge. Es lässt sich feststellen, dass im Bereich von Microservices die klassischen Integrati-onstests durch Consumer-Contract-Tests sinnvoll ergänzt beziehungsweise unter Um-ständen sogar durch diese ersetzt werden können. Consumer-Contract-Tests sind leicht zu schreiben, schnell und robust.

In Microservice-Architekturen nimmt Test-automation einen viel höheren Stellenwert ein als in anderen Systemen. Angesichts der Tatsache, dass die Entwicklung von Micro-services verteilt und unabhängig ist, können manuelle Teststrategien, die auf monolit-hische Architekturen angewendet werden, hier nicht angewendet werden. Testautoma-tion ist hier der Schlüssel zum Erfolg.

Der Artikel gibt die Meinung des Autors, und nicht die seines Arbeitgebers, wieder.

Der Provider liefert die Daten wie in der PACT-Datei beschrieben zurück und wir ha-ben eine erfolgreiche Testdurchführung:

Example app listening at http://:::8081 success

Zusammenfassend lässt sich feststellen, dass wir im Bereich von Microservices die klassischen Integrationstests fast vollstän-dig durch Consumer-Contract-Tests ersetzen könnten.

Fazit

Microservices ist ein Architekturansatz, der die gesamte Geschäftslogik in einem Netz-werk aus kleinen Services zur Verfügung stellt, und nicht in einem einzelnen Mono-lithen. Die Microservices sind dabei lose gekoppelt und laufen jeweils in einem eige-nen Prozess, damit sie leichter austauschbar sind. Durch die eigenständigen Services wer-den zusätzliche Schnittstellen sichtbar, die in einer monolithischen Architektur nicht vor-handen sind. Dieses Architekturmuster stellt

Der PACT-Provider-Mock liefert die Daten wie von uns definiert zurück und generiert einen Consumer-Contract, aka PACT-Datei.

PACT-Datei

Unser Test hat nicht nur das Verhalten des Providers überprüft, sondern auch den Consumer-Contract in der Datei consumer-lo-gin_provider.json gespeichert (siehe Lis-ting 2). Diese Datei im JSON-Format ist im Wesentlichen der Vertrag zwischen Consu-mer und Provider und enthält alle Interakti-onen, die definiert wurden. Jede Interaktion legt fest, was der Provider für einen gegebe-nen Request zurückgeben soll.

Dem Test aus Providersicht steht jetzt nichts mehr im Weg. Der Provider erhält die PACT-Datei vom Consumer und überprüft mit seinem Provider-Test (siehe Listing 3), dass er nicht gegen die Interaktionen verstößt, die der Consumer definiert hat. Der Provider-Test wird gestartet durch:

node ../spec/AuthService.spec.js

Rudolf Grötzrudolf.groetz@gmail.comseit 30 Jahren in der IT unterwegs und passionierter Softwaretester, ist als Senior Technical Test Engineer bei Raiffeisen Bank International in Wien im Bereich Softwaretests tätig und lebt den Leitspruch „Testautomation is not an act, Testautomation is a habit!“ Neben Fachartikeln in diversen Magazinen versorgt er die Community auch mit Konferenzauftritten und organisiert das Vienna Agile Testautomation Meetup.

Listing 3: Provider Test/AuthService.spec.js

Referenzen

› [Ash14] St. Ashman, Layers of Test Automation, QA Matters, 28.12.2014, siehe: http://qa-matters.com/2014/12/28/layers-of-test-automation/

› [Grö17] R. Grötz, D. Kukacka, N. Nikolic, Testautomation einer Microser-vice-Architektur – Teil 1 und 2, in: JavaSPEKTRUM, 03 und 04/2017

› [ISTQB] ISTQB Glossary, siehe: https://www.astqb.org/glossary

› [Scot16] A. Scott, Ask Me Anything, WatirMelon, 26.5.2016, siehe: https://watirmelon.blog/tag/testing-pyramid/

› [Thought] Consumer-driven contract testing, Technology Radar, ThoughtWorks, siehe: https://www.thoughtworks.com/radar/techniques/consumer-driven-contract-testing

23

IMPRESSUM

Know-how für Tester

J. Albrecht-Zölch

Testdaten und Testdatenmanagement

Vorgehen, Methoden und Praxis

2018, 454 Seiten, € 42,90 (D) ISBN 978-3-86490-486-8

T. Linz

Testen in Scrum-Projekten

Leitfaden für Softwarequalität in der agilen Welt

Aus- und Weiterbildung zum ISTQB® Certified Agile Tester – Foundation Extension

2. Auflage2016, 270 Seiten, € 34,90 (D) ISBN 978-3-86490-414-1

dpunkt.verlag GmbH Wieblinger Weg 17 D-69123 Heidelbergfon: 0 62 21 / 14 83 40fax: 0 62 21 / 14 83 99 e-mail: bestellung@dpunkt.de www.dpunkt.de

Linz

Test

en in

Scr

um-P

roje

kten

2. A

ufla

ge

Testen in

Scrum-Projekten

Tilo Linz

Leitfaden für Softwarequalität in der agilen Welt

Aus- und Weiterbildung zum ISTQB® Certified Agile Tester – Foundation Extension

2., a

ktua

lisie

rte

und

über

arbe

itet

e A

ufla

ge

»Das Buch ist sehr zu empfehlen.«Harry Sneed zur 1. Auflage

Interesse am E-Book? www.dpunkt.de/plus

Thema• Softwaretest• Qualitätssicherung• Softwareentwicklung

Leser• Tester • Testmanager• Projektleiter• Qualitätsverantwortliche• Softwareentwickler

Website• www.softwaretest-

knowledge.de

ISBN 978-3-86490-414-1

€ 34,90 (D) € 35,90 (A)

9 783864 904141

Tilo Linz

Testen in Scrum-Projekten

Softwareentwicklung wird heute mit agilen Methoden durchgeführt. Dass ein Team, eine Softwareabteilung oder ein ganzes Unterneh-men agiles Entwickeln langfristig erfolgreich realisiert und damit die erhofften Vorteile erzielt, daran haben Softwaretests und agile Softwarequalitätssicherung einen entschei-denden Anteil.

Dieses Buch gibt einen praxisorientierten Überblick über die am weitesten verbrei-teten Testmethoden und -praktiken sowie Managementinstrumente in agilen Projekten. Entwicklungsleiter, Projektleiter, Testmana-ger und Qualitätsmanager erhalten Hinweise und Tipps, wie Testen und Qualitätssicherung organisiert werden müssen, damit sie auch in agilen Projekten nicht an Schlagkraft ver-lieren. Professionelle Tester und Experten für Softwarequalität erfahren, wie sie in agilen Teams erfolgreich mitarbeiten und ihre spezi-elle Expertise optimal einbringen können.

Aus dem Inhalt:• Agile und klassische Vorgehensmodelle• Planung im agilen Projekt• Unit Tests, Test First• Integrationstests, Continuous Integration• Systemtests, Test nonstop• Qualitätsmanagement, Qualitäts sicherung

Fallstudien, ein durchgängiges Fallbeispiel sowie Übungsaufgaben und Checkfragen zum Self-Assessment runden den Inhalt ab.

Das Buch orientiert sich am ISTQB® Certified Tester – Foundation Level Extension Syllabus »Agile Tester«. Es eignet sich gleichermaßen für das Selbststudium wie als Begleitliteratur zu den entsprechenden Schulungen.

Die 2. Auflage wurde komplett überarbeitet und ist konform zum ISTQB®-Lehrplan Version 2014.

Albrecht-Zölch

Test

date

n un

d Te

stda

tenm

anag

emen

t

Best Practices • Cloud • Datenschutz • Effizienz • Metriken • Softwaretests • Test-abläufe • Testanalyse • Testarten • Testautomatisierung • Testdaten • Testdatenman-agement • Testdesign • Testprozess • Teststufen • Qualitätssicherung • Quellcode • Werkzeuge • Best Practices • Cloud • Datenschutz • Effizienz • Metriken • Software-tests • Testabläufe • Testanalyse • Testarten • Testautomatisierung • Testdaten • Test-datenmanagement • Testdesign • Testprozess • Teststufen • Qualitätssicherung • Quellcode • Werkzeuge •Best Practices • Cloud • Datenschutz • Effizienz • Metriken • Softwaretests • Testabläufe • Testanalyse • Testarten • Testautomatisierung • Testdaten • Testdatenmanagement • Testdesign • Testprozess • Teststufen • Qualitätssicherung • Quellcode • Werkzeuge • Best Practices • Cloud • Datenschutz • Effizienz • Metriken • Softwaretests • Testabläufe • Testanalyse • Testarten • Testautomatisierung • Testdaten • Testdatenmanagement • Testdesign • Testprozess • Teststufen • Qualitätssicherung • Quellcode • Werkzeuge • Best Practices • Cloud • Datenschutz • Effizienz • Metriken • Softwaretests • Testabläufe • Testanalyse • Testarten • Testautomatisierung • Testdaten • • Testdatenmanagement • Testdesign • Testprozess • Teststufen • Qualitätssicherung • Quellcode • Werkzeuge • Best Practices • Cloud • Datenschutz • Effizienz • Metriken • Softwaretests • Testabläufe • Testanalyse • Testarten • Testautomatisierung • Testdaten • Testdatenmanagement • Testdesign • Testprozess • Teststufen • Qualitätssicherung • Quellcode • Werkzeuge • Best Practices • Cloud • Datenschutz • Effizienz • Metriken • Softwaretests • Testabläufe • Testanalyse • Testarten • Testautomatisierung • Testdaten • Testdatenmanagement • Testdesign • Testprozess • Teststufen • Qualitätssicherung • QQuellcode • Werkzeuge • Best Practices • Cloud • Datenschutz • Effizienz • Metriken • Softwaretests • Testabläufe • Testanalyse • Testarten • Testautomatisierung • Testdaten

Vorgehen, Methoden und Praxis

Testdaten und Testdaten-

management

Janet Albrecht-Zölch

C

9 783864 904868

Interesse am E-Book? www.dpunkt.plus

Thema• Softwareentwicklung• Qualitätsmanagement• Testmanagement• Testen

Leser• Tester • Testanalysten• Testmanager• Projektleiter• Qualitätsmanager• Softwareentwickler

€ 42,90 (D)ISBN 978-3-86490-486-8

Janet Albrecht-Zölch

Testdaten und Testdaten management

Testdaten werden in jedem Softwareentwick-lungsprojekt benötigt. Das Management von Testdaten stellt sicher, dass diese jederzeit bedarfs-, zeit- und regelgerecht bereitstehen, und erhöht so die Effizienz und die Qualität des Testens.

Dieses Buch bietet eine umfassende Einführung in Testdaten und ein effizientes Testdatenmana-gement. Dabei werden sowohl fachliche als auch technische Konzepte vorgestellt. Es gliedert sich in drei Teile:

• Teil I erläutert die Eigenschaften von Testda-ten, die Anforderungen, Probleme und Risiken im Umgang mit ihnen sowie das Gewinnen und Archivieren. Auch auf Regelungen zum Datenschutz und auf Testdaten in der Cloud wird eingegangen.

• Teil II behandelt Modelle und Best Practices für das Testdatenmanagement, die Organisation und Test-Rollen sowie Werkzeuge und Metri-ken für Testdaten und Testdatenmanagement.

• Teil III enthält ein Vorgehen zum Einführen bzw. Verbessern eines Testdatenmanagements sowie Checklisten, Mustergliederungen und Fragenkataloge.

Zahlreiche Erfahrungsberichte und Praxisbei-spiele geben Einblicke in die reale Welt des Testdatenmanagements und erlauben dem Leser einen direkten Transfer zu seiner täglichen Arbeit.

K. Franz · T. Tremmel · E. Kruse

Basiswissen Testdatenmanagement

Aus- und Weiterbildung zum Test Data Specialist – Certified Tester Foundation Level nach GTB

2018, 208 Seiten, € 32,90 (D) ISBN 978-3-86490-558-2

Klaus Franz . Tanja Tremmel . Eckehard Kruse

Aus- und Weiterbildung zumTest Data Specialist

Certified Tester Foundation Levelnach GTB

Testdaten-management

Basiswissen

9 783864 905582

Interesse am E-Book? www.dpunkt.plus

Thema•Softwareentwicklung•Qualitätsmanagement•Testen

Leser•Testanalysten•Testmanager•Projektleiter•Qualitätsmanager•Softwareentwickler

€ 32,90(D)

ISBN978-3-86490-558-2

Bas

isw

isse

nTe

stda

tenm

anag

emen

tFranz

• Trem

mel•Kruse

KlausFranz•TanjaTremmel•EckehardKruse

BasiswissenTestdatenmanagement

OhneDatenistTestennichtmöglich.BenötigtwerdenEin-undAusgabedaten,Zustands-datenundeinTestorakel.

DieAutorengebeneinenpraxisorientiertenÜberblicküberdassystematischeTestdaten-managementunddenTestdatenmanagement-prozesssowiekonkreteAnregungenundHilfenfürdieeffizienteBereitstellungvonTestdaten.BehandeltwerdenimEinzelnen:

• Herausforderungen,Risiken,Nutzen• TestdatenartenundVerfahrenzuderen

Erzeugung• GesetzlicheRegelnundNormen,

Datenschutz• Testdatenmanagementprozess

(Aktivitäten,Ergebnisartefakte,Rollen)• EinbindungindieOrganisation• Testdatenwerkzeuge

DieallgemeingültigbeschriebenenArtefaktedesTestdatenmanagementswerdenabschlie-ßendmiteinemBeispielfürprojektbezogeneTestdatenartefakteundeinemBeispielfüreineTestdatenrichtlinieunterlegt.

DasBuchorientiertsichamLehrplanzum»CertifiedTesterFoundationLevelTestDataSpecialist«nachGTB(GermanTestingBoard)undeignetsichmiteinemausführlichenGlos-sarundKontrollfragenmitLösungshinweisengleichermaßenfürdasSelbststudiumwiealsBegleitliteraturzudenentsprechendenSchulungen.

Kostenfreie Broschüre zum Buch »Lean Testing für C++-Programmierer«

Jetzt herunterladen:

www.dpunkt.de/s/lt

Buch + E-Book:

www.dpunkt.plus

Lean Testing fürC++-Programmierer

Spillner

Breymann

Lean

Testin

g fü

r C++

-Pro

gram

mie

rer

Angemessen statt aufwendig testen

Lean Testing fürC++-Programmierer

Andreas Spillner . Ulrich Breymann

Konform zu ISO 29119

9 783864 903083

www.dpunkt.deInteresse am E-Book? www.dpunkt.de/plus

Thema• Programmierung • Softwaretest• Qualitätssicherung• Softwareentwicklung

Leser• Programmierer• Softwareentwickler • Softwaretester • Dozenten und Studenten

Website• http://leantesting.de

€ 29,90 (D) € 30,80 (A)ISBN 978-3-86490-308-3

Andreas Spillner . Ulrich BreymannLean Testing für C++-ProgrammiererSie programmieren – auch in C++. Sie führen regelmäßig Unit Tests durch. Sie sind sich manchmal unsicher, ob Sie ausreichend oder zu viel getestet haben. Werfen Sie einen Blick in dieses Buch, Sie werden viele Anregungen für Ihre tägliche Arbeit finden!

»Lean Testing« steht für einen Ansatz, der auf der einen Seite alle wichtigen Testfälle zur Prüfung der Software berücksichtigt, auf der anderen Seite aber den Testaufwand in einem überschaubaren Rahmen hält. Der angemes-sene Mittelweg zwischen zu wenig und zu viel Testen wird bei jedem Vorgehen zum Entwerfen der Testfälle diskutiert und erörtert. Die in diesem Buch präsentierten Vorgehens-

weisen zum Testfallentwurf werden konkret mit den entsprechenden C++-Programmtexten und den jeweiligen Testfällen dargelegt. Sind hierzu unterstützende Werkzeuge erforderlich, beschreiben die Autoren deren Anwendung. Dabei geben sie nützliche Hinweise für die Verwendung der Testverfahren und bieten einen Leitfaden für ihren Einsatz. Alle Testverfahren des aktuellen ISO-Standards

29119, die für den Unit Test relevant sind, werden vorgestellt und ausführlich behandelt. Ulrich Breymann ist ein bekannter Fachautor für

die Programmiersprache C++ – Andreas Spillner für den Testbereich. Beide Autoren bringen ihre Fachkompetenz ein und schlagen eine Brücke zwischen Programmierung und Test. Das Buch unterstützt die aktuelle Entwicklung, bei der Softwareerstellung keine strikte (personen-bezogene) Trennung zwischen Implementie-rung und Test auf Unit-Ebene vorzusehen (z.B. TDD & Test-first-Ansatz).

ImpressumVERLAG:

SIGS DATACOM GmbHLindlaustraße 2c, D-53842 TroisdorfTel.: +49 (0) 2241/2341-100Fax: +49 (0) 2241/2341-199www.sigs-datacom.deE-Mail: info@sigs-datacom.de

CHEFREDAKTEUR:

Dr. Stephan Weißleder und Richard Seidl

SCHLUSSREDAKTEURIN:

Annette WeinertE-Mail: schlussredaktion@objektspektrum.de

VERLAGSLEITUNG:

Emanuel Rosenauer

VERTRIEBSLEITUNG:

Miro KeilE-Mail: miro.keil@sigs-datacom.de

GRAFIK & PRODUKTION:

F&W Perfect Image GmbHAm Oberfeld 1 · D-83026 Rosenheim,E-Mail: info@perfectimage-gmbh.de

DRUCK:

F&W Druck- und Mediencenter GmbHHolzhauser Feld 2 · D-83361 KienbergTel.: +49 (0) 8628/9884-52E-Mail: anzeigendaten@objektspektrum.de

BILDNACHWEISE:

Titelbild: ShutterstockSeite 4 und 6: Shutterstock

URHEBERRECHT:

Für Programme, die als Beispiele veröffentlicht werden, kann der Herausgeber weder Gewähr noch irgendwelche Haftung übernehmen. Aus der Veröffentlichung kann nicht geschlossen werden, dass die beschriebenen Lösungen oder verwendeten Bezeichnungen frei von gewerb-lichen Schutzrechten sind. Die Erwähnung oder Beurteilung von Produkten stellt keine irgendwie geartete Empfehlung dar. Für die mit Namen oder Signatur gekennzeichneten Beiträge übernehmen der Verlag und die Redaktion lediglich die presse-rechtliche Verantwortung.

© 2018 SIGS DATACOM GmbH

Die Zeitschrift wird mit chlorfreiem Papier hergestellt.

MANUSKRIPTEINSENDUNGEN:

Manuskripte werden von der Redaktion – aus-schließlich in elektronischer Form – gerne ange-nommen. Mit der Einsendung von Manuskripten gibt der Verfasser die Zustimmung zum Abdruck, zur Vervielfältigung auf Datenträgern und zur Übersetzung.Das German Testing Magazin erscheint als Verlagsbeilage in den Magazinen OBJEKTspektrum und JavaSPEKTRUM.