Page 1

Ausgabe 42 | März 2017

IM GESPRÄCH: mit dem DevOpsExperten Uwe Friedrichsen

TITELTHEMA: Quality Driven DevOps

PLU

S: Die a ktuel len Schul ungstermi n f ür 2 0 e 17

Folgen Sie uns auf Twitter und Facebook.

twitter.com/SQMagazin facebook.com/SQforyou

ISSN 2367-3516


SOCIAL IMPACT

5

High

THE STARTUP BOOSTER

1.9

Supporting startups in the development of their employee’s skills

60%

DER GRÖSSTEN DEUTSCHEN MARKEN NUTZEN AKTIV SOCIAL MEDIA

1 MINUTE im Internet

MILLIARDEN MENSCHEN WELTWEIT NUTZEN SOCIAL MEDIA

48h

Videomaterial auf YouTube geladen

3.000

QUALITY IS THEFotos auf Flickr geladen PLAN 39%BEST BUSINESS685.000 Facebook-Inhalte geteilt Twitter

78%

©Rawpixel.com_shutterstock.com

37% YouTube

28%

Facebook

12%

Unternehmensblogs

100.000

neue Tweets

high5startups.com 2+ Mio. Suchanfragen auf Google

ÜBER 78% DER DEUTSCHEN INTERNETNUTZER VERWENDEN SOCIAL MEDIA NETZWERKE

Join High5´s breakfast TV live from the SXSW March 10-13, 2017 | 9 AM (CST)

Meet the experts and follow the trends of the world´s largest digital and creative gathering via High5´s breakfast TV!


3

Ausgabe 42  |  März 2017

Editorial

Es geht ein Gespenst um in Deutschland… Europa droht auseinanderzubrechen, das behauptet zumindest US-Präsident Donald Trump. Und es gibt einige, die seine Ansicht teilen. Griechenland-Fiasko, Brexit, das Erstarken der rechten Parteien in Holland, Frankreich und Polen – was wird wohl als nächstes kommen? Deutschland, so schien es, war bis vor kurzem eine sichere, feste Burg inmitten von Ungewissheit und Destabilität. Doch dann kam Herr Schulz. Seither geht die German Angst wieder um. In den Medien zeichnet der designierte SPD-Kanzlerkandidat ein düsteres Bild von Deutschland: ungerecht und unsozial gehe es zu. Man müsste meinen, die ersten Barrikadenkämpfe zwischen der geknechteten Unterschicht und den gierigen Oberetagen-Managern stünden kurz bevor. Was hier mit Bezug auf Herrn Schulz mehr als überspitzt formuliert ist, erweckt den Eindruck, Deutschland taumle angesichts sozialer und wirtschaftlicher Ungerechtigkeit langsam aber sicher dem Abgrund entgegen. Dabei geht es Deutschland so gut wie nie zuvor. „Kaum ein anderer Industriestaat hat sich mit Blick auf die eigene Zukunftsfähigkeit in den vergangenen zehn Jahren so positiv entwickelt“, ergibt eine Studie der Bertelsmann-Stiftung, die die Regierungsführung in den entwickelten Industrieländern bewertet. Mit seiner Kritik an der Agenda 2010 versucht Schulz einen anderen Eindruck zu erwecken – und verwandelt sich damit immer mehr zu einem Abziehbild von Donald Trump, jedenfalls in den Methoden.

Das Klagen und Schimpfen von Herrn Schulz fördert nicht gerade den Optimismus und die Stabilität unseres Landes. Genau das Gegenteil von Pessimismus – eine positive Einstellung zur Zukunft – ist das, was wir brauchen, um erfolgreich zu sein. Damit meine ich nicht, wir sollten alles schön reden. Aber wir sollten uns zumindest fragen, ob die Dinge wirklich so schlecht sind, wie sie andere

malen. Wir stehen nicht nur vor einer sozialen Herausforderung, sondern auch vor der Frage, wie sich angesichts einer voranschreitenden Digitalisierung unsere Arbeit, Produktion, Kommunikation, unsere (ethischen) Werte und unsere Gesellschaft verändern werden. Das allein ruft schon eine gewisse Unsicherheit hervor. Deshalb ist ein positives Denken so wichtig. Keine Neiddebatte. Herr Schulz und seine Forderungen mögen der Stimmung in der SPD zuträglich sein – doch sie reden das klein, was unser Land bisher stark gemacht hat. In Deutschland geht die Angst um. Dabei bräuchten wir mehr Mutmacher, wie den zukünftigen Bundespräsidenten Frank-Walter Steinmeier. Herzlichst

Ihr Stephan Goericke ASQF-Hauptgeschäftsführer

Was ist Ihre Meinung oder Erfahrung? Teilen Sie mir Ihre Gedanken mit! Ich freue mich auf Ihre Zuschrift und einen anregenden Austausch zu den verschiedensten Themen. s.goericke@sq-magazin.de


ASQF NEWS 14

Quality-Driven

DevOps

DevOps Eine Revolution im Kopf Inhalt 5 ASQF-NEWS TITELTHEMA 8

Quality Driven DevOps

16 DevOps – Ein Geschenk für Software-Produktmanager 34 Hohe Qualität durch eine testgetriebene Entwicklung

8

GERMANY GOES SXSW

MIT EINER EIGENEN DELEGATION IST DEUTSCHLAND AUCH IN DIESEM JAHR AUF DER SXSW IN AUSTIN/TEXAS PRÄSENT.

14 IM GESPRÄCH mit DevOps-Experte Uwe Friedrichsen

28 GERMANY GOES SXSW 32 iSQI-NEWS

4

Ausgabe 41  |  Dezember 2016

28


ASQF NEWS

5

ASQF

Das Expertennetzwerk für Software-Qualität Feier zum 20-jährigen Jubiläum

Prof. Dr. Bernd Hindel nimmt den Deutschen Preis für Software-Qualität für sein Lebenswerk von Stephan Goericke entgegen.

Nach wie vor ist SoftwareQualität für viele Menschen ein schwer greifbares Thema. ASQF-Präsidentin Prof. Dr. Ina Schieferdecker

Der ASQF, wichtigstes Netzwerk von SoftwareQualitätsexperten im deutschsprachigen Raum, wurde 1996 im fränkischen Erlangen gegründet. Seitdem gestaltet der Arbeitskreis maßgeblich die Entwicklung und Sicherung von Softwarebzw. System-Qualität. Als Repräsentant und Stimme der SoftwareBranche befindet sich der Verband im Dialog mit Entscheidungsträgern in Wirtschaft und Politik. Über die Jahre hat der Verein wesentlich dazu beigetragen, die Verfahren im Bereich Qualitätssicherung zu definieren und weiterzuentwickeln. Auch für Fortbildung eintretend, fördert der ASQF eine international einheitliche Aus- und Weiterbildung von IT-Fachkräften – Stichwort „Certified Tester“, welcher in Deutschland von einer Arbeitsgruppe des ASQF entwickelt und in die Industrie gebracht worden ist. Wesentliche Beiträge zur Etablierung von z.B. Spice® und INTACS™ wurden vom ASQF initiiert und umgesetzt. Es werden stetig weiter Vorschläge erarbeitet, die den neuen Anforderungen der Digitalisierung Rechnung tragen, aktuell in der Arbeitsgruppe zum Thema Internet of Things. Diese arbeitet derzeit an einem Zertifizierungsstandard für das Quality Engineering für das Internet der Dinge. Das Herz des ASQF sind weiterhin seine Fachgruppen und der inhaltliche Austausch in den Netzwerken. So werden leistungsstarke StartUps, Mittelständler, Global Player und Hochschuleinrichtungen miteinander verbunden.

Im Dezember 2016 feierte der ASQF e.V. sein 20-jähriges Bestehen mit einem festlichen Empfang im CINIQ Center Berlin. Mit Blick auf die Zukunft sagte ASQF-Präsidentin Prof. Dr. Ina Schieferdecker: „Nach wie vor ist Software-Qualität für viele Menschen ein schwer greifbares Thema. Hinsichtlich Automatisierung und Digitalisierung müssen wir ihnen Antworten geben, wie bestimmte Prozesse, z.B. beim autonomen Fahren, abgesichert werden können. Neue Technologien werden nur akzeptiert, wenn ihnen die Menschen vertrauen. Wir müssen daher unser Bestes tun, um die Gemeinschaft auf dem Weg der Digitalisierung mitzunehmen.“ Stephan Goericke, Hauptgeschäftsführer des ASQF, stimmte in seiner Begrüßungsrede zu: „Wir haben immer Themen gesetzt und den Weg nach vorn gezeigt. Nun müssen wir darüber diskutieren, wie die nächsten 20 Jahre aussehen sollen.“ Ehrenpreis verliehen Im Rahmen der Jubiläumsfeier wurde Prof. Dr. Bernd Hindel für sein Lebenswerk mit dem Deutschen Preis für Software-Qualität ausgezeichnet. Prof. Dr. Bernd Hindel ist ASQF-Gründungsmitglied und Präsident der ersten Stunde. Er nahm den Ehrenpreis auf der Veranstaltung in Berlin persönlich entgegen. In seiner Laudatio verdeutlichte Dr. Walter Wintersteiger, Ehren-Präsident der Österreichischen Vereinigung für SoftwareQualität, warum Prof. Dr. Bernd Hindel in seinen Augen die „Inkarnation von ganzheitlicher Software-Qualitätssicherung“ ist. Prof. Dr. Bernd Hindel, Gründer der Method Park Unternehmensgruppe, hat die Entstehung, Etablierung und Strukturierung des Berufsstandes des SoftwareTesters im deutschsprachigen Raum maßgeblich beeinflusst und mitgetragen. Dies wurde von Dr. Walter Wintersteiger betont, der ausführte: „Bernd Hindel ist es im Wesentlichen zu verdanken, dass es ein Branchennetzwerk wie den ASQF nur im deutschsprachigen Raum gibt. Mit dem Satz „Wir machen das jetzt“, setzte er um, was sich viele wünschten, aber nicht zutrauten: Die Gründung eines Netzwerkes, in dem sich die Tester-Community austauschen konnte.“


DEV OPS

Ausgabe 42  |  März 2017

6

DevOps - Wir wollen alle dasselbe! Christian Eggbauer, ANECON ASQF-Vizepräsident Norbert Kastner (r.) und Michael Strobel (l.) von der infoteam Software AG überreichten den ASQF-Förderpreis an Marcel Busch.

Marcel Busch erhält ASQF-Förderpreis für seine Masterthesis DevOps, ein neues Buzzword das viele Unternehmen beschäftigt - und das zu Recht! Der Ansatz lässt Fehler so früh erkennen wie keine andere Methode und reduziert drastisch die Gesamtdurchlaufzeit durch effiziente, rasche Fehlerbehebung. Hohe Geschwindigkeit. Steigende Qualität. Mehr Innovation. Mühsame manuelle Tests werden automatisiert. Mit Hilfe von Service Virtualisierung gelingt eine simple Abbildung ganzer heterogener Systemlandschaften, um frühzeitige Tests schnell und produktionsnah durchzuführen. Ebenso werden die Themen Deployments, LogFiles durchgraben, Abstimmungen über falsche Versionen, Fallbackszenarien oder Releasenotes somit obsolet. Und dies alles spart Zeit! Mindset schärfen - zusammen bewegen wir mehr! Nichtsdestotrotz - DevOps muss verstanden, etabliert und gelebt werden. Dafür ist, ein durchgängiges Commitment seitens des Managements notwendig. Schritt für Schritt und DevOps-Teams werden einen hohen Mehrwert für das Unternehmen bringen!

Lesen Sie den ganzen Artikel am ANECON Blog - das Thema wird aus Sicht der Projektleitung beleuchtet und das realitätsbezogen und ehrlich! https://goo.gl/jOkdqd

www.anecon.com/blog

Während einer Absolventenfeier an der Friedrich-Alexander-Universität Erlangen-Nürnberg wurde Anfang Februar der ASQF-Förderpreis an Marcel Busch verliehen. Die mit 500 Euro dotierte Auszeichnung wurde dieses Mal von der infoteam Software AG gesponsert. ASQF-Vizepräsident Norbert Kastner überreichte zusammen mit Michael Strobel von der infoteam Software AG die Auszeichnung. Marcel Busch widmete sich in seiner Abschlussarbeit, betreut durch Dr. Tilo Müller und Dipl.-Inf. Mykola Protsenko, dem Thema „Android Application Protection Reinforced by Off-Device Ahead of Time Compilation“. Lob hierfür gab es unter anderem von der Leitung des Lehrstuhls Informatik an der FAU. „Herr Busch entwickelte einen innovativen Ansatz zum Schutz von mobile Android Apps, der diese zuverlässig gegen ReverseEngineering-Angriffe auf BytecodeEbene härtet. Herr Busch hat diesen Ansatz sehr selbstständig und fachlich hervorragend realisiert und damit einerseits einen Beitrag zum Schutz hochqualitativer Software vor dem

Kopieren geleistet. Andererseits ist die sorgfältig ausgearbeitete Lösung auch beispielhaft für Software mit hoher Qualität“, würdigte Prof. Dr. Freiling, Leiter des Lehrstuhls Informatik 1 (IT-Sicherheitsinfrastrukturen), die Arbeit des Preisträgers. Der ASQF e.V., größtes Expertennetzwerk für Software-Qualität im deutschsprachigen Raum, vergibt seit 2006 seinen Förderpreis an junge Talente. Er wird einmal im Semester an Studenten und/oder Absolventen verliehen und würdigt besonders gute Leistungen während des Studiums, eine kurze Studiendauer und eine Abschlussarbeit, die in besonderem Maße Praxisnähe und Software-Qualitätsaspekte berücksichtigt. In Kooperation mit verschiedenen Hochschulen wird der ASQF-Förderpreis derzeit an der FU Berlin, FH Brandenburg, BTU Cottbus, TU München, FH Nürnberg und der Friedrich-AlexanderUniversität Erlangen-Nürnberg vergeben.


ASQF NEWS

7

20 Jahre Software-Qualität Anlässlich seines 20-jährigen Bestehens hat der ASQF eine Sonderschrift mit dem Titel „20 Jahre im Dienst von Qualität“ herausgegeben. In ausgewählten Beiträgen erörtern hochkarätige Branchenexperten unterschiedliche Fragen von Software-Qualität. Mitglieder des ASQF erhalten dieses umfangreiche Werk kostenfrei. JETZT MITGLIED DES ASQF WERDEN: Erhalten Sie zur Begrüßung eine Sonderschrift kostenfrei und nutzen Sie den Zugang zu hochwertigen (kostenfreien) Events, die einen persönlichen Austausch mit Experten aus Wirtschaft und Politik auf persönlicher Ebene unterstützen. MEHR ZU IHREN VORTEILEN ALS ASQF-MITGLIED ERHALTEN SIE AUF www.asqf.de/asqf/mitglied-werden

Qualitätssicherung für das Internet der Dinge ASQF Quality Day in Berlin Ausführlich wurde beim vergangenen ASQF Quality Day in Berlin über Herausforderungen und Ansätze für das Internet of Things in Praxis und Theorie diskutiert, sei es modellgetriebene Entwicklung und Tests, Prozesserfordernisse, Plattformen oder Services. Gerade die Herausforderungen an die Software-Qualität und die Sicherheit sind im hoch vernetzten Internet of Things enorm. Dies betonte auch Dr. Andrej Pietschker in seiner Keynote „Im Testen nichts Neues“. In seinem Vortrag über die vergangenen 20 Jahre der Testautomatisierung schlug er eine Brücke von Ansätzen in der Testautomatisierung und -beratung hin zu aktuellen Themen des Software-Tests, besonders die künftigen Herausforderungen im IoT-Umfeld. Um diesen Herausforderungen begegnen zu können, benötigt es Quality Engineering für das Internet der Dinge, wie Armin Metzger vom ASQF betonte. Hierfür werde gerade in einer Kooperation des Expertennetzwerkes ASQF und des German Testing Boards ein Trainingsschema entwickelt. Besonders interessant für IoT sind die Sicherheitsaspekte. Eindrucksvoll stellte Thomas Haase dar, wie leicht es Hackern gemacht wird, an Passwörter und andere empfind-

liche Daten zu gelangen. In Bezug auf das Internet of Things ist diese Gefahr bzw. Unsicherheit nicht zu unterschätzen. Insgesamt schätzten die Teilnehmer die gute und aktuelle Themenzusammenstellung des ASQF Quality Days. Auch Günter Schneider (Sulzer GmbH), Aussteller und Sponsor, betonte: „Die Vorträge waren sehr spannend. Wir haben gute und intensive Gespräche mit den Teilnehmern geführt.“ Das Internet of Things ist und bleibt weiterhin ein sehr interessantes Thema, zu dem es noch mehr Veranstaltungen vom ASQF geben wird.

Zuwachs: Neue Mitglieder im ASQF e.V. rola Security Solutions GmbH Oberhausen www.rola.com

New Elements GmbH Nürnberg www.newelements.de

Werden Sie Mitglied im ASQF! Jetzt Mitgliedsantrag stellen und Teil einer Community aus über 1.400 Qualitätsexperten werden. www.asqf.de/asqf/mitglied-werden


Titelthema

Ausgabe 42  |  März 2017

Quality-Driven

DevOps von Sven Euteneuer

8


9

validiert werden können, ist hier vorbei. In vielen Branchen treiben neue, leichtgewichtige Player die etablierten Marktteilnehmer dabei vor sich her. In einschlägigen Umfragen geben bereits bis zu 65 Prozent der Befragten an, monatliche, wöchentliche oder sogar tägliche Releases zu planen.

Was ändert sich, was bleibt gleich − und wie können Qualitätssicherung und Test von DevOps profitieren? Unter DevOps (Abkürzung für Development und Operations) versteht man eine Philosophie, die seit langer Zeit organisatorisch getrennten Bereiche Entwicklung und Betrieb von IT-Systemen wieder an einen Tisch zusammenbringt und Kommunikation, Zusammenarbeit und Interaktion fördert. Neben organisatorischen und prozessualen Mitteln wird auch darauf gesetzt, wiederkehrende Tätigkeiten weitestgehend zu automatisieren. Getrieben wird die Einführung von DevOps in Unternehmen dadurch, dass sich Anforderungen − insbesondere überall dort, wo IT an der Kundenschnittstelle oder in Produkten eingesetzt wird − häufig und hochfrequent ändern. Die Zeit stabiler Pflichtenhefte, die in wasserfallartigen Prozessen umgesetzt, verifiziert und

Wenn nun ein Ansatz wie DevOps es sich auf die Fahnen schreibt, schnelle Reaktionsfähigkeit zu ermöglichen, gleichzeitig aber damit wirbt, Qualität zu steigern und Kosten zu senken, dann ist ihm die Aufmerksamkeit von Entscheidern sicher. Die Effektivität von DevOps-Vorgehen lässt sich dort nachweisen, wo der Ansatz systematisch, geplant und diszipliniert eingeführt und gelebt wird. Aber auch DevOps ist nicht die sprichwörtliche „Silver Bullet“ – auch für DevOps gibt es Leitplanken, Vorbedingungen und Erfolgsfaktoren. Dazu gehören: Zusammenarbeit von Development und Operations, Automation, eine Continuous Delivery sowie eine Anpassung der Software- und Systemarchitekturen. Parallel dazu hat die gesamtwirtschaftliche Lage in Deutschland dazu geführt, dass gerade in der IT ein akuter Fachkräftemangel spürbar ist. Überall dort aber, wo das Angebot an einem Gut (hier qualifizierter Arbeit) knapp ist, treten die Nachfrager desselben automatisch in einen Wettbewerb, der einerseits über Gehälter und Sonderleistungen stattfindet, andererseits auch zu „Techie-freundlicheren“ Arbeitsumgebungen führt; dazu gehört auch ein zeitgemäßes Vorgehensmodell. Kein gestandener Entwickler und erst recht keiner der


Titelthema

Ausgabe 42  |  März 2017

10

Abbildung 1: Eigenschaften von DevOps

vielbeschworenen Millenials wird sich freiwillig auf ein Wasserfallmodell kurz vor dem großen „Go-Live“ einlassen. Wer hier einen moderneren, iterativen, werkzeugunterstützen Ansatz bieten kann, ist klar im Vorteil. DevOps und Fachkräftemangel verändern Entwicklungsumgebungen Wenn nun ein starker Fokus darauf liegt, Technikern attraktive Bedingungen zu bieten, ist es ganz zwangsläufig, dass die gewählten Lösungen häufig stark technikfokussiert sind. An dieser Stelle kommen die Trends DevOps und Fachkräftemangel zusammen. Sie sorgen dafür, dass das Umfeld, in dem heute Software entwickelt, integriert und betrieben wird, viel stärker auf technische Affinität zurückgreift, auch und gerade über die klassisch technischen Rollen hinaus. Man muss nicht weit schauen, um Indizien hierfür zu finden: So finden sich in vielen Disziplinen wie Netz-

werk- oder Umgebungsmanagement Tendenzen hin zu Configuration- oder Infrastructure-as-Code. Das heißt, es werden vermehrt Artefakte in Form von Quellcode hinterlegt. Ein weiteres Indiz ist die Veränderung der Stellenprofile von Test- und QS-Rollen in Projekten. War hier traditionell eine gute Kombination aus Domänen- (Fachlichkeit) und Methodenkompetenz (Testmethodik) gefragt, so tritt hier mittlerweile die Anforderung nach Entwickler-Know-how, Programmiersprachen und Testautomatisierung immer stärker in den Vordergrund. Und die Qualität? Die beschriebenen Veränderungen haben massive Auswirkungen – und wie jede Veränderung birgt auch diese das Risiko des Scheiterns. Allerdings stehen wir hier vor einer Situation, in der Rollen mit Qualitätsbezug einen wesentlichen Beitrag zum Gelingen dieser Transition leisten können. Ganz

konkret sind dies die folgenden drei Beiträge: Etablierung cross-funktionaler Teams über die Entwicklung hinaus, Aufsetzen einer funktionierenden Continuous Delivery Pipeline, Schaffung von Transparenz im Tagesgeschäft. Cross-funktionale Teams Nicht erst seitdem DevOps zum Hype wurde, hat sich die Erkenntnis durchgesetzt, dass strenge, anhand einer industriellen Fertigungsstraße ausgerichtete arbeitsteilige, Vorgehen in der komplexen, interdependenten und sich schnell ändernden Welt der IT nicht die optimale Lösung darstellen. So ähnelt Software-Entwicklung doch mehr der Entwicklung eines Produkts denn seiner industrialisierten Fertigung. Daher fordern schon Ansätze aus der agilen Software-Entwicklung die Auf-


11

stellung von interdisziplinären oder auch cross-funktionalen Teams. In diesen Teams gibt es keine schematische Arbeitsteilung. Jedes Teammitglied sollte ein T-förmiges Fähigkeitsprofil mitbringen, das heißt: Spezialist in einem Bereich sein, aber breites Oberflächenwissen in anderen Bereichen mitbringen. Hier wird jedoch häufig zu kurz gedacht. Während es sinnvoll ist, solche interdisziplinären Entwicklungsteams aufzustellen, ist es wenig sinnvoll, danach sofort aufzuhören. Allzu häufig führt dies zu Situationen, in denen hochagil arbeitende Entwicklungsteams ad absurdum geführt werden, wenn der Rest der Organisation wie Fachbereich, Betrieb oder auch nur weitere Teams, die andere Systeme verantworten, nicht eingebunden sind. DevOps versucht solchen Fehlentwicklungen zu begegnen, indem grundsätzlich und von Beginn an alle operativen Stakeholder Teil des crossfunktionalen Teams sind. Das bedeutet, dass insbesondere der Fachbereich und die zukünftigen Nutzer beziehungsweise Betreiber der Software im Team vertreten sind. Während schon der Begriff DevOps klar macht, dass neben der klassischen Entwicklungssicht nun auch eine Betriebssicht integraler Bestandteil wird, besteht das Risiko, dass die Qualitätssicht wenig Beachtung findet beziehungsweise sogar ausgeklammert und als späteres Implementierungsdetail verkannt wird. Hier muss eingegriffen werden. Nur, wenn das gemischte Team adäquat auch mit QS-bezogenen Skills und Rollen ausgestattet ist, kann ein DevOps-Ansatz Erfolg haben. Allein die Idee, Änderungen mehr oder weniger automatisch in den Live-Betrieb zu schieben, muss wahnsinnig erscheinen, wenn nicht über den gesamten Prozess von der Entwicklung bis zum Betrieb eine stringente Qualitätssicherung sichergestellt ist. Die koordinierte Integration einzelner Komponenten in größere und komplexere Systeme kann dabei mit Me-

chanismen wie MicroServices gelöst werden, die sicherstellen, dass einzelne Teams gleichzeitig handlungsfähig bleiben, aber auch klare Schnittstellen zu ihrer Umgebung anbieten. Eine regelmäßige Koordination zwischen den Teams ist notwendig, um zum Beispiel die Ablösung einer Schnittstelle durch eine neuere Version mit anderer Signatur zu koordinieren. Aus einer übergreifenden, architekturgetriebenen QS-Rolle kann eine solche Koordination über eine Vielzahl kleiner DevOps-Zellen oder -Pods effektiv und effizient geleistet werden. Continuous Delivery Pipeline Die zweite wesentliche Säule, auf der DevOps steht, ist die Umsetzung einer Continuous Delivery (CD) Pipeline. Der Automationsgrad einer solchen Pipeline kommt hier vor allem der schnellen Überführung von Änderungen in den IT-Betrieb zu Gute. In voller Ausbaustufe werden Änderungen, beginnend vom Check-In, automatisiert durch die Pipeline geschleust. Werden keine Abweichungen erkannt, geht die Änderung je nach Risikoprofil auch direkt live. Auf diese Art und Weise bleiben Unternehmen wie Spotify am Puls der Zeit und können Anregungen durch Nutzer teilweise innerhalb von Tagen umsetzen. Darüber hinaus liegt der Vorteil von CD darin, schnell und systematisch erwiesenermaßen funktionierende Software-Releases produzieren zu können. Das erleichtert nicht nur die Arbeit des eigentlichen ReleaseManagements, welches weniger Aufwand benötigt, ein Release technisch herzustellen. Darüber hinaus erleichtert dieses Vorgehen auch die Zusammenarbeit mit anderen Teams oder bei der Integration in große Systeme von Systemen. Überall dort ist es von Vorteil, erkannte Probleme schnell zu korrigieren, zu testen und in ein entsprechendes Release zu deployen. Abbildung 2 zeigt ein Beispiel für eine solche Pipeline. Konkrete Implementierungen sind immer bezogen auf ein konkretes technisches Umfeld (Hard-


Titelthema

Ausgabe 42  |  März 2017

MODDELING STAGE

COMMIT STAGE

ACCEPTANCE TEST STAGE

NFT TEST STAGE

PRODUCTION STAGE

Analyze individual items

Compile Execute Unit Test

Configure Environment

Configure Environment

Configure Environment

Package

Package

Deploy Binaries

Deploy Binaries

Deploy Binaries

Analyze integrated items

Execute Code Analysis

Execute Smoke Tests

Execute Smoke Tests

Execute Smoke Tests

Execute Acceptance Tests

Execute User Acceptance Tests

Abbildung 2: Beispiel für eine CD-Pipeline

ware, Betriebssystem, TechnologieStack, Programmiersprache, Buildund Compiler-Infrastruktur oder Testwerkzeuge). Im Grunde besteht eine Pipeline dabei aber immer aus einer Abfolge sogenannter Stages (in der Abbildung dunkel dargestellt) mit ihren jeweiligen Prozessschritten (hell dargestellt). Jede Stage entspricht dabei einer Tätigkeit im Entwicklungsprozess beziehungsweise einer neuen Integrationstiefe. Sinnvollerweise beginnt die Pipeline mit den ersten Artefakten aus dem Prozess. Das können Modelle oder Quellcode sein. Wird das System zunächst in Modellen entworfen, stellt die Analyse die erste Stage der Pipeline dar. Manuell entwickelter Code stößt anschließend dazu (in nicht-modellgetriebenen Ansätzen stellt dies üblicherweise die erste Stufe der Pipeline dar). Unterstützt durch durchgängige Repositories für alle Artefakte integriert hier ein CI-System die Quellcodelieferungen und unterzieht sie Build- und Test-Prozessen. Ein Vorteil ist dabei, dass das CI-System damit zum „Quell der Wahrheit“ wird und offizielle Builds herausgibt. Lokal erzeugte Builds, mit allen ihren Problemen rund um das Konfigurationsmanagement, werden weniger wichtig. Neben dem eigentlichen Build laufen auf dem CI-System erste Code-nahe Tests ab. Üblicherweise werden hierzu sowohl fachliche Tests (z.B. mittels fachlichen Unit Tests) als auch nichtfachliche Tests implementiert (z.B.

mittels nichtfachlicher Unit Tests oder mittels anderer Verfahren wie statischer Analyse für bestimmte Anforderungen zu Wartbarkeit, Übertragbarkeit oder Sicherheit). Für jede Stufe der Pipeline gilt: Sind alle Schritte auf dieser Stufe erfolgreich durchlaufen, so darf eine Stufe weitergerückt werden. Schlägt zum Beispiel der Build oder ein Test fehl, wird nicht weitergerückt; eine nach Analyse und Bugfix eingecheckte Version, die das Problem korrigiert, kann sich dann erneut „bewerben“. Nun folgt eine Reihe von Teststufen, die je nach konkretem Umfeld, Organisation und Integrationstiefe unterschiedlich implementiert werden. Meist sind eine fachliche Abnahme der Lieferung dabei („Acceptance Test“) sowie gegebenenfalls eine Stufe, die dedizierte dynamische Prüfungen nicht-fachlicher Anforderungen vornimmt („NFT Test Stage“). Während auf der Commit Stage noch keine dedizierten Umgebungen angebunden waren, werden diese nun zum Thema. In aller Regel müssen hier virtualisierte (Simulator/Emulator) oder physische Umgebungen (x-inthe-loop) angebunden sein. Um einen hohen Automationsgrad zu erreichen, ist hier häufig Integrationsaufwand zu leisten, so dass Umgebungen automatisiert zusammengestellt, initialisiert, genutzt und wieder abgebaut werden können. Sind auch diese Stufen der Pipeline erfolgreich durchlaufen, kann das Ergebnis freigegeben werden. Auch,

12


13

wenn es eine Produktionsumgebung im Sinne der IT nicht gibt, kann ein solcher Build intern bereitgestellt oder nach Durchlaufen weiterer interner Prozesse auch „live“ eingesetzt werden. All diese qualitäts- und testbezogenen Aufgaben in der CD-Pipeline erfordern ein gehöriges Investment in Qualität, zunächst im Aufbau und später auch im Tagesgeschäft. Über alle Stufen der Pipeline ist eine Qualitätsstrategie zu ziehen, so dass sichergestellt ist, dass alle relevanten Aspekte auch durch Analysen bzw. Tests in einer der Stufen abgedeckt sind. Nicht zu vergessen ist auch, dass in einem viel stärkeren Ausmaß automatisiert wird – dies bedeutet zwangsläufig, dass sich Aufwände vom manuellen Test hin zur Automatisierung und Wartung der Automationslösungen verschieben. Die Notwendigkeit der Automatisierung erfordert auch einen stärkeren Fokus auf Unterstützungsdisziplinen wie Testdaten- bzw. Umgebungsmanagement. Semiautomatische Lösungen und Workarounds sind nicht mehr gut genug – sie halten die Pipeline an, wie ein Fließband in einer Fahrzeugfertigung. Mehr Nachverfolgbarkeit und Transparenz Eine andere Organisationsform und eine automatisierte Deployment Pipeline sind das eine – die Anforderung an eine lückenlose Nachverfolgbarkeit der Zusammenhänge zwischen Artefakten ist das andere. In manchen Umfeldern wird es nur intern gefordert, in anderen ist es aufgrund regulatorischer Anforderungen (wie Safety) unabdingbar. Eine CD-Pipeline ist dabei ein weiterer Schritt in die richtige Richtung. Schließlich lässt sich für alles, das automatisiert in dieser Pipeline abläuft ein „Paper Trail“ aufzeichnen, so dass eine dichtere Nachverfolgbarkeit möglich wird. Die Pipeline alleine ist aber nur eine Lösungskomponente. Die Informationen müssen noch in einem ge-

meinsamen Modell zusammengeführt werden, welches es erlaubt, die Informationen nach verschiedenen Aspekten wie Artefakten, Betrachtungsgegenständen, Anforderungen, Qualitätseigenschaften, Prozessphasen oder Meilensteinen anzufragen. Da hierfür derzeit leider noch keine Out-of-the-box-Lösung verfügbar ist, können an dieser Stelle beträchtliche Aufwände bei der Integration und der Anpassung existierender Lösungen an die konkreten Anforderungen entstehen. Konzeptuell existieren allerdings tragfähige Modelle. Es ist aber noch notwendig, diese Modelle individuell in entsprechende Analyse- und Dashboardsysteme zu implementieren bzw. zu konfigurieren. Aufgrund des durch DevOps weiter steigenden Bedarfs, entwickelt sich hier aber gerade eine erhebliche Dynamik, so dass in naher Zukunft Lösungen der nächsten Generation mit erheblich geringeren Aufwänden angepasst und eingesetzt werden können. DevOps ist das Buzzword der Stunde – es kommt eine Reihe von Trends in der IT zusammen und entwickelt eine eigene Dynamik. Aus Qualitätssicht ergeben sich große Chancen, Vorgehen, Infrastruktur und Methodik so anzupassen, dass nicht nur die DevOpsTransition gelingt, sondern dass auch das Fundament für eine spürbar bessere Produktqualität gelegt wird. Ist der Schritt hin zu DevOps gelungen, bleibt nur mit Herbert Grönemeyer zu schließen – es „bleibt alles anders“!

Sven Euteneuer verantwortet bei SQS technische Beratungsund Testservices in der DACH-Region. In dieser Rolle unterstützt er Kunden von SQS dabei, nichtfachliche Qualität messbar und transparent zu machen und hilft Ihnen dabei, die nötigen Voraussetzungen für die erfolgreiche Nutzung von Ansätzen wie DevOps zu schaffen. Der Diplom-Informatiker ist seit über 20 Jahren im IT-Bereich tätig, zehn Jahre davon in der Softwareentwicklung. Danach implementierte er technische QS-Maßnahmen, nichtfachliche Tests und Lifecycle-Automationslösungen.


Im Gespräch

Ausgabe 42  |  März 2017

DevOps Eine Revolution im Kopf Mit DevOps soll ein lang schwelender Konflikt zwischen Software-Entwicklern und IT-Verantwortlichen endlich beigelegt werden. Die Befürworter des neuen Prozessverbesserungsansatzes versprechen sich davon kürzere Entwicklungszeiten, häufigere Releases und qualitativ höherwertige Software. Doch kann DevOps halten, was es verspricht? Wie sollte man in DevOps einsteigen und wo liegen die Stolpersteine? Das SQ-Magazin befragte dazu DevOps-Experte Uwe Friedrichsen.

SQ: Wie definieren Sie Dev­Ops gemäß Ihrer praktischen Erfahrungen? Uwe Friedrichsen: Hier ist zu unterscheiden, was ich in der Praxis in Unternehmen antreffe, die von sich sagen, dass sie „DevOps machen“ und, was DevOps wirklich ist. In Unternehmen und in Diskussionen sehe ich ein perfektes Durcheinander von Interpretationen, beginnend mit sinnvollen Ansätzen bis hin zu Skurrilitäten wie neu geschaffene Teams, die zwischen den unveränderten Entwicklungs- und Betriebsabteilungen vermitteln sollen; Managern, die gegenüber Entwicklern mit „You build it, you run it“ Drohkulissen aufzubauen versuchen; oder der Vorstellung, dass man mit DevOps keine Betriebsexperten mehr braucht, sondern alles zukünftig von den Entwicklern gemacht wird und man so die IT-Kosten kräftig senken kann.

SQ: Der Ansatz von Dev­Ops scheint also vielen noch nicht klar zu sein? Leider treffen die meisten Ansätze die Ideen von DevOps nicht wirklich, sondern sind entweder so abstrus wie zuvor skizziert, oder beschränken sich häufig im Kern auf das Einführen einer mehr oder weniger durchgängigen Continuous Delivery Pipeline (vereinfacht ausgedrückt eine Automatisierung von Build, Test und Deployment). Tatsächlich ist DevOps aber ein viel umfassenderes Konzept. Es ist sehr gut in dem Buch „The Phoenix Project“ [1] und als Referenz kurz in dem zugehörigen Blog Post [2] beschrieben. Im Kern geht es bei DevOps darum, die gesamte IT-Wertschöpfungskette kontinuierlich mit dem Ziel möglichst kurzer Durchlaufzeiten (Cycle Times) zu optimieren, das heißt salopp ausgedrückt: „Wie schnell kann ich eine Idee durch die IT-Wertschöpfungskette bringen, so dass der Kunde sie sieht und mir Feedback geben kann?“

SQ: Das ist ein fundamentaler Unterschied zu der Art und Weise, wie IT in der Vergangenheit optimiert worden ist. Seit der Software-Krise, die ihren Beginn in den späten Sechzigern des letzten Jahrhunderts hatte, hat man eigentlich immer nur versucht, kosteneffizient die Produktion von Soft-

14


15

Uwe Friedrichsen ist ein langjähriger Reisender in der IT-Welt. Als CTO der codecentric AG ist er stets auf der Suche nach innovativen Ideen und Konzepten. Er teilt und diskutiert seine Ideen regelmäßig auf Konferenzen, als Autor von Artikeln, Blog Posts, Tweets und im direkten Gespräch.

ware zu skalieren, also mehr Software für weniger Geld zu erstellen. Die Konzepte des Software Engineerings, die Aufteilung der IT-Wertschöpfungskette in „Arbeitsstationen“ (wie z.B. Anforderungserhebung, Architektur, Programmierung, Test und den ganzen Betriebsdisziplinen), welche durch ein virtuelles Fließband, nämlich den Software-Entwicklungsprozess miteinander verbunden sind – all das sind die Konzepte der industriellen Produktion, auf die Software-Entwicklung angewandt. Der Kerngedanke der industriellen Produktion ist Kosteneffizienz, denn je günstiger ich ein Teil produzieren kann, desto höher ist meine Marge. Allerdings setzt industrielle Produktion auch weite, träge Märkte voraus, in denen die Nachfrage deutlich höher ist als das Angebot, denn die Ko-

steneffizienz geht zu Lasten der Reaktionsgeschwindigkeit. Je optimaler sich ein Unternehmen hinsichtlich von Kosteneffizienz aufgestellt hat, desto langsamer kann es auf Veränderungen von außen reagieren. Das liegt an typischerweise großen Batches in der Produktion, um die Fixkostenanteile zu minimieren, langen, zentralisierten Entscheidungsketten und einer hochgradigen Spezialisierung in den einzelnen Arbeitsstationen, die über Prozesse und Artefakte verbunden sind, die detailliert im Vorfeld definiert worden sind. Das ist kein Problem, solange die Märkte träge sind, das heißt, die Hersteller aufgrund der überwiegenden Nachfrage die Veränderungsgeschwindigkeit selber definieren können. Kippt aber das Verhältnis von Angebot und Nachfrage, das heißt, das Angebot

übersteigt die Nachfrage deutlich, dann werden Märkte eng und dynamisch. Kunden kaufen nicht mehr dankbar das, was da ist, sondern das, was ihre persönlichen Bedürfnisse am besten trifft. Sie haben ja die Wahl. Damit bewegt sich der Markt sehr schnell und wird von denen getrieben, die sich am schnellsten auf die sich verändernden Bedürfnisse der Kunden einstellen können. In solchen sogenannten post-industriellen Märkten ist Kosteneffizienz nicht mehr der primäre Treiber für Optimierung, sondern Cycle Times, d.h. wie schnell man neue Ideen zu den Kunden bringen kann. Man muss sich so aufstellen, dass man sich so schnell wie möglich verändern kann und kontinuierlich an die Bedürfnisse der Kunden anpassen kann. Das beginnt damit, dass man die Entscheidungskompetenz dezentralisiert, das heißt, dahin delegiert, wo die Probleme sind, nämlich an den Grenzen zum Markt, also zu den Teams, die direkten Marktkontakt haben. Und man richtet auch alles andere konsequent darauf aus, so schnell wie möglich auf sich verändernde Marktbedürfnisse reagieren zu können.

SQ: Was hat das mit IT im Allgemeinen und DevOps im Speziellen zu tun? Nun, zweierlei. Zum einen hat sich die Rolle der IT seit den Anfangszeiten des Software Engineering massiv verändert. Hat IT damals noch einzelne Teilfunktionen des Business unterstützt, so ist IT heute das Nervensystem eines jeden nicht-trivialen Unternehmens. Die gesamte Business-DNA ist in IT kodiert. Es ist nicht mehr möglich, Geschäftsprozesse, Produkte oder auch nur Features zu ändern, ohne die IT anzufassen. Damit ist die


Im Gespräch

Durchlaufzeit einer Änderung durch die IT-Wertschöpfungskette zu einem begrenzenden Faktor für die mögliche Veränderungsgeschwindigkeit eines Unternehmens geworden. Zum anderen haben sich die Märkte stark verändert, in denen sich die meisten Unternehmen bewegen. Waren die Märkte in den Zeiten, in denen die Grundlagen des Software Engineerings gelegt wurden (und nach denen heute noch die meisten IT-Bereiche von Unternehmen handeln), in der Regel noch weit und träge, so sind sie heute fast überall durch Globalisierung, Internet-Handel und ähnliche Einflüsse eng und dynamisch. Wir müssen mit der IT also ganz andere Anforderungen erfüllen. Die vielbeschworene Digitalisierung treibt das auf die Spitze, denn Digitalisierung bedeutet vereinfacht „IT ist Business und Business ist IT“. IT ist also nicht mehr nur ein Unterstützer des Business im Hintergrund, sondern Teil der Produkte, die dem Kunden angeboten werden, steht also an „vorderster Front“ und unter ständiger Beobachtung des Marktes. DevOps ist letztlich nichts anderes als ein Ansatz, der diesen Veränderungstreibern Rechnung trägt, indem er Cycle Times und nicht Kosteneffizienz in den Fokus stellt, um so Unternehmen die erforderliche Veränderungs-

Ausgabe 42  |  März 2017

geschwindigkeit zumindest aus der IT heraus zu ermöglichen. (Natürlich reicht es nicht, wenn die IT schnell wird, wenn der Rest des Unternehmens sich nicht ebenfalls an die veränderten Marktbedingungen anpasst, aber das liegt außerhalb der Einflussbereiche von IT und DevOps.)

SQ: DevOps beinhaltet einerseits einen technologischen Aspekt, andererseits hat es etwas mit Unternehmenskultur zu tun. Inwiefern ist Kultur für DevOps wichtig und fördernd? Kultur ist wichtig für jede Art von Veränderung, denn Kultur ist im Prinzip nichts anderes als die Summe der vergangenen Erfolge und Misserfolge inklusive der zugehörigen Handlungsmuster, die in den Mitarbeitern eines Unternehmens und deren Beziehungen untereinander abgespeichert sind. Wann immer eine neue Aufgabe zu bewältigen ist, werden erfolgreiche Handlungsmuster aus der Vergangenheit angewendet, während in der Vergangenheit nicht erfolgreiche sowie unbekannte Handlungsmuster abgelehnt werden. Durch die wechselseitige Bestärkung

16

bezüglich erfolgreicher und Abschwächung nicht erfolgreicher Handlungsmuster entstehen Handlungsimperative, also „wie man Dinge macht“, ohne vorherige Analyse der Angemessenheit des Handlungsmusters für den konkreten Kontext. Der Satz „Das haben wir schon immer so gemacht“ ist im Prinzip die Essenz von Kultur. Man kann Kultur auch als einen adaptiven Reglungskreis verstehen, in dem die Vergangenheit die Gegenwart steuert und jeder neue Erfolg und Misserfolg die „Parameter“ des Regelkreises ein wenig verändert – aber halt auch nur ein wenig. Das muss man berücksichtigen, wann immer man Dinge verändern möchte. Kultur ist ein Trägheitsmoment aus der Vergangenheit, das Veränderungen entgegensteht. Erst indem man häufig genug Erfolge mit neuen, anderen Handlungsmustern wiederholt, diffundieren diese über die Zeit in die Kultur und können damit über die Zeit nachhaltig werden. Ein paar vereinzelte Leuchtturmerfolge gehen in dem großen kollektiven Gedächtnis der Kultur einfach unter. In diesen Fällen wird man bei neuen Herausforderungen wieder auf die kulturell verfestigten Handlungsmuster zurückgreifen, was diese weiter bestärkt und die wenigen neuen Er-


17

folge mit anderen Handlungsmustern vergessen macht. DevOps bedeutet letztlich eine „Revolution im Kopf“. Anstatt wie in den vergangenen 40+ Jahren üblich die IT vorrangig unter dem Aspekt Kosteneffizienz zu optimieren, wird bei DevOps die Reaktionsgeschwindigkeit in den Vordergrund gestellt. Damit sind alle in der Vergangenheit trainierten Handlungsmuster obsolet geworden oder müssen zumindest kritisch in Bezug auf die neue Optimierungsgröße hinterfragt werden. Aber genau diese obsoleten Handlungsmuster sind die Muster, die fest in der Kultur der Unternehmen gespeichert sind und sich mit all ihrer Kraft und Trägheit neuen Mustern entgegenstellen. Deshalb ist gerade bei einer so grundlegenden Veränderung der zugrundeliegenden Werte wie bei DevOps das Thema Kultur essentiell wichtig. Es zu ignorieren würde ein sicheres Scheitern jeder DevOps-Initiative bedeuten, denn Kultur fördert eine Veränderung wie DevOps – zumindest am Anfang – niemals, sondern wirkt ihr immer entgegen.

SQ: Sind DevOps ein Hype oder ein Ansatz mit Zukunft? Hier gilt es den Begriff DevOps und die damit verbundenen Ziele zu unterscheiden. Der Begriff DevOps ist derzeit ein Modebegriff. Viele Parteien schmücken ihre Angebote damit wie seinerzeit mit „agile“ oder „lean“ – häufig ohne, dass das Angebot irgendetwas mit den Zielen von DevOps zu tun hat. So gesehen kann es durchaus passieren, dass der Begriff DevOps irgendwann einmal verbrannt sein wird, weil zu viel Schindluder damit getrieben worden ist. Das wäre zwar schade, passiert aber leider regelmäßig in der IT. Auf der anderen Seite stehen die Ziele hinter DevOps, nämlich die kontinuierliche ganzheitliche Optimierung der

IT-Wertschöpfungskette mit dem Ziel, die Cycle Times zu reduzieren. Wenn man akzeptiert, dass post-industrielle Märkte und Digitalisierung nicht nur kurzfristige Hypes sind, sondern fundamentale Veränderungen in der Beziehung zwischen Marktteilnehmern und Unternehmen bedeuten, und wenn man außerdem akzeptiert, dass IT heute nicht mehr nur ein lästiges Cost Center, sondern ein existentieller Produktionsfaktor der meisten Unternehmen ist, dann ist DevOps nicht nur kein Hype, dann gibt es keine Alternative dazu, wenn man als Unternehmen mittelfristig überleben will. Natürlich gehört zum Überleben mehr als nur DevOps, aber das liegt, wie schon zuvor beschrieben, außerhalb des Wirkungsbereichs der IT.

SQ: Wie sollten Unternehmen in DevOps einsteigen? Zunächst sollte man überlegen, ob man DevOps überhaupt benötigt. Es passiert mir immer wieder, dass ich mit Leuten spreche, die DevOps einführen wollen und bei denen ich innerhalb weniger Minuten feststelle, dass es ihnen gar nicht um DevOps geht. Als Lackmustest verwende ich das „magische Dreieck“ bestehend aus den Begriffen „schnell“ (kurze Cycle Times), „billig“ (Kosteneffizienz) und „gut“ (Qualität) und bitte meine Gesprächspartner, die zwei Begriffe zu wählen, die ihnen am wichtigsten sind. Sehr häufig fällt die Wahl dann auf das Paar „billig & gut“, also industrielle Software-Produktion. Die betreffenden Personen versprechen sich in dem Fall von DevOps entweder direkte Kosteneinsparungen oder eine Erhöhung der Qualität, ohne von dem Primärziel der Kosteneinsparung abzurücken. Das kann DevOps aber nicht leisten, weil es ein ganz anderes Ziel hat. DevOps befindet sich auf der Kante „schnell & gut“ des Dreiecks,

also der postindustriellen SoftwareProduktion. Solange die führenden Entscheider nicht der Meinung sind, dass Reaktionsgeschwindigkeit für sie wichtiger ist als Kosteneffizienz, egal ob aus berechtigten Gründen oder Verharrungsreflexen, braucht man über DevOps nicht weiter nachzudenken. Ist diese Grundsatzfrage positiv beantwortet, muss man einen Weg finden, nicht direkt von der Kultur gefressen zu werden, denn wie zuvor beschrieben, steht die etablierte Unternehmenskultur einer Veränderung in Richtung DevOps üblicherweise entgegen. Ein guter erster Einstieg in Richtung DevOps ist aus meiner Erfahrung Continuous Delivery, also die Automatisierung von Build, Test und Deployment. Continuous Delivery eignet sich deshalb recht gut, weil es sowohl auf der Kante „billig & gut“ als auch auf der Kante „schnell & gut“ funktioniert. Man kann die Automatisierung nutzen, um Kosten zu sparen, ohne die Qualität zu kompromittieren; man kann sie aber auch nutzen, um die Cycle Times ohne Verlust von Qualität zu reduzieren. Und auch wenn sich die konkreten Implementierungen je nach gewähltem Ziel etwas unterscheiden werden, kann man so schon eine wichtige Grundvoraussetzung für DevOps implementieren und eine erste „Erfolgsgeschichte“ vorweisen, ohne direkt in den Kulturkampf gehen zu müssen.

SQ: Was ist ausschlaggebend für den Erfolg von DevOps? Was sind die Risiken, die ein Unternehmen beachten sollte? Im Prinzip sind die wichtigsten Erfolgsfaktoren bereits genannt worden: Revolution und Umsetzung. Bei der „Revolution im Kopf“ müssen sich alle Entscheider und Beteiligten einig sein, dass die Beschleunigung der IT-Wertschöpfungskette für den


Im Gespräch Unternehmenserfolg wichtiger ist, als Kosteneinsparungen um jeden Preis. Das zweite ist die „Evolution in der Umsetzung“. Um den „Kampf gegen die Kultur“ gewinnen zu können, darf man es nicht als Kampf ansehen, sondern muss es als eine lange und kontinuierliche Folge von Erfolgserlebnissen verstehen, die man dem Unternehmensgedächtnis hinzufügt, um darüber die Kultur sukzessiv zu verändern. Letzteres klingt einfacher, als es in der Praxis meistens ist. Gerade ein Thema wie DevOps, das im Kern eine radikale Veränderung der Denk- und Verhaltensweisen erfordert, fordert die Kultur eines Unternehmens sehr heraus. Versucht man zu viele Veränderungen auf einmal zu etablieren, wird die Kultur versuchen, sie zu bekämpfen, wie ein Immunsystem Fremdkörper in einem Organismus bekämpft. Deshalb ist es, wie zuvor beschrieben, sinnvoll, erste Erfolgserlebnisse (z.B. mit Continuous Delivery) zu realisieren, ohne die Abwehrkräfte herauszufordern.

Ausgabe 42  |  März 2017

barer Erfolge mit DevOps-Vorgehensweisen vorzuweisen haben. Einfach wird es aber trotzdem nicht werden. Man wird eine Menge Geduld, Beharrlichkeit und Geschick benötigen, um eine DevOps-Transition erfolgreich umzusetzen.

SQ: Was kann ein Unternehmen tun, um eine DevOpsKultur nachhaltig einzufühSQ: Welche weiteren Schrit- ren? te empfehlen Sie? Es kann helfen, geschützte Bereiche aufzubauen, in denen neue Ideen erprobt (und weitere Erfolgsgeschichten erzeugt) werden können, ohne, dass die geballte Kraft der Unternehmenskultur auf sie einwirkt. Das kann man auf zwei Arten machen. Entweder man trennt ein Team organisatorisch komplett vom Rest der Organisation (der „Lab“-Gedanken, den man derzeit in diversen Unternehmen beobachten kann) oder, man erklärt eine veränderte Vorgehensweise zu einem zeitlich beschränkten Versuch: „Lasst es uns für <Zeitraum X> einmal so versuchen. Wenn das nicht funktionieren sollte, dann können wir wieder zur alten Vorgehensweise zurückkehren.“ Irgendwann wird die Konfrontation mit den „alten Werten“ der Kultur unumgänglich sein. Bis dahin sollte man idealerweise schon eine Reihe sicht-

Die Antwort ist eigentlich schon in der Frage enthalten: Es ist notwendig, die Kultur des Unternehmens über eine Vielzahl von Erfolgen so zu verändern, dass die neuen DevOps-bezogenen Handlungsmuster die alten Handlungsmuster in der Kultur „überschreiben“. Erst wenn das gelungen ist, ist die Veränderung nachhaltig. Aber nochmals: Das klingt auf dem Papier deutlich einfacher, als es in der Praxis ist. Das theoretische Wissen darum, was Kultur ist und wie man sie beeinflussen kann, heißt noch lange nicht, dass sich dies in der Praxis einfach umsetzen ließe. Da gilt es wie bei jeder größeren Veränderung viele Widerstände zu überwinden, manche offen sichtbar, viele aber unsichtbar und nicht alle Angriffe auf die Veränderungsbemühungen werden fair verlaufen. Es hilft auch nicht, wenn man auf

18

der rationalen Ebene vermittelt bekommt, dass die Veränderung für das Überleben des Unternehmens (oder zumindest der IT-Abteilung) unumgänglich ist. Veränderungen lösen bei den meisten Menschen Ängste aus und diese sind irrational und tief im menschlichen Verhalten verankert. Solche Ängste erreicht man nicht mit rationalen Argumenten, sondern nur auf einer emotionalen Ebene. Deshalb empfehle ich als Laie in solchen Themengebieten auch geschützte Räume und wiederholte Erfolgserlebnisse. Aber am Ende des Tages bin ich Informatiker und kein Psychologe. Entsprechend bin ich auch kein Experte für Veränderungsprozesse und kann nur ein paar elementare Anregungen zu dem Thema anbieten. Wenn Sie DevOps also nachhaltig in Ihrem Unternehmen einführen wollen, wäre meine abschließende Empfehlung, dass Sie für so ein Vorhaben nicht nur einen DevOps-Experten an Bord haben, sondern mindestens auch einen Veränderungsexperten. Die Fragen stellten Christin Senftleben und Anja Schreinert.

REFERENZEN [1] Gene Kim, Kevin Behr, George Spafford, „The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win“, It Revolution Press, 2014 [2] „The Three Ways: The Principles Underpinning DevOps“, siehe http://itrevolution.com/thethree-ways-principles-underpinning-devops/


der Hef tmitt

e heraus tren

April - Juni 2017 Certified-Schulungen werden ausschließlich von akkreditierten Unternehmen durchgeführt. Das iSQI fungiert hier als Vermittler. Anmeldeformular und Preise unter www.isqi.org. Ort

nen

Mehr als 100 weitere Termine finden Sie unter: www.isqi.org/de/seminare.html Datum (Start)

Tage

Anbieter

München Berlin Stuttgart Berlin Wien Frankfurt Braunschweig Berlin Hamburg Bremen Braunschweig Hamburg München Frankfurt am Main Frankfurt Köln Braunschweig

CMAP Mobile App Testing 03.04.17 2 Sogeti Deutschland GmbH 03.04.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH 08.05.17 2 Sogeti Deutschland GmbH 08.05.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH 04.04.17 2 ANECON 10.04.17 2 CGI Deutschland Ltd. & Co. KG 27.04.17 2 BREDEX GmbH 18.05.17 2 Loyal Team GmbH 18.05.17 2 Loyal Team GmbH 18.05.17 2 Loyal Team GmbH 22.05.17 2 BREDEX GmbH 01.06.17 2 SQS 08.06.17 2 CGI Deutschland Ltd. & Co. KG 19.06.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH 26.06.17 2 Loyal Team GmbH 26.06.17 2 Loyal Team GmbH 26.06.17 2 BREDEX GmbH

Berlin (in Englisch) München Stuttgart Stuttgart Berlin Frankfurt

CMAP Mobile App Test Automation 05.04.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH 05.04.17 3 Sogeti Deutschland GmbH 10.05.17 3 Sogeti Deutschland GmbH 10.05.17 3 CGI Deutschland Ltd. & Co. KG 10.05.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH 21.06.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH

Berlin (in Englisch) Berlin (in Englisch) Stuttgart

iSQI ® Certified Agile Business Analysis 12.04.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH 15.06.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH 28.06.17 2 Sogeti Deutschland GmbH

Berlin (in Englisch) Frankfurt Köln München München Hamburg Stuttgart Stuttgart Hamburg Berlin Berlin (in Englisch) Düsseldorf Frankfurt

iSQI ® Certified Agile Essentials 10.04.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH 11.04.17 2 Loyal Team GmbH 11.04.17 2 Loyal Team GmbH 02.05.17 2 Sogeti Deutschland GmbH 02.05.17 2 Loyal Team GmbH 04.05.17 2 Sogeti Deutschland GmbH 04.05.17 2 Loyal Team GmbH 04.05.17 2 Loyal Team GmbH 15.05.17 2 Loyal Team GmbH 15.05.17 2 Loyal Team GmbH 22.05.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH 06.06.17 2 Sogeti Deutschland GmbH 29.06.17 2 Loyal Team GmbH

Hannover Offenbach Stuttgart Köln Hamburg Düsseldorf Berlin Berlin Köln München München Wien München Stuttgart

iSQI's CAT Certified Agile Tester 03.04.17 5 Díaz & Hilterscheid Unternehmensberatung GmbH 24.04.17 5 Sogeti Deutschland GmbH 29.05.17 5 Sogeti Deutschland GmbH 24.04.17 5 SQS 10.05.17 5 Loyal Team GmbH 15.05.17 5 Integrata / CGI Deutschland Ltd. & Co. KG 15.05.17 5 Díaz & Hilterscheid Unternehmensberatung GmbH 17.05.17 5 Loyal Team GmbH 17.05.17 5 Loyal Team GmbH 29.05.17 5 Method Park Consulting GmbH 19.06.17 5 Integrata / CGI Deutschland Ltd. & Co. KG 19.06.17 5 ANECON 21.06.17 5 Loyal Team GmbH 21.06.17 5 Loyal Team GmbH

STAND: Februar 2017

Schulungen 2017

Term ine to go

einfach aus


Wien Stuttgart Wien Bremen München Erlangen Dresden Berlin München Hamburg Hamburg Hamburg Münster Berlin Frankfurt Frankfurt Berlin Hamburg Frankfurt München Köln Münster Braunschweig Stuttgart Ingolstadt Berlin München Berlin München Wiesbaden Wiesbaden Berlin Wien Braunschweig Nürnberg München Offenbach Düsseldorf Berlin (in Englisch) Köln/Düsseldorf Stuttgart Düsseldorf Berlin Hamburg München Bielefeld Wien Hamburg Wien Frankfurt Köln München Hamburg Berlin Dortmund

iSQI´s Certified Agile Test Driven Development 08.05.17 3 ANECON ISTQB ® Certified Tester – Foundation Level 04.04.17 4 abilex GmbH 07.03.17 4 OBJENTIS Software Integration GmbH 03.04.17 3 Loyal Team GmbH 03.04.17 4 ISARTAL akademie GmbH 03.04.17 4 Method Park Consulting GmbH 03.04.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH 07.04.17 4 CGI Deutschland Ltd. & Co. KG 08.04.17 4 Sogeti Deutschland GmbH 10.04.17 4 Sogeti Deutschland GmbH 10.04.17 4 SQS 10.04.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH 18.04.17 4 CGI Deutschland Ltd. & Co. KG 19.04.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH 24.04.17 4 SQS 24.04.17 4 Díaz & Hilterscheid Unternehmensberatung GmbH 26.04.17 3 Loyal Team GmbH 26.04.17 3 Loyal Team GmbH 02.05.17 4 CGI Deutschland Ltd. & Co. KG 02.05.17 4 ISARTAL akademie GmbH 08.05.17 4 SQS 08.05.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH 09.05.17 4 Muth Partners GmbH 10.05.17 3 Loyal Team GmbH 10.05.17 3 sepp.med GmbH 15.05.17 4 Loyal Team GmbH 15.05.17 3 Philotech Academy 15.05.17 4 Díaz & Hilterscheid Unternehmensberatung GmbH 16.05.17 4 CGI Deutschland Ltd. & Co. KG 16.05.17 4 Muth Partners GmbH 16.05.17 4 Muth Partners GmbH 22.05.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH 29.05.17 4 ANECON 29.05.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH 30.05.17 4 CGI Deutschland Ltd. & Co. KG 30.05.17 4 ISARTAL akademie GmbH 06.06.17 4 Sogeti Deutschland GmbH 06.06.17 4 CGI Deutschland Ltd. & Co. KG 06.06.17 4 Díaz & Hilterscheid Unternehmensberatung GmbH 12.06.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH 16.06.17 4 Freitage abilex GmbH 19.06.17 4 Sogeti Deutschland GmbH 19.06.17 3 Loyal Team GmbH 19.06.17 3 Loyal Team GmbH 19.06.17 4 SQS 19.06.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH 20.06.17 4 OBJENTIS Software Integration GmbH 20.06.17 4 CGI Deutschland Ltd. & Co. KG 20.06.17 4 OBJENTIS Software Integration GmbH 26.06.17 3 Loyal Team GmbH 26.06.17 3 Loyal Team GmbH 26.06.17 4 ISARTAL akademie GmbH 26.06.17 4 Díaz & Hilterscheid Unternehmensberatung GmbH 03.07.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH 05.07.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH

Dresden Offenbach Münster Stuttgart München München Frankfurt Berlin Köln München München Stuttgart Bielefeld München

ISTQB ® Certified Tester – Foundation Level Extension, Agile Tester 06.04.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH 02.05.17 2 Sogeti Deutschland GmbH 11.05.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH 26.06.17 2 Sogeti Deutschland GmbH 03.04.17 2 Loyal Team GmbH 06.04.17 2 SQS 27.04.17 2 CGI Deutschland Ltd. & Co. KG 29.05.17 2 Loyal Team GmbH 01.06.17 2 SQS 12.06.17 2 Loyal Team GmbH 12.06.17 2 CGI Deutschland Ltd. & Co. KG 22.06.17 2 Loyal Team GmbH 22.06.17 2 Díaz & Hilterscheid Unternehmensberatung GmbH 26.06.17 2 Method Park Consulting GmbH

Düsseldorf Berlin Köln Berlin München Stuttgart

ISTQB ® Certified Tester – Advanced Level, Test Manager 24.04.17 5 Sogeti Deutschland GmbH 24.04.17 5 CGI Deutschland Ltd. & Co. KG 24.04.17 5 SQS 24.04.17 5 Díaz & Hilterscheid Unternehmensberatung GmbH 03.05.17 5 Loyal Team GmbH 03.05.17 5 Loyal Team GmbH


Hamburg Hamburg München Stuttgart Stuttgart Berlin (in Englisch) München Berlin Hamburg Berlin Erlangen Frankfurt Köln/Düsseldorf

15.05.17 15.05.17 17.05.17 29.05.17 29.05.17 29.05.17 19.06.17 19.06.17 19.06.17 19.06.17 26.06.17 26.06.17 26.06.17

5 5 6 5 5 5 5 5 5 5 5 5 5

Sogeti Deutschland GmbH SQS ISARTAL akademie GmbH Sogeti Deutschland GmbH CGI Deutschland Ltd. & Co. KG Díaz & Hilterscheid Unternehmensberatung GmbH Sogeti Deutschland GmbH Loyal Team GmbH Loyal Team GmbH SQS Method Park Consulting GmbH SQS Díaz & Hilterscheid Unternehmensberatung GmbH

Köln Frankfurt am Main Berlin Frankfurt Köln Hamburg Frankfurt München Frankfurt Bremen Wien Düsseldorf München Berlin (in Englisch) Köln

ISTQB ® Certified Tester – Advanced Level, Test Analyst 03.04.17 4 SQS 02.05.17 4 Díaz & Hilterscheid Unternehmensberatung GmbH 24.04.17 4 Loyal Team GmbH 24.04.17 4 Loyal Team GmbH 24.04.17 4 Loyal Team GmbH 24.04.17 4 Loyal Team GmbH 24.04.17 4 CGI Deutschland Ltd. & Co. KG 24.04.17 4 SQS 02.05.17 4 SQS 15.05.17 4 Loyal Team GmbH 15.05.17 5 ANECON 19.06.17 4 CGI Deutschland Ltd. & Co. KG 19.06.17 5 Method Park Consulting GmbH 19.06.17 4 Díaz & Hilterscheid Unternehmensberatung GmbH 26.06.17 4 SQS

Berlin (in Englisch) Berlin Hamburg Wien München Stuttgart Köln Hamburg München Köln Stuttgart

ISTQB ® Certified Tester – Advanced Level, Technical Test Analyst 19.04.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH 24.04.17 3 Loyal Team GmbH 24.04.17 3 Loyal Team GmbH 26.04.17 3 ANECON 15.05.17 3 Loyal Team GmbH 15.05.17 3 Loyal Team GmbH 15.05.17 3 CGI Deutschland Ltd. & Co. KG 29.05.17 3 SQS 07.06.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH 19.06.17 3 SQS 21.06.17 3 CGI Deutschland Ltd. & Co. KG

München Röttenbach München Stuttgart München Berlin Nürnberg Düsseldorf Berlin Nürnberg München Berlin Frankfurt Köln Erlangen Köln Berlin Hamburg Frankfurt Stuttgart Berlin Berlin München Wien München Stuttgart München Frankfurt Frankfurt Köln Berlin Hamburg Köln Stuttgart

ISTQB ® Certified Tester – Foundation Level Extension, Model-Based Tester 08.05.17 2 CGI Deutschland Ltd. & Co. KG 17.05.17 2 sepp.med GmbH IREB ® Certified Professional for Requirements Engineering – Foundation Level 03.04.17 3 Loyal Team GmbH 03.04.17 3 Loyal Team GmbH 03.04.17 3 SQS 03.04.17 3 microTOOL GmbH 10.04.17 3 SOPHIST GmbH 26.04.17 3 SOPHIST GmbH 03.05.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH 08.05.17 3 SOPHIST GmbH 08.05.17 3 ISARTAL akademie GmbH 08.05.17 3 microTOOL GmbH 17.05.17 3 Loyal Team GmbH 17.05.17 3 Loyal Team GmbH 22.05.17 3 Methdo Park Consulting GmbH 22.05.17 3 SQS 29.05.17 3 Loyal Team GmbH 29.05.17 3 Loyal Team GmbH 07.06.17 3 SOPHIST GmbH 07.06.17 3 Methdo Park Consulting GmbH 12.06.17 3 Díaz & Hilterscheid Unternehmensberatung GmbH 14.06.17 3 microTOOL GmbH 19.06.17 3 ISARTAL akademie GmbH 28.06.17 3 ANECON

IREB® Certified Professional for Requirements Engineering – Advanced Level, Requirements Elicitation and Consolidation 03.04.17 3 Loyal Team GmbH 03.04.17 3 Loyal Team GmbH 24.04.17 3 SOPHIST GmbH 03.05.17 3 SOPHIST GmbH 17.05.17 3 Loyal Team GmbH 17.05.17 3 Loyal Team GmbH 29.05.17 3 Loyal Team GmbH 29.05.17 3 Loyal Team GmbH 12.06.17 3 SQS 28.06.17 3 SOPHIST GmbH


München Stuttgart München Erlangen Frankfurt Köln Frankfurt Berlin Hamburg Nürnberg

IREB ® Certified Professional for Requirements Engineering – Advanced Level, Requirements Modeling 03.04.17 3 Loyal Team GmbH 03.04.17 3 Loyal Team GmbH 05.04.17 3 SOPHIST GmbH 24.04.17 3 Methdo Park Consulting GmbH 17.05.17 3 Loyal Team GmbH 17.05.17 3 Loyal Team GmbH 22.05.17 3 SOPHIST GmbH 29.05.17 3 Loyal Team GmbH 29.05.17 3 Loyal Team GmbH 26.06.17 3 SOPHIST GmbH

Berlin München Köln

UXQB ® Certified Professional for Usability and User Experience, Foundation Level 20.04.17 2 CGI Deutschland Ltd. & Co. KG 01.06.17 2 CGI Deutschland Ltd. & Co. KG 26.06.17 3 ProContext Consulting GmbH

Frankfurt München Nürnberg

Certified Professional for Requirements Engineering Foundation Level - Blended Learning 24.04.17 2 SOPHIST GmbH 22.05.17 2 SOPHIST GmbH 19.06.17 2 SOPHIST GmbH

AGILE

REQUIREMENTS ENGINEERING

SECURIT Y

MOBILE

SOF T WA RE TESTING

PROJECT MANAGEMENT

USABILITY

SPECIALISED

PRODUCT MANAGER

MEDICAL

WEITERE ANGEBOTE

Seminare 2017 April - Juni 2017

Mehr als 100 weitere Termine finden Sie unter: www.isqi.org/de/seminare.html

Seminartitel

Ort

Anforderungen mit Prosa und Modellen clever erheben und dokumentieren"

München

03.04.17

2

SOPHIST GmbH

Agiles RE - Vom Stakeholder zum Backlog

Frankfurt

20.04.17

2

SOPHIST GmbH

Train-the-Trainer

München

24.04.17

3

ISARTAL akademie GmbH

Erfolgreich im Reviewteam mitarbeiten - Präsenz-Workshop

Kirchheimbolanden

28.04.17

1

Maud Schlich, THE QUALITEERS

Doku Agil - Fachliches Wissen in agilen Projekten dokumentieren

München

02.05.17

2

SOPHIST GmbH

Reviews effizient moderieren - Präsenz-Workshop

Kirchheimbolanden

05.05.17

2

Maud Schlich, THE QUALITEERS

Einführung in die Funktionale Sicherheit (Automotive - ISO 26262) (deutschsprachig)

Kornwestheim

08.05.17

2

KUGLER MAAG CIE GmbH

Agiles RE - Vom Stakeholder zum Backlog

Nürnberg

11.05.17

2

SOPHIST GmbH

Agile in Automotive (deutschsprachig)

Kornwestheim

12.05.17

1

KUGLER MAAG CIE GmbH

Automotive SPICE ® - iNTACS™ certified Provisional Assessor (deutschsprachig)

Kornwestheim

15.05.17

5

KUGLER MAAG CIE GmbH

TTCN-3 Training "Theory and Practice of TTCN-3"

Berlin

15.05.17

3

Spirent Technologies GmbH

GTB ® Certified Automotive Softwaretester

München

15.05.17

2

ISARTAL akademie GmbH

"Requirements-Engineering in der Praxis: Anforderungen mit Prosa und Modellen clever erheben und dokumentieren"

Düsseldorf

16.05.17

2

SOPHIST GmbH

"Business Analyse - Wie Sie Geschäftsprozesse für alle Beteiligten besser abbilden"

Nürnberg

22.05.17

2

SOPHIST GmbH

Praxistaugliche Testkonzepte optimal erstellen und nutzen

Datum(Start)

02.06.17

360° Testautomatisierung

Wien

"Requirements-Engineering in der Praxis: Anforderungen mit Prosa und Modellen clever erheben und dokumentieren" Agiles RE - Vom Stakeholder zum Backlog

Tage Anbieter

5 LiveMaud Schlich, THE QUALITEERS Sessions

07.06.17

2

ANECON

Frankfurt

19.06.17

2

SOPHIST GmbH

Düsseldorf

20.06.17

2

SOPHIST GmbH

Qualitätsmetriken für Anforderungsspezifikationen: Von der Spezifikation zur Kennzahl

Nürnberg

23.06.17

1

SOPHIST GmbH

Automotive SPICE ® - iNTACS™ zertifizierter Provisional Assessor (englischsprachig)

Kornwestheim

26.06.17

5

KUGLER MAAG CIE GmbH

Doku Agil - Fachliches Wissen in agilen Projekten dokumentieren

Nürnberg

29.06.17

2

SOPHIST GmbH

Zusätzliche Schulungs- und Seminartermine finden Sie auf www.isqi.org! Irrtümer, Termin- und Preisänderungen vorbehalten. Es gelten die allgemeinen Geschäfts- und Preisbedingungen des jeweiligen Veranstalters.

Friedrich-Engels-Straße 24 14473 Potsdam Tel.: + 49 331 231810-0 Fax: + 49 331 231810-10

Ansprechpartner: Caroline Ladek Examination and Organization +49 331 231810-33 trainings@isqi.org

Mandy Krause Examination and Evaluation +49 331 231810-28 trainings@isqi.org

Alle Themen auch als Inhouse-Angebot buchbar!

SIE WOLLEN IHR SEMINAR AUCH IM NÄCHSTEN SQ-MAGAZIN BEWERBEN? Wir freuen uns über eine Nachricht. Bitte senden Sie uns Ihre Termine per E-Mail zu: trainings@isqi.org

STAND: Februar 2017

Das iSQI fungiert hier als Vermittler. Ausführliche Seminarbeschreibungen, Preise und Anmeldeformular: www.isqi.org


Das ASQF-Karriereportal Wir haben den passenden Job für Sie!

IT-Systemadministrator (w/m)

Testmanager (m/w)

Testspezialist (w/m)

ASTRUM IT GmbH Erlangen

netcare Business Solutions GmbH Frankfurt oder Neustetten bei Stuttgart

G. Muth Partners GmbH Wiesbaden

Senior IT Enterprise Architect (m/w)

IT & Process Support Specialist (m/w)

VON ESSEN GmbH & Co. KG Bankgesellschaf Essen

netcare Business Solutions GmbH Neustetten

Softwaretester/ Mitarbeiter IT Qualitätssicherung (w/m)

Consultant: Software Tester / Testautomatisierung (m/w)

Senior Software Quality Engineer (m/w)

Qytera Software Testing Solutions GmbH Eschborn

TecAlliance GmbH München, Weikersheim oder Köln

Software Tester – Quality Assurance

Technical Software Tester (m/w) Testautomatisierung & Last- und Performance Tests

beQualified GmbH Köln

netcare Business Solutions GmbH Frankfurt a.M., Stuttgart

Junior / Senior Softwaretester (m/w)

(Senior) Testmanager/-in (m/w)

OMNINET GmbH Eckental

ckc group Braunschweig

Webentwickler C# / ASP.NET (m/w)

Requirements Engineer/ Business Architekt (m/w) im Gesundheitswesen

iucon GmbH Anwendungsentwicklung & Webentwicklung Berlin

azh Abrechnungs- und IT-Dienstleistungszentrum für Heilberufe GmbH Aschheim bei München

affilinet GmbH Hannover

SOFTWARE TESTER (M/W) Panasonic AVC Langen Langen

Senior IT Enterprise Architect (m/w) VON ESSEN GmbH & Co. KG Bankgesellschaf Essen

Consultant: Software Tester – Testmanagement / Software Testmanager (m/w) Qytera Überall

Hier könnte Ihre Anzeige stehen!

Schreiben Sie uns unter info@asqf.de

Die ausführlichen Stellenangebote finden Sie auf www.asqf.de/karriereportal


Titelthema

Ausgabe 42  |  März 2017

DEVOPS

EIN GESCHENK FÜR SOFTWARE-PRODUKTMANAGER?

24


25

D

as Ziel von DevOps ist die Verkürzung der Durchlaufzeiten vom Abschluss einer Code-Änderung bis zur Kundenverfügbarkeit. Für SoftwareProduktmanager bietet das viele Vorteile: Sie können schnell auf aktuelle Entwicklungen reagieren, die Produkte zügiger optimieren und Flexibilität gewinnen. Oft steigert DevOps die Produktivität und schafft mehr Kapazität für Innovation und Verbesserung. DevOps birgt für Software-Produktmanager aber auch Herausforderungen, insbesondere bei der Release-Planung und der Vermittlung des Kundennutzens.

WELCHE NEUERUNGEN BRINGT DEVOPS AUS PRODUKTMANAGEMENT-SICHT? In der Entwicklung setzt DevOps ein hochgradig iteratives Vorgehen voraus, in der Regel mit agilen Methoden. Für Software-Produktmanager ändern sich mit der Einführung von DevOps vor allem das Herangehen an die Planung, die Planungszyklen werden kürzer, und die Zusammenarbeit mit den Entwicklungsteams muss neu gestaltet werden. Auf der technischen Seite erfordert DevOps die Automatisierung der Integrations-, Test- und Delivery-Prozesse. Die sofortige Bereitstellung aktualisierter Produktversionen für den Kunden ist möglich aber nicht zwingend. DevOps kann daher nicht nur für web-basierte Dienste eingesetzt werden, sondern auch für On-Premise-Produkte und Software-intensive Systeme. Ein ausführlich dokumentiertes Beispiel für Software-intensive Systeme ist die gemeinsame Firmware für HP’s Enterprise LaserJet-Drucker [1] [2]. Dort erfolgt das Deployment in größeren Zeitintervallen.

DEVOPS-VORTEILE FÜR PRODUKTMANAGER DevOps bietet viele Vorteile für Software-Produktmanager. So bezeichnet Suzie Prince in einem Blog-Artikel Continuous Delivery und Dev­Ops als die besten Freunde des Produktmanagers [3]. Zwei Effekte von DevOps sind dafür besonders verantwortlich: Effizienzgewinne durch Automatisierung und verkürzte Durchlaufzeiten. Die Automatisierung, etwa durch Continuous Integration und Testing, senkt den Aufwand für die Entwicklungsteams. So kann die Organisation bei gleichem Budget bzw. bei gleichbleibenden Teamstärken mehr Kapazität in kundenrelevante Themen investieren: Innovation, neue Features oder Qualitätsverbesserung.

HP’s LaserJet Firmware-Entwicklung hatte in einer global verteilten Organisation mit über 400 Entwicklerinnen und Entwicklern nur etwa fünf Prozent der Bandbreite für Neuentwicklungen zur Verfügung − zu wenig, um dauerhaft in einem sehr wettbewerbsintensiven Markt zu bestehen. Durch DevOps stieg die für Innovationen verfügbare Kapazität auf 40 Prozent. Die Produktmanager erhielten wesentlich mehr Gestaltungsfreiheit zur Weiterentwicklung der Produkte. Die Verkürzung der Durchlaufzeiten bringt Änderungsanfragen ebenso wie neue Features wesentlich schneller zu den Kunden. Bei HP sank mit DevOps die Zeit vom Einchecken einer CodeÄnderung bis zum getesteten Software-Paket enorm: von mehr als sechs Wochen auf wenig mehr als einen Tag. Produktmanager können dadurch wesentlich schneller auf Probleme reagieren, etwa bei Kunden-Eskalationen, die Funktionalitätsänderungen erfordern. Es ist klar, dass die Zufriedenheit der Kunden steigt, wenn man schnelle Lieferung zusagen kann. Nicht zuletzt profitiert die Qualität des Produkts. Gerade bei Sicherheitslücken ist eine schnelle Lösung enorm wichtig. Aber nicht nur die Reaktion auf Probleme gewinnt. Das Produkt kann auch schneller proaktiv weiterentwickelt werden. Ein Beispiel ist die Adaptive Maintenance, die ein Produkt an veränderte Umgebungsbedingungen anpasst, etwa an eine neue Betriebssystemversion. Mit DevOps können solche Anpassungen schneller und früher auf den Markt gelangen. Das Gleiche gilt für die Umsetzung neuer Erkenntnisse, die Produktmanager beispielsweise aus A/B-Tests, aus Kunden-Feedback oder aus der Markt- und Wettbewerbsanalyse beziehen. Verallgemeinert gilt: Die Verkürzung der Durchlaufzeiten ermöglicht schnellere Feedback-Schleifen, die auch bei konstantem Entwicklungsaufwand eine gezieltere Ausrichtung des Produkts auf Markterfordernisse erlauben.

HERAUSFORDERUNGEN FÜR PRODUKTMANAGER DevOps konfrontiert das Produktmanagement auch mit neuen Herausforderungen: So müssen die Produktmanager dafür sorgen, dass die Entwicklung wirklich den geschäftlichen und strategischen Zielen folgt. Denn die DevOps-Konzepte fokussieren stark auf die internen Abläufe von Entwicklung und Betrieb. Beispielsweise fördert DevOps die Verlagerung von Entscheidungen in die Entwicklung, als ein


Titelthema

Barbara Hoisl

Dr. Andreas Birk

Ausgabe 42  |  März 2017

Mittel zur Beschleunigung der Durchlaufzeiten. Damit entsteht jedoch die Gefahr, dass Entwicklung und Betrieb sich von geschäftlichen und strategischen Zielen abkoppeln. Produktmanager müssen hier gegensteuern. Eine zweite Herausforderung für Produktmanager schafft DevOps durch das kontinuierliche Deployment. Aus Sicht von Kunden und Benutzern kann das zu einem unstrukturierten Strom von Aktualisierungen führen, in dem das Profil der Software verschwimmt: Kleine Änderungen stören etablierte Benutzungsprozesse, wichtige Neuerungen gehen unter und erzielen nicht die gewünschte Aufmerksamkeit im Markt. Auch hier muss das Produktmanagement eingreifen.

NEUE AUFGABENSCHWERPUNKTE FÜR PRODUKTMANAGER

Gerald Heller

Die Autoren sind Partner bei pd7.group (http://pd7.group), einem Netzwerk von Experten aus dem SoftwareProduktmanagement. Gerald Heller ist Gründungsmitglied und Board-Member der International Software Product Management Association (ISPMA, http://ispma.org), Barbara Hoisl ist ISPMA Fellow.

Wie kann das Produktmanagement mit den neuen Herausforderungen im DevOps-Kontext umgehen? Als Erstes muss es sich überhaupt ins Spiel bringen und die Kommunikation mit den Entwicklungsteams neu justieren. Diese sollen eigenständig arbeiten können, etwa bei dringenden Fehlerbehebungen. Die Entwickler müssen aber auch wissen, wann sie die Abstimmung mit den Produktmanagern suchen sollen. Für die Weiterentwicklung des Produktes muss das Produktmanagement Orientierung und Vorgaben bieten. Das beginnt mit Vision, Produktdefinition und Produktpositionierung. Bei DevOps sind Release-Planung und Roadmaps besonders wichtig, um die richtigen Prioritäten in der Entwicklung sicher zu stellen.

Bei DevOps sind ReleasePlanung und Roadmaps besonders wichtig, um die richtigen Prioritäten in der Entwicklung sicher zu stellen. Die Release-Planung muss dafür sorgen, dass Kunden wichtige Neuerungen im Produkt gut wahrnehmen. Die hohe Aktualisierungsrate im Continuous Deployment bewirkt zunächst häufige Releases mit vielen kleine Änderungen. Für wichtige Neuerungen müssen Produktmanager die nötigen Features passend gruppiert in die Entwicklung einbringen. Mit Marketing und Vertrieb, sowie bei der Kommunikation mit Analysten müssen sie betreffende Releases besonders ankündigen. Gegenüber der Entwicklung werden die Release-Inhalte vor allem über Roadmaps mit definierten Schwerpunktthemen vermittelt. Eine Umfrage unter erfahrenen Produktmanagern hat ergeben, dass Roadmaps in DevOps als Rahmen formuliert werden sollten, in dem die Entwicklungsteams Details eigenständig gestalten können [4]. Wenn Produktmanager diese Herausforderungen meistern, dann ist Dev­Ops wirklich ein Geschenk für sie: Sie erweitern ihren Gestaltungsspielraum und erhalten damit beste Voraussetzungen für ein erfolgreiches Produkt.

REFERENZEN [1] G. Kim: The Amazing DevOps Transformation of the HP LaserJet Firmware Team (Gary Gruver); DevOps Blog, IT Revolution Press. (http://itrevolution.com/the-amazing-devops-transformation-ofthe-hp-laserjet-firmware-team-gary-gruver/) [2] G. Gruver, M. Young, P. Fulghum: A Practical Approach to Large-Scale Agile Development - How HP Transformed LaserJet FutureSmart Firmware; Addison-Wesley, 2012. [3] S. Prince: Why Continuous Delivery And DevOps Are Product Managers’ Best Friends; MindTheProduct Blog, July 2016. (http://www.mindtheproduct.com/2016/07/continuous-delivery-devops-product-managers-new-bff/) [4] G. Heller: DevOps Release Planning; pd7.group Blog, February 2017. (http://pd7.group/2017/devops-release-planning)

26


27

Im Fokus DevOps & Co. JA, NATÜRLICH! WEIL …

IST DAS WIRKLICH SO EINFACH? KANN DAS FUNKTIONIEREN?

9 783864 903762

Wie können wir agiles Arbeiten in großen, komplexen Organisationen skalieren? Eine Frage, die sich vielen Unternehmen stellt. Mit Large-Scale Scrum (LeSS) liegen nun zwei Frameworks (LeSS und LeSS Huge) vor, mittels derer Scrum konsequent ohne viel Zusatz skaliert werden kann, um als Unternehmen agil und überlebensfähig zu sein.

SOFTWARE QUALITY DAYS 2017 IN WIEN In diesem Buch haben Craig Larman und Bas Vodde ihre Erkenntnisse aus mehr als einem Jahrzehnt an Erfahrung in der Einführung von LeSS in groß angelegten Umgebungen gebündelt. Es sind konkrete Wegweiser entstanden, die dabei helfen, mehr Flexibilität durch weniger Komplexität, mehr Wert durch weniger Verschwendung und mehr Sinnhaftigkeit durch weniger Vorschriften im Unternehmen zu verankern. Es werden u.a. folgende Themen adressiert:

• Implementierung von LeSS für die Entwicklung in großen Umgebungen • Auswahl der richtigen Umsetzungsstrategie und des Organisationsdesigns • Ausrichtung und Strukturierung einer großen Entwicklungsorganisation hin zum Kundennutzen • Klärung der Rolle des Managements, des Product Owners und des Scrum Masters • Skalierung von Produktdefinition, Anforderungen, Planung und Produktmanagement • Synchrones Arbeiten mit mehreren FeatureTeams • Koordination und Integration zwischen den Teams • Integration von Scrum in Multisite- und Offshore-Projekten • Skalierung von Design und Architektur

Thema • Skalierung • Produktentwicklung • Softwareentwicklung • Agile Methoden • Projektmanagement Leser • Führungskräfte • Product Owner und Produktmanager • Scrum Master • Organisations- und Team-Coaches • Softwareentwickler • Projektmanager

Larman . Vodde

Large-Scale Scrum

Large-Scale Scrum

Craig Larman . Bas Vodde

C. Larman · B. Vodde Craig Larman . Bas Vodde

Large-Scale Scrum More with LeSS

Scrum erfolgreich skalieren mit LeSS → Aus

dem Englischen übersetzt von Björn Jensen und Alexander Marquart

→ Mit

einem Geleitwort von Stephen Denning YES, OF COURSE! BECAUSE...

Large-Scale Scrum Scrum erfolgreich skalieren mit LeSS 2017, 396 Seiten € 34,90 (D) ISBN 978-3-86490-376-2

€ 34,90 (D)

ISBN 978-3-86490-376-2

www.dpunkt.de

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

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. Auflage 2017, 270 Seiten € 34,90 (D) ISBN 978-3-86490-414-1

E. Wolff

Zum Jahresbeginn drehte sich auf den Software Quality Days in Wien alles um das Schwerpunktthema „Quality of Things: Complexity and Challenges of Software Engineering in Emerging Technologies“. Rund 380 Teilnehmer aus über 20 Ländern nutzten auch in diesem Jahr das Event als Plattform für Informationsaustausch, Interaktion und Networking. Die Teilnehmer bildeten eine gute Mischung aus Wirtschaft, Industrie, Anbietern und Anwendern aus dem universitären Bereich. Auf der Konferenz wurde unter anderem in sechs parallelen VortragsTracks ein breit gefächertes Spektrum an Vorträgen mit aktuellen Themen des modernen Software Engineerings angeboten. Gemeinsam mit 21 anderen Ausstellern präsentierte sich das International Software Quality Institute (iSQI) bei den Software Quality Days. Bestehende Bekanntschaften und Verbindungen konnten gepflegt und neue geknüpft werden.

IoT im Zentrum der Diskussion Diskussionen zum Thema „Internet of Things“ (IoT) werden längst nicht mehr „nur“ im rein technischen Kon-

Microservices

text geführt. Die technischen Lösungen werden immer mehr in den Kontext der politischen, gesellschaftlichen und ethischen Rahmenbedingungen gestellt. Auch der Meinungsaustausch auf den Software Quality Days verdeutlichte das große Interesse an derartigen Fragestellungen. Ethische Entscheidungen waren zumindest bisher in hohem Maße dem Menschen als Bediener der Systeme überlassen. Im Kontext des IoT wandern ethische Fragestellungen aber mehr und mehr auch in die Algorithmik und die künstliche Intelligenz der Maschinen. Daher birgt das Internet der Dinge nicht nur bezüglich seiner Architekturen, sondern auch hinsichtlich der ethischen Regelwerke Herausforderungen, die zukünftig zu lösen sind.

Grundlagen flexibler Softwarearchitekturen 2016, 386 Seiten € 36,90 (D) ISBN 978-3-86490-313-7

E. Wolff

Continuous Delivery Der pragmatische Einstieg 2. Auflage 2016, 282 Seiten € 34,90 (D) ISBN 978-3-86490-371-7

A. Mouat

Docker Software entwickeln und deployen mit Containern 2016, 368 Seiten € 36,90 (D) ISBN 978-3-86490-384-7

Termin für 2018 steht Der nächste Termin steht bereits fest: die Jubiläums-Konferenz – 10 Jahre Software Quality Days – wird vom 16. bis 19. Januar 2018 stattfinden. Veranstaltungsort ist, wie in den Jahren zuvor, die österreichische Landeshauptstadt Wien.

ok: Buch + E-Bokt.de/plus www.dpun

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


GERMANY GOES SXSW 28

Ein Event, an dem im März keiner vorbei kommt, ist die South by Southwest (SXSW) in Austin, Texas. Vom 10. bis 19. März treffen sich in den USA Professionals, Tech-Jünger und Start-up-Stars, um den Trends von morgen nachzugehen. Der Kalender der SXSW ist prall gefüllt. Über 1.000 Sessions und Events stehen 2017 im Programm. Sie bieten die perfekte Gelegenheit, um den eigenen Horizont zu erweitern und neue Branchenkontakte zu knüpfen.

RASANTER GESCHÄFTSERFOLG JOERG BLUMTRITT IST DATA SCIENTIST UND BLOGGER. ER IST MITGRÜNDER DER DATARELLA GMBH, DIE IM VERGANGENEN JAHR DURCH HIGH5 UNTERSTÜTZT WURDE. AUCH FÜR SEIN UNTERNEHMEN HAT SICH DER BESUCH DER SXSW GELOHNT. HIER SAGT ER WARUM: Für uns bei Datarella war das Jahr seit der letzten SXSW-Konferenz äußerst bewegt. Durch ein Kundenprojekt hatten wir 2015 begonnen, uns mit der Blockchain und mit Smart Contracts zu beschäftigen. Blockchain – die Technolgie hinter Bitcoin und anderen sogenannten CryptoWährungen – ist vermutlich DAS Buzzword des Jahres. Die SXSW-Konferenz, die traditionell der „Jahrmarkt der Buzzwords“ ist, war da natürlich perfekt, um interessante Leute zu treffen und uns in der Community zu vernetzen. Auf der SXSW kommt man mit Experten, potenziellen Partnern und Kunden leicht in Kontakt, selbst mit Menschen, die sonst sehr schwer erreichbar sind. Mit dem „German Haus“ steht zudem ein angenehmer Ort für Termine und Treffen zur Verfügung. Seit damals hat unser Blockchain-Geschäft extrem zugelegt. Wir arbeiten für eine Reihe internationaler Konzerne und Regierungsorganisationen, nicht nur als Berater, sondern vor allem in der Software-Entwicklung. Dabei fokussieren wir uns auf Anwendungen jenseits der Finanzbranche.

Regelmäßig veranstalten wir ein Meetup zur Blockchain, mit 80 bis 120 interessierten Besuchern und internationalen Speakern in München, Stuttgart, Köln, Hamburg und Danzig. Auf der SXSW-Konferenz 2017 trete ich auch im Hauptprogramm auf – und darauf bin ich besonders gespannt!


TIEFGREIFENDE VERÄNDERUNGEN HIgh5 ünterstützt als Partner des „German Haus“ wiederholt vielversprechende deutsche Start-ups. Das Stuttgarter Unternehmen Smoope hat den Durchbruch bereits geschafft. Unterstützt von High5 nahm die junge Firma im vergangenen Jahr an der SXSW teil. Im Interview erzählt Smoope-Mitgründer und Geschäftsführer Eleftherios Hatziioannou, wie es nach der SXSW-Teilnahme weiterging.

ser entwickeln konnten. Wir haben uns weg vom reinen App-Anbieter hin zum Infrastruktur-Lieferant für sicheres, integrierbares und skalierbares Messaging verändert und helfen Unternehmen dabei, sich fit für das Zeitalter des Conversational Commerce zu machen. Messaging als integraler Bestandteil von Webseiten, Kundenportalen und Apps von Unternehmen – statt einer separaten App.

SQ: HERR HATZIIOANNOU, WARUM HAT SICH DIE SXSW FÜR IHR UNTERNEHMEN GELOHNT?

IHR NEUESTES PROJEKT IST…?

Smoope-Mitgründer und Geschäftsführer Eleftherios Hatziioannou

Die SXSW ist aus unserer Sicht die kompakteste Tech-Veranstaltung der Welt. Kaum ein anderes Event bietet in so kurzer Zeit und auf so engem Raum so viel. Sowohl inhaltlich bei den Workshops, Präsentationen, Diskussionsrunden als auch, wen man dort so alles trifft. Die wichtigsten und interessantesten Köpfe und Marken der Tech-Szene sind präsent und ansprechbar. Wir konnten für uns die wichtigsten Trends mitnehmen und ableiten, wohin sich der Markt in den nächsten 12 bis 24 Monaten entwickeln wird. Das hat uns letztlich geholfen, unsere Prioritäten zu hinterfragen und die richtigen Maßnahmen zu ergreifen, um unsere Technologie marktgerecht weiterzuentwickeln.

WELCHE MEILENSTEINE KONNTEN SIE IM VERGANGENEN JAHR SETZEN? Ein wichtiger Meilenstein war für uns, dass wir einen tiefgreifenden Veränderungsprozess initiiert haben, der letztlich sogar zu einem modifizierten Geschäftsmodell geführt hat, mit dem wir uns jetzt noch schneller und bes-

Dass wir mit unserer Technologie mittlerweile höchsten Ansprüchen in Sachen Datenschutz, Sicherheit und Individualisierung gerecht werden und deshalb insbesondere in sensitiven Branchen wie der Finanz- und Versicherungswirtschaft stark wachsen. Wer hätte anfangs gedacht, dass heute Banken, Versicherungen und Finanzdienstleister den größten Anteil unserer Kundschaft ausmachen. Als wir vor drei Jahren gestartet sind, wollten wir eigentlich die Mobilfunk-Shops meines Mitgründers mit Ihren Kunden vernetzen.

IHR BESTER TIPP FÜR START-UP-GRÜNDER? Mein SXSW-Tipp: Das Programm ist fast schon überwältigend, deshalb rate ich jedem zu einer guten Vorbereitung. Unbedingt vorher prüfen, welche Sessions interessant sind und sich nicht mehr als 3-4 pro Tag vornehmen, damit noch genug Zeit für zufällige Gespräche und Netzwerken bleibt. Mein Tipp für Start-ups allgemein: Gerade in der Startphase sollte man flexibel bleiben und nicht an der Ursprungsidee festhalten, wenn sie nicht

funktioniert. Letztlich tastet man sich als Start-up voran bis zum ProductMarket-Fit. Dieser ist erst dann gegeben, wenn ein echtes Kundenproblem gelöst wird, für das Kunden bereit sind, Geld auf den Tisch zu legen. Nicht die Gründer, sondern der Markt sollten entscheiden, was letztlich das Produkt sein wird. Die Fragen stellte Christin Senftleben.


GERMANY GOES SXSW Ausgabe 42  |  März 2017

30

RISING STARS DER SXSW

DIESE START-UPS PRÄSENTIEREN SICH MIT UNTERSTÜTZUNG VON HIGH5 IN AUSTIN HOLOPLOT HOLOPLOT hat ein komplett neuartiges und bahnbrechendes professionelles Lautsprecher-System entwickelt, welches die Grenzen im Audio- Bereich neu definiert. Das Produkt, bestehend aus Hardware und Software erlaubt es, Schall zu richten wie einen Lichtstrahl. Somit kann nun präzise bestimmt werden, wo etwas zu hören ist oder – vielleicht noch interessanter – wo nicht. Die Schallwellen des Systems haben dabei konstante Lautstärke auf Distanz – eine revolutionäre Innovation im Audio-Bereich – und erlauben es, nun alle Zuhörer mit derselben Qualität zu versorgen, unabhängig von ihrer Distanz oder Position zum Sound-System.

Das intuitive Software Interface erlaubt dabei die einfache Kontrolle über mehrere Kanäle gleichzeitig, wobei in Echtzeit mehrere Sound Beams mit unterschiedlichem Inhalt, Richtung und Größe gesteuert werden können. Dies macht HOLOPLOT zum perfekten Tool für viele Bereiche von Konferenzen, Konzerten, Messen bis hin zu jeder Umgebung mit schwieriger Akustik. Darüber hinaus liegt eine große Stärke des Systems im Erstellen von 3Dimmersiven Audio-Umgebungen. Das System ist in der Lage, die Akustik von Räumen zu verändern. Der Zuhörer kann dabei den Lautsprecher nicht mehr als Quelle identifizieren und

MIT EVOPARK FINDET JEDER EINEN PARKPLATZ Einen Parkplatz in der überfüllten Innenstadt finden, die letzte freie Parklücke im Parkhaus sichern – nichts ist leichter als das, versprechen die Gründer von evopark. Das Start-up wurde 2014 mit dem Ziel gegründet, das Parken neu zu erfinden. Eine Parkkarte öffnet per RFID-Funkchip Schranken im Parkhaus automatisch. Der Nutzer spart sich das Schlange stehen am Kassenautomaten, er zahlt bargeldlos und bequem am Monatsende. Ergänzt wird die evopark Karte durch eine kostenlose App, die freie Parkhäuser in der Umgebung zeigt und auf Wunsch dorthin navigiert. Vier Absolventen der WHU – Otto Beisheim School of Management haben evopark gegründet und führen es seither gemeinsam: Maximilian Messing, Tobias Weiper, Sven Lackinger und Marik Hermann. Die Parkkarte und App sind bereits sehr erfolgreich im Einsatz, auch dank der engen Zusammenarbeit mit den größten Systemherstellern und Parkhausbetreibern in Deutschland.

Zahlreiche namhafte Unternehmen nutzen evopark Lösungen, u.a. AXA Deutschland und NOVOFLEET. Aktuell verzeichnet evopark bereits mehr als 20.000 Kunden. Mit seinem innovativen Konzept hat das Kölner Start-up bereits 14 Preise gewonnen, darunter den DWNRW Award 2015, überreicht von NRW-Wirtschaftsminister Garrelt Duin. Im September 2016 erhielt evopark auf dem CODE_n new.New Festival den Hauptpreis der Sparte Connected Mobility, verliehen durch Hewlett Packard Enterprise. Damit wurde evopark für das vielversprechendste Geschäftsmodell, die innovativste Technologie und das beste Kundenerlebnis auf dem Gebiet der vernetzten Mobilität geehrt. Namhafte Business Angels haben in das Unternehmen investiert. Im

komplett in die akustische Umgebung eintauchen. Das eröffnet neue Möglichkeiten im Entertainment Bereich, besonders auch für neuartige Technologien wie Virtual Reality.

Juni 2016 hat sich zudem Porsche mit einem siebenstelligen Betrag an evopark beteiligt – die erste Investition des Automobilherstellers in ein Start-up. Auf der SXSW Interactive präsentiert sich evopark mit Unterstützung von High5 einem internationalen Publikum und potentiellen Kunden. Übrigens: Mit seinem Produkt überzeugte das clevere Gründerteam bereits die Start-up-Investoren Frank Thelen und Carsten Marschmeyer in der VOXSendung „Die Höhle der Löwen“.


ANTELOPE.TECHWEAR - DIE ERSTE LEISTUNGSSTEIGERNDE SPORTBEKLEIDUNG DER WELT Schneller, stärker, ausdauernder – ANTELOPE erhöht jeden Trainingseffekt. Die Sportbekleidung der Zukunft ist eine Fusion aus Sportswear und Wearable Technology. ANTELOPE besteht aus einer Kompressionsbekleidung mit integrierten Elektroden, einer smartphonegroßen Elektronikeinheit sowie einer App zur Steuerung des Systems. Über elektrische Impulse von außen werden Muskelkontraktionen

beim Sport verstärkt – jede sportliche Betätigung wird damit intensiver und deutlich effektiver. Die einzigartige Sportswear setzt auf Elektromuskel-

stimulation (EMS) – eine Technologie, die aus der Rehabilitation sowie dem Leistungssport stammt. Die Elite der Sportwelt hat den Nutzen von EMS bereits erkannt. Stars wie Usain Bolt, Rafael Nadal oder die Fußball-Teams von Bayern München und Real Madrid profitieren seit Jahren von den Trainingseffekten dieser Technologie. Wearable Life Science GmbH (“WLS”) ist das Unternehmen hinter der Marke ANTELOPE. Es wurde im März 2014 von Philipp G. Schwarz, Kay Rathschlag und Patrick Thumm gegründet. Dr. Mynia Deeg stieß im Januar 2016 zum Management Team. Aktuell besteht das interdisziplinäre Team aus über 25 Mitgliedern, darunter: Serial Entrepreneurs, EMS-Pionieren, Textilund Elektroingenieuren, Software- und IT-Spezialisten, Sportwissenschaftlern, Vertriebs-, Marketing- und PR-Experten sowie einem Professor der Neurophysiologie. Viele mit einem internationalen Background. Unterstützt wird das Team von einem renommierten Beirat sowie sieben Business Angels, die neben der finanziellen Unterstützung ihr Know-how mit in den Entwicklungsprozess einfließen lassen.

GRAMMOFY – DAS SPOTIFY FÜR KLASSIK-FANS Klassische Musik neu entdecken und erlebbar machen – das hat sich Grammofy aus Stuttgart auf die Fahnen geschrieben. Der Streaming-Dienst ist etwas für Neugierige und Kenner, denn er bietet die Möglichkeit, sowohl neue musikalische Welten kennenzulernen, als auch nach bekannten Komponisten und Künstlern aus verschiedenen Klassik-Epochen zu stöbern. Im Zentrum des Angebots stehen wöchentlich kuratierte „Collections” in denen ausgewählte Werke vorgestellt und von Hintergrundinformationen im Podcast-Format begleitet werden. Das junge Start-up um Gründer Lukas Krohn-Grimberghe will auf diese Weise neben Klassikfans vor allem neue Zielgruppen ansprechen, indem es klassische Musik für das Online-Streaming zugänglicher macht. Ähnliche

HIGH 5 FÜR DEUTSCHE START-UPS Mit einer eigenen Delegation ist Deutschland auch in diesem Jahr auf der SXSW präsent. Im Vorjahr zählte sie über 900 Teilnehmer. In diesem Jahr dürfte die Zahl sogar noch etwas darüber liegen. Zentraler Anlaufpunkt für viele während der SXSW ist das German Haus. Unter der Federführung der Initiative Musik und der Beteiligung mehrerer Bundesländer repräsentiert das German Haus (inklusive eines Standes auf der Trade Show) die deutsche Kultur- und Kreativbranche. Als Partner des German Haus hat sich das Tochterunternehmen des iSQI, die High5 GmbH, die Förderung der beteiligten Start-ups auf die Fahnen geschrieben. So werden in diesem Jahr junge Firmen aus Bayern, BadenWürttemberg, Berlin-Brandenburg und Nordrhein-Westfalen finanziell unterstützt. Zudem erhalten die Unternehmen fachlichen Support in Sachen nachhaltiger Unternehmens- und Personalplanung.

BREAKFAST TV LIVE VON DER MESSE Dienste wie z.B. Spotify sind im Mainstreambereich bereits sehr erfolgreich. Mit Grammofy gibt es nun ein Pendant für Klassikfans. Basierend auf modernsten Technologien hat sich Grammofy ganz der Liebe zu klassischer Musik, Filmmusik und Jazz verschrieben. Momentan ist der Streaming-Dienst in 17 Ländern präsent. „Wir wollen eine Brücke schlagen zwischen moderner Technologie, zeitgemäßen Formen des Musikkonsums und der Klassischen Musik“, sagt Grammofy-Gründer Lukas Krohn-Grimberghe. Die SXSW bietet für ihn eine hervorragende Möglichkeit, um neue Kontakte im internationalen Musik-Business zu knüpfen.

So frisch wie das warme Brötchen vom Bäcker bekommen „Daheimgebliebene“ vom 10. bis 13. März die besten News und Innovationen von der SXSW im „High 5 Breakfast TV“ serviert. iSQI-CEO Stephan Goericke lädt sich im Daily Talk interessante Gesprächspartner an den Frühstücktisch ein. Zusätzlich präsentiert das kurzweilige Format informative Beiträge rund um SXSW-Events und Keynotes. Schalten Sie ein zum High5 Breakfast TV via Livestream direkt aus dem High5-Haus in Texas. high5startups WEB: high5startups.com


iSQI NEWS

Ausgabe 42  |  März 2017

32

7. World Congress for Software Quality 20. bis 22. März / Lima, Peru Vom 20. bis zum 22. März 2017 findet der siebente World Congress for Software Quality (WCSQ) in Lima (Peru) statt. Er bringt internationale Software-Experten, innovative Praktiker und inspirierende Redner aus Wirtschaft und Wissenschaft zusammen.

einen tiefen Einblick in das Hauptthema „Software Quality meets IoT“ und in viele andere spannende Themen, wie Mobile Apps, Frauen in der Technologie, Big Data und vieles mehr.

SOFTWARE QUALITY MEETS IoT

Außerdem haben Besucher die Gelegenheit, Peru kennenzulernen – ein Land mit vielen kulturellen Einflüssen und einer außergewöhnlichen internationalen Atmosphäre. In dem Kontrast von Neuem und Alten befindet sich die IT-Branche in einem starken Wachstum.

In den drei Tagen wird den Besuchern ein vielfältiges Programm geboten, mit bemerkenswerten Keynotes, praxisnahen Tutorials und Workshops sowie einer Fachausstellung und einem Social Event. Der WCSQ ermöglicht

Aus dem iSQIKonferenzplaner 2017 06.03. – 09.03.2017 SXSW Edu // Austin 10.03. – 14.03.2017 SXSW Interactive // Austin 15.03.2017 Swiss Testing Day // Zürich 20.03. – 22.03.2017 7th World Congress for Software Quality // Lima 25.03. – 31.03.2017 HOOD ReConf // München 24.04. – 28.04.2017 Mobile Dev & Test Conference // San Diego 15.05.2017 TestNet // Nieuwegein 22.05. – 23.05.2017 National Software Testing Conference // London

NEUES TRIFFT AUF ALTES

RABATT AKTION Mit dem Aktionscode wcsq_isqi_15 erhalten Sie 15 Prozent Rabatt auf den Ticketpreis! Mehr Informationen finden Sie unter: www.wcsq.org

Relevanz des IREB®-CPRE erneut bestätigt Mit dem Ziel, ein einheitliches Ausund Weiterbildungsschema für Fachkräfte des Requirements Engineering zu festigen, haben sich das IREB® und REQB® dazu entschlossen, ihre Bestrebungen nach einer allgemein verbindlichen Ausbildung im Bereich RE unter der Flagge des IREB® fortzuführen. Durch den Zusammenschluss gewinnt das bereits etablierte Ausbildungsprogramm IREB® CPRE (Certified Professional for Requirements Engineering) weiter an Bedeutung. Seine Reputation und Stellenwert werden zusätzlich gestärkt. Als Zertifizierungsspezialist für das IREB® -Schema unterstützt iSQI die Bündelung der Kräfte.

KOMPETENT UND ERFAHREN BERATEN Mit iSQI haben Fachkräfte einen erfahrenen IREB® -Partner an ihrer Seite, der

sich mit der IREB® CPRE-Zertifizierung bestens auskennt und sie kompetent beraten kann. Durch leistungsstarke und innovative Prüfungsverfahren, sein hervorragendes, internationales Netzwerk und dem Angebot von Online-Prüfungen in über 5.200 Pearson VUE-Testcentern unterstützt iSQI maßgeblich das internationale Wachstum des IREB® CPRE.


33

Partnerschaft mit Universität in Havanna Ende des vergangenen Jahres war das International Software Quality Institutes (iSQI) zu Gast an der Universidad Tecnologica de la Habana. CEO Stephan Goericke und COO Ronald Huster trafen dort die Dekanin Dra. Martha Delgado und weitere Unidozenten der Facultad de Ingenieria Informatica. Im Gespräch wurden die Kooperationsmöglichkeiten im Rahmen des develoPPP.de-Förderprojektes vorgestellt und besprochen. Speziell für die kubanischen Studierenden des Fachbereichs Centro Estudies Ingenier Software (CEIS), wurde nach Zusatzqualifikationen in den Bereichen Software-Testing, Requirements Engineering, Project-Management sowie Software Security nachgefragt. Ende Dezember 2016 wurde ein entsprechendes Memorandum of Un-

derstanding für die Zusammenarbeit vereinbart. In der ersten Jahreshälfte 2017 plant iSQI nun zunächst eine TTT-Ausbildung im Bereich Software-Testing für die kubanischen Dozenten der Fakultät. Diese befähigt die Dozenten dazu, selbst Ausbildungskurse für die Studierenden anzubieten und durchzuführen. Mit dem Anliegen, Hilfestellung bei der Einführung international anerkannter Qualifizierungsstandards zu liefern und sich gleichermaßen mit Kubas IT-Experten zu vernetzen, ist iSQI einen weiteren Schritt vorangegangen. Zusätzlich zu den angebotenen Qualifizierungsmaßnahmen wird das iSQI der Bibliothek des Fachbereichs eine Auswahl an Fachliteratur zu Verfügung stellen.

München startet Qualifizierungsprogramm für IT-Fachkräfte Die Bayerische Landeshauptstadt München macht sich mit Hilfe des International Software Quality Institute (iSQI) fit für die Zukunft. Im Rahmen eines speziellen Qualifizierungsprogramms soll die IT-Fachkompetenz der Beschäftigten weiterentwickelt werden. Hierzu werden von der Stadt verschiedene Ausbildung-Angebote initiiert, die mit einer Abschlussprüfung enden sollen. Die Stadt München hat zu diesem Zweck das iSQI mit der Organisation, Durchführung und Auswertung dieser Prüfungen beauftragt. Erste Prüfungen sollen voraussichtlich schon in diesem Frühjahr stattfinden. Der Kooperationsvertrag läuft vorerst bis Ende 2020.


Titelthema

Ausgabe 42  |  März 2017

34

EINFÜHRUNG

Hohe Qualität durch eine testgetriebene Entwicklung VOR- UND NACHTEILE VON TEST DRIVEN DEVELOPMENT (TDD) Vorsichtig, aber zielsicher, sucht sich die Testing Goat, die ihre Heimat in der PythonWelt hat, ihren Weg durch die SoftwareEntwicklung. Sie interessiert sich nicht für Dirty Hacks und bleibt auch nicht stehen für unpräzise Anforderungen. Dafür hört sie auf User Stories und Testautomatisierung. Der Leser wird hier zwar nicht Bekanntschaft mit der Testing Goat machen, dafür aber ihre „Lebensart“ kennenlernen und verstehen.

Falls das Test Driven Development doch noch nicht jedem ein Begriff ist, hier eine kurze Zusammenfassung: Es handelt sich hierbei um eine Vorgehensweise bestehend aus kurzen Zyklen, in denen der erste vorgenommene Schritt immer das Schreiben des Testfalls ist. An dieser abstrakten Definition kann man bereits erahnen: Testen ist hier, wie der Name schon sagt, nicht der Nebenprozess, der durch die einzelnen Projekt-Phasen meist nur mühevoll mitgezogen wird, sondern tatsächlich einer der Hauptprozesse, an denen sich alle nachfolgenden Schritte orientieren. Das TDD kann somit auch als eine Methode des Software-Design bezeichnet werden.

DAS VORGEHEN Im Rahmen des TDD werden die Tests bereits vor der ersten Zeile Code geschrieben. Dies geschieht natürlich nicht für die gesamte Software, sondern immer nur für den kleinstmöglichen lauffähigen Teil der Software, der in diesem Moment umgesetzt werden soll. Das Vorgehen ist hier immer das gleiche: Der erste Schritt ist das Schreiben des funktionalen Tests. Die kommende Funktionalität wird in einem Testfall aus Sicht des Benutzers beschrieben. Für funktionale Tests bieten sich Abnahmekriterien aus User Stories bestens an. Dieser funktionale Test kann zum Beispiel automatisiert in Selenium1 realisiert werden. Wird etwa einem Onlineshop eine Funktionalität hinzugefügt, wie ein Benutzerlogin, beschreibt der automatisierte Test eine noch gar nicht existierende Eingabemaske. Das Ziel ist hierbei, dass der Testfall fehlschlägt.

PRAKTISCHE VOR- UND NACHTEILE Als Vorteil fällt hier bereits auf, dass die ersten Tests so elementar und einfach sein müssen, dass sie bis zum Ende des Entwicklungsprozesses bestehen bleiben und angewendet werden können. Man arbeitet also nicht


35

TEST DRIVEN DEVELOPMENT besteht aus kurzen Zyklen, in denen der erste vorgenommene Schritt immer das Schreiben des Testfalls ist.

mehr mit komplexen und langen Tests und Test-Szenarien, die bei jeder neuen Anforderung umgeschrieben werden müssen, sondern erreicht eine viel höhere Geschwindigkeit durch kurze und essenzielle Tests, auf denen nach Belieben aufgebaut werden kann. Der Nachteil ist natürlich genauso offensichtlich: Zeit. Es kostet anfangs eine Menge Zeit sich daran zu gewöhnen, Testfälle vor dem Code zu schreiben und es kostet Zeit, die Testfälle vorzubereiten. Existiert ein funktionaler Test, kann die Umsetzung der Funktionalität im Code geplant werden, damit der Testfall gelingt. An dieser Stelle bietet es sich an, Unit Tests zu schreiben, um den kommenden Code zu prüfen. Dieses Vorgehen stellt sicher, dass es am Ende keine ungetestete Zeile Code mehr gibt. Die Unit Tests setzen genauso wie die funktionalen Tests auf einer elementaren Ebene an und decken immer nur den kleinstmöglichen Teil ab, sich orientierend an der fachlichen Umsetzung. Hier besteht wieder der gleiche Vorteil: Die Tests werden so einfach ausfallen, dass sie bis zum Ende des Entwicklungsprozesses behalten werden können. Allerdings findet sich auch hier wieder der Nachteil der Zeit und Umgewöhnung. Dazu kommt noch, dass ein Entwickler, der die Fachlichkeit nicht kennt, Schwierigkeiten haben wird, Unit Tests für einen noch nicht existierenden Code zu schreiben. Existieren jetzt also fehlschlagende funktionale und nicht-funktionale Tests, wird genau so viel Code geschrieben wie notwendig ist, um die Tests beim Ausführen grün zu bekommen. Der letzte, nicht immer erwähnte Schritt ist das „Refactoring“ von Code. (s. Abb. 1) Da sich der funktionale Test auf einer abstrakteren Ebene befindet als die Unit Tests, folgen die Unit Tests und der geschriebene Code also dem funktionalen Test - der funktionale Test stellt in diesem Vorgehen eine klar definierte Anforderung mit einem klaren Ziel dar. Erst wenn der funktionale Test grün ist, kann davon gesprochen werden, dass die Anforderung auch tatsächlich erfüllt wurde. Dieses Vorgehen hat den Vorteil, dass abstrakte fachliche Zusammenhänge als automatisierte Testfälle existieren, bevor mit der Entwicklung begonnen wird, und damit ein klares Ziel geschaffen wird, auf das hingearbeitet wird.

WOZU IST DIESER PROZESS NOTWENDIG? Kent Beck, der Quasi-Erfinder des TDD, hat die Notwendigkeit mit einer Metapher beschrieben (Test-Driven Development by Example 2002, S. 10): Das Heben eines Eimer Wassers aus einem Brunnen. Ist der Brunnen nicht allzu tief und der Eimer nicht ganz voll, lässt sich der Eimer problemlos heben. Ist der Brunnen tief und der Eimer randvoll, wird das Heben sehr schnell sehr anstrengend. Um zu verhindern, dass der Eimer nach einem Ausrutscher wieder nach unten fällt, existiert TDD. Eine der großartigsten Eigenschaften des TDD ist, dass man sich keine Gedanken mehr machen muss, etwas bereits Umgesetztes zu vergessen. Man führt einfach seine automatisierten fachlichen Testfälle erneut aus und schon ist das Ziel wieder klar erkennbar. Hier wird erkennbar, warum TDD auch als Methode des Software Designs bezeichnet wird. Offensichtlich entsteht hierbei aber auch ein Nachteil: Sollten die Testfälle von niedriger Qualität sein, wird auch die Fachlichkeit der Software nur ungenügend ausfallen, was spätestens bei den Abnahmetests zu enormen Problemen führt. Wird TDD von Anfang an befolgt, wachsen die Testfälle genau wie die Funktionalität. Anfangs wird vielleicht nur eine dreizeilige Funktion getestet, nach ein paar Tagen wird die Funktion erweitert und der Testfall wächst mit. Nach ein paar Sprints, wenn die Funktion zu einer polymorphen Metaklasse herangewachsen ist, ist die eigentliche Funktionalität immer noch über die Testfälle nachvollziehbar.

DER VORTEIL VON TEST-EXPERTEN IN TDD Bei all der Testautomatisierung fragt man sich irgendwann, ob man überhaupt noch eigene Test-Experten braucht. Die Antwort lautet definitiv: ja! Tester sind näher an der Fachlichkeit, erkennen mit ihrer Erfahrung auch Szenarien, die sonst keine Beachtung finden würden, und sind in der Lage, Entwicklern im Bereich der Automatisierung einen Teil der Arbeit abzunehmen. In einem agilen Projekt existiert zwar keine absolute Abgrenzung zwischen den Aufgabengebieten, trotzdem sollte die Rolle des Testers Beachtung finden. Die Erfahrung zeigt, dass eine Rolle, welche sich primär um das Erkennen von Risiken und Fehlern in der Software kümmert, auch bessere Ergebnisse liefert als eine gemischte Rolle, der diese Aufgabe nur zufällig zugeteilt wurde.


Titelthema

Ausgabe 42  |  März 2017

NEIN

SCHREIBE DEN

IST DER

FUNKTIONALEN TEXT

TEST GRÜN?

JA

SOLLTE REFACTORED WERDEN?

NEIN

SCHREIBE CODE

JA

Abb. 1: Der vereinfachte TDD Prozess. Quelle: selbsterstellte Grafik

Zum Beispiel übersieht ein Entwickler, der sich primär nur mit einem kleinen Teil der Software beschäftigt, schnell themenübergreifende Testfälle, die man nur ableiten kann, wenn man sich auch bereits aktiv mit Komponenten und UmSystemen auseinandergesetzt hat. Software-Tests nur um des Testens Willen helfen nicht viel, am Ende steht man vor einem Berg von Tests, hat keinen Überblick, was eigentlich genau getestet wird, und bei jeder Code-Änderung werden viele der Units und funktionalen Tests rot. Schlimmstenfalls dauert das Fixen der Tests dann genauso lange wie das Schreiben des Codes selbst. Es ist leicht, bei einer komplexen Business-Software den Überblick zu verlieren. Genauso leicht ist es, die relevanten Tests aus den Augen zu verlieren. Ohne Kontrolle und Leitung mit klarem Testvorgehen kann eine Test-Suite schnell genauso komplex und unüberschaubar werden, wie die eigentliche Software. Hier hilft auch nur die Erfahrung eines professionellen Testers, der

von Anfang an mit einem klaren Testvorgehen den Blick auf das Wesentliche lenkt.

DAS TESTEN ALS ROTER FADEN Den Grundstein legen hier auch bereits die Anforderungen an die Software. Wenn mit einer Spezifikation gearbeitet wird, ist es wichtig sich von Details zu entfernen. Nicht das Wie sollte spezifiziert werden, sondern das Was. Es sollten Fachlichkeiten und keine Geschäftslogik im Prosatext geliefert werden. Fehlt ein grundsätzlicher Bezug zur Fachlichkeit, wird nur noch das umgesetzt, was die Spezifikation vorgibt, ohne zu verstehen, was eigentlich gerade passiert. Entsprechend wird die Entwicklung auch keine Fachlichkeiten mehr abdecken, sondern nur noch komplexe, unüberschaubare Regelwerke, die sie selbst nicht versteht. Legt man den Fokus auf Fachlichkeit anstatt auf technische Details, ist der Vorteil, dass sich eine Fachlichkeit, wenn sie richtig beschrieben wird, so bald nicht ändern sollte. Technische Details

36


37

hingegen ändern sich ständig – mit jedem neuen Release können sich größere und kleinere technische Details ändern, während die Fachlichkeit gleichbleibt. Auch in der agilen Entwicklung treten immer wieder dieselben Irrtümer auf: Man glaubt, nah an der Entwicklung zu sein, aber in Wirklichkeit bewegt sich alles in abstrakten Regelwerken und kafkaesker Geschäftslogik. Gibt die Spezifikation bereits Datentypen und Funktionslogik vor, sinkt die Motivation die eigene Arbeit zu verstehen, signifikant. Durch die Beschränkung auf Use Cases und anfängliches Realisieren durch fachliche Tests können diese Gefahren überwunden werden.

ANFÄNGLICHE HÜRDEN ÜBERWINDEN Das gesamte Vorgehen hört sich in der Theorie gut an, lässt sich in der Praxis allerdings meistens nur schwer realisieren. Abgesehen von den bekannten Widerständen in einem Projekt muss hierfür auch die richtige Einstellung im Team vorhanden sein. Die Umstellung, zuerst Testfälle zu schreiben und danach den Code, scheint anfangs zu aufwändig und umständlich. Einfacher wird es, wenn man sich die Rosinen heraus pickt und nicht verlangt, dass sofort eine komplette Umstellung erfolgt. Hier sind die TestExperten gefragt, da für sie der Umstieg am einfachsten ist. Wenn man als Tester bereits eng mit der Entwicklung zusammenarbeitet, ist es gar kein Problem, eine GUI zu automatisieren, bevor die Entwicklung überhaupt be-

gonnen hat. Somit wird Fachlichkeit von Anfang an durch automatisierte Tests abgebildet und der Entwickler orientiert sich bei der Umsetzung seiner Arbeit an den vorgegebenen Tests. Schlägt ein Testfall fehl, leitet dieser den Entwickler über Stacktraces Schritt für Schritt zum Ziel. Das hört sich kompliziert an – werden die Testfälle allerdings ausführlich und methodisch geschrieben, ergibt sich hierdurch ein roter Faden, dem der Entwickler folgen kann. Folglich orientiert sich der Entwickler nicht an Fließtext und Stichpunkten aus User Stories, sondern an praktischen Beispielen über die Testfälle. Wichtig für den Tester ist hierbei auch, sich nicht zum Over Engineering der Tests verleiten zu lassen. Kleine, einfache Skripte, die möglichst nah an der Fachlichkeit und branchenspezifisch sind, nach Bedarf einzelnen Stories und Abnahmekriterien zugeordnet werden können und dem Entwickler jederzeit zur Verfügung stehen, sind definitiv einem großen Automatisierungsframework vorzuziehen. In einem aktuellen agilen Projekt von Capgemini konnte durch das Anwenden der TDD-Methodologie, verantwortlich geführt durch das Test-Team, der Testprozess vor den Entwicklungsprozess gestellt werden. Die Veränderung wurde vom Entwicklungsteam und den Projektverantwortlichen als sehr positiv bewertet. Als besonders hilfreich bei der Umstellung hat sich gezeigt, dass es am besten ist, die neuen Ideen anfangs nur

Abb. 2: IDs ermöglichen es bereits GUI Testfälle zu erstellen, ohne dass eine GUI überhaupt vorhanden ist. Quelle: selbsterstellte Grafik

Sascha Rezagholinia ist Technical Test Analyst bei Sogeti Deuschland. Er beschäftigt sich intensiv mit Technologien, Methoden und Lösungsansätzen im Bereich der Software Entwicklung.

mit einem oder zwei Lead Developern zu besprechen und diese dann die neuen Ideen ins Team tragen zu lassen. Zur Unterstützung der Tester wurde in dem Projekt die webbasierte GUI der Software so angepasst, dass alle Elemente mit fixen IDs versehen wurden. So konnten automatisierte Testfälle, die von den Entwicklern auch aktiv genutzt wurden, bereits zu Anfang des Sprints entwickelt werden, um ihre Arbeit zu kontrollieren. Durch die Unterteilung der Test Automatisierung in kleine, in sich geschlossene Skripte konnten diese auch problemlos im Versionsverwaltungstool Git in jedem Softwarebranch geführt werden und so immer der richtige Test zur richtigen Version zugeordnet werden.

FAZIT Durch Anwenden der Methode der testgetriebenen Entwicklung erreicht man quasi eine Fusion des Test- und des Entwicklungsprozesses. Durch die zusätzliche Fokussierung auf den Schwerpunkt Test rückt die Qualität in den Vordergrund, als Anforderung an das gesamte Projekt. So kann nicht nur eine stetig hohe Qualität geliefert werden, sondern auch komplexe Änderungen können so durch das gesamte Projekt hindurch verfolgt werden. QUELLVERWEIS: https://www.sogeti.de/blog-selenium


Im Gespräch

Impressum

Sudoku 4 1

1

6

4

7

Sudokus lautete: USER EXPERIENCE

Friedrich-Engels-Str. 24, 14473 Potsdam Tel

+49 331 231810-29

Fax

+49 331 231810-10

info@asqf.de, www.asqf.de

Dino Saric, Aachen // Timo Fischer,

8

2

9

Paderborn // Christina Papava-

REDAKTION

sileiou, Konstanz // Frank Ossig,

V.i.S.d.P.:

München // Christian Frederking //

6 3

HERAUSGEBER ASQF e.V.

Die Gewinner aus Heft 41 sind:

9 6

Die Lösung des letzten

Nürnberg

9

5

6

Stephan Goericke (Hauptgeschäftsführer) Chefredaktion: Christin Senftleben Redaktionsteam: Julia Schirmer, Anja Schreinert, Isabel von Gustedt Friedrich-Engels-Str. 24, 14473 Potsdam

1 4

2

1

7

6

4

Tel

+49 331 231810-56

Fax

+49 331 231810-10

redaktion@sq-magazin.de, www.sq-magazin.de SATZ / LAYOUT Frenkelson Werbeagentur, Potsdam www.frenkelson.de

Buchstaben: 1=M, 2=E, 3=U, 4=G, 5=H, 6=A, 7=Z, 8=N, 9=S LÖSUNGSWORT

FOTOS: ASQF e.V. und iSQI GmbH Titel: ©PR Uwe Friedrichsen Seite 4, 8, 11 ©shutterstock_d1sk Seite 5 ©shutterstock_hanoiki Seite 18 ©shutterstock_Rawpixel

Mitmachen und gewinnen! Docker-Container bieten eine einfache, schnelle und robuste Möglichkeit, Software zu entwickeln, zu verteilen und laufen zu lassen – besonders in dynamischen und verteilten Umgebungen. Mit diesem praktischen Leitfaden lernen Sie, warum Container so wichtig sind, was durch den Einsatz von Docker möglich ist und wie Sie es in Ihren Entwicklungsprozess einbinden. Dieses Buch ist ideal für Entwickler, Operations-Techniker und

Seite 24 ©shutterstock_MrCreative Seite 28 ©shutterstock_RoschetzkyProductions

Administratoren – insbesondere, wenn Sie einen DevOps-Ansatz verfolgen. Es nimmt Sie mit auf eine Reise von den Grundlagen bis hin zum Ausführen Dutzender Container auf einem Multi-Host-System mit Networking und Scheduling. Im Verlauf des Buches erfahren Sie, welche Schritte zum Entwickeln, Testen und Bereitstellen einer Webanwendung mit Docker notwendig sind. Senden Sie bis zum 4. Mai das Lösungswort des Gewinnspiels an info@asqf.de und gewinnen Sie eines von fünf Büchern.

*Der Rechtsweg ist wie immer ausgeschlossen. Die Mitarbeiter der iSQI GmbH und des ASQF e.V. sowie sämtliche am Gewinnspiel beteiligten Personen sind von der Teilnahme ausgeschlossen. Teilnehmer erklären sich mit der Veröffentlichung ihres Namens in der Folgeausgabe einverstanden.

Seite 28 PR Smoope Seite 28 PR Datarella Seite 30 PR Holoplot Seite 30 PR evopark Seite 31 PR Wearable Life Science Seite 31 PR Grammofy Seite 31 ©shutterstock_Dja65 Seite 32 ©shutterstock_ UNIKYLUCKK Seite 33 ©shutterstock_Prasit Rodphan Seite 34 ©shutterstock_Timofey123 Seite 36 ©shutterstock_dotshok

Alle Portraits und Grafiken mit freundlicher Genehmigung der Autoren. DRUCK: PRINTEC OFFSET, Kassel DRUCKAUFLAGE: 4.000 Stück INTERNETAUSGABE: www.sq-magazin.de

№ 43

erscheint im Juni 2017

SQ № 43 Thema: Qualitätssicherung in der Digitalisierung Anzeigenschluss:15.05.2017 Redaktionsschluss: 28.04.2017

Qualitätssicherung in der Digitalisierung

MEDIADATEN Gern senden wir Ihnen unsere Mediadaten zu. Richten Sie Ihre Anfrage an werben@sq-magazin.de

Das ist unser Schwerpunktthema in der Juniausgabe. Die Beiträge unserer Autoren beleuchten verschiedene Blickwinkel rund um das Thema.

Namentlich gekennzeichnete Beiträge müssen nicht mit der Meinung der Redaktion übereinstimmen. Die Redaktion behält sich das Recht

Sie haben eine Meinung dazu oder möchten einen interessanten Artikel einreichen? Dann schreiben Sie uns an: redaktion@sq-magazin.de

auf sinngerechte Kürzung und Bearbeitung eingereichter Manuskripte vor. Wir machen darauf aufmerksam, dass Daten nicht an Dritte weitergegeben und ausschließlich zur internen Auswertung herangezogen werden können.


Fachgruppentermine: März - Juni 2017 09.03.2017: FG Requirements Engineering, Franken 18:00 – 20:00 Uhr MÄRZ

Thema: Anforderungen an sichere Software ermitteln und dokumentieren

Mi

Do

Fr

Sa

1

2

3

4

So 5

10

6

7

8

9

10

11

12

11

13

14

15

16

17

18

19

12

20

21

22

23

24

25

26

13

27

28

29

30

31

KW Mo

Di

Sa

So

1

2

APRIL 2017

03.04.2017: FG Requirements Engineering, NRW 18:00 – 20:00 Uhr

Thema: Save lifes and save time – efficient and effective safety requirements analysis and elicitation APRIL

09

Thema: Agile Hardware, aber wie? Ein Erfahrungsbericht Vorankündigung

05.04.2017: FG Software Test, Norddeutschland 18:00 – 20:00 Uhr 06.04.2017: FG Requirements Engineering, Franken 18:00 – 20:00 Uhr 10.04.2017: FG Mobile Devices & Apps, Rhein-Main 18:00 – 20:00 Uhr 07.05.2017: FG Software Test, Niedersachsen 18:00 – 20:00 Uhr Vorankündigung

Fr

3

4

5

6

7

8

9

15

10

11

12

13

14

15

16

16

17

18

19

20

21

22

23

17

24

25

26

27

28

29

30

KW Mo

Di

Mi

Do

Fr

Sa

So

18

1

2

3

4

5

6

7

19

8

9

10

11

12

13

14

20

15

16

17

18

19

20

21

21

22

23

24

25

26

27

28

22

29

30

31

KW Mo

Di

Do

Fr

Sa

So

1

2

3

4

MAI 2017

JUNI 2017 Mi

22

Alle Termine und Anmeldung unter: www.asqf.de/events

Do

14

01.06.2017: FG Requirements Engineering, Franken 18:00 – 20:00 Uhr Vorankündigung

Mi

13

Thema: Change Management Vorankündigung

MAI

Di

16.03.2017: FG Agilität, Franken 19:00 – 21:00 Uhr 21.03.2017: FG Safety & Security, Rhein-Main 18:00 – 20:00 Uhr

JUNI

MÄRZ 2017 KW Mo

23

5

6

7

8

9

10

11

24

12

13

14

15

16

17

18

25

19

20

21

22

23

24

25

26

26

27

28

29

30

Branchenticker HALBZEIT! Quality Engineering für das Internet der Dinge Die ASQF-Arbeitsgruppe IoT befindet sich auf einem guten Kurs für einen geplanten Release des Schemas in der zweiten Jahreshälfte 2017 – Halbzeit sozusagen. Ende letzten Jahres wurden in einem eintägigen Workshop der AG die Details des inhaltlichen Outlines für diesen Kurs freigegeben. Damit kann die Arbeitsgruppe nun die Detaillierung der Lehrplaninhalte ausarbeiten. Vermittelt werden sollen die Grundlagen der technischen Expertisen eingebunden in die spezifischen Soft Skills. „Quality Engineering“ ist hierbei Programm. Dadurch soll der Industrie Hilfe in Form von Methoden, Leitlinien zur Qualitätssicherung und Absicherung von IoT-Lösungen durch Qualifizierungsschemata und ein Glossar als De-facto-Standard angeboten werden.

Trimetis AG übernimmt GFB Beider GFB EDV Consulting und Services GmbH, Oberursel, gibt es Veränderungen in derGeschäftsführung. GFB-Gründer und Geschäftsführer Bernhard Baumgarten gibt die Führung ab, bleibt jedoch weiterhin als Key-Account-Managerund Senior Consultant für die GFB tätig. Michael Völker, langjähriger Geschäftsführer, bleibt weiterhin in dieser Position. Neu in derGeschäftsführung sind Andreas Günther, zuletzt Vice President der Capgemini Gruppe,und Peter Laggner, Vorstand und einer der Gründer der Trimetis Gruppe.

ASQF Testing Day NRW Life Science Center, Merowinger Platz 1a, 40225 Düsseldorf Motto: Future of Testing Keynote: Prof. Dr. Andreas Spillner

ASQF Rhein-Main Testing Day Jürgen-Ponto-Platz 1, 60329 Frankfurt am Main Motto: „Aus der Praxis – für die Praxis: Austausch im Open Space Format“ Keynote: Claudine Villemot-Kienzle


FUNDAMENTALS OF TESTING

Für Einsteiger und Profis: ISTQB® Certification Product Portfolio GTB Premium Partner

T-Systems Multimedia Solutions GmbH

www.german-testing-board.info

Profile for International Software Quality Institute

SQ Magazin 42  

SQ Magazin 42  

Profile for isqi
Advertisement

Recommendations could not be loaded

Recommendations could not be loaded

Recommendations could not be loaded

Recommendations could not be loaded