Seit Jahren wachsen die E-Commerce-Händler und eine repräsentative Internetpräsenz gewinnt immer mehr an Bedeutung. Features in kürzester Zeit live zu bringen, ist ein Schlüsselfaktor für den Erfolg. Auf dieser Grundprämisse wurde entschieden, die bis dato verwendete Standardlösung hinter sich zu lassen und mit einem eigenentwickelten Shop die vom Markt geforderten Bedürfnisse zu erfüllen.
Abb. 1: Er hat Generationen begleitet, gehörte fast in jedem Haushalt zum Inventar - der OTTO-Katalog. Doch jede (Erfolgs-) Story muss ein Ende finden. Im Dezember macht sich der Hauptkatalog zum letzten Mal auf den Weg in die deutschen Haushalte. Der Online-Anteil am Umsatz beträgt bei OTTO mittlerweile über 90 Prozent
Schritt 1: Der Online Shop auf der grünen Wiese
Die Teams sind bei OTTO überwiegend in die sogenannten Vertikalen geschnitten. Exemplarisch sei hierfür das Funktionsteam „Suche & Navigation“ genannt. Dieses Team ist in Bezug auf die Suchfunktion und die Navigation von der Oberflächenintegration bis hin zur Umsetzung der Datenbankanbindung für die korrekte Funktionsweise verantwortlich. Durch diese vertikalen Schnitte und die Einhaltung der Makro- und Mikroarchitektur [Otto13] wird die Grundlage geschaffen, Services isoliert zu entwickeln, zu testen und letztendlich auch zu deployen.
Für die Makroarchitektur (Vertikalen übergreifend) gelten folgende Prinzipien:
- vertikaler Systemschnitt,
- Shared Nothing,
- RESTful Architecture.
Für die Mikroarchitektur (in der Verantwortung der Vertikalen):
- Buy when not core,
- gemeinsame Basistechnologien.
Doch welche Rolle nehmen in diesem Veränderungsprozess die Testmanager bei uns ein? Als nächsten Schritt werden die Testmanager in die Teams integriert und sind wie Fachspezialisten und Entwickler ein vollwertiges Teammitglied. Neben ihren klassischen Aufgaben wie der Testfallerstellung und -durchführung, der Auswahl geeigneter Testwerkzeuge oder der Testmittelbeschaffung sind Testmanager ab jetzt auch wichtiger Inputgeber bei der Erstellung von User-Storys, um zum Beispiel die Testbarkeit neuer Funktionalität von Beginn an mit zu berücksichtigen. Darüber hinaus streuen sie ihr Qualitäts- und Test-Know-how im gesamten Team, um die Qualität der Software nachhaltig zu verbessern. Die Entwicklungsteams des Online Shops sind bei OTTO überwiegend in die sogenannten Vertikalen geschnitten. Kasten 1 gibt einen Überblick über diesen ersten Schritt. Dadurch wird die Unabhängigkeit der Teams weiter gestärkt und der manuelle Testaufwand reduziert.
Kasten 1
Kasten 2
Kasten 3
Abb. 2: OTTO Konzernzentrale
Schritt 2: Sukzessive Einführung von Microservices
Der erste Schritt ist geschafft und dafür waren einige Klimmzüge für die Organisation notwendig. Aber am Ziel sind wir auch noch nicht angekommen. Die Deployments dauern mit ca. 40 Minuten immer noch zu lange und es sind viele manuelle Testaufwände notwendig, bevor die Software guten Gewissens live geschaltet werden kann.
Im zweiten Schritt haben sich die Teams daher entschieden, ihre Services überwiegend mit Microservices zu realisieren. Dabei werden marktübliche Tools wie Docker, Mesos und Marathon verwendet. Außerdem wird in den Vertikalen deutlich stärker in die Ausweitung der Testautomatisierung auf allen Testebenen der Testpyramide [Fow12] investiert. Dadurch wird die Unabhängigkeit der Teams weiter gestärkt und die manuellen Testaufwände werden reduziert.
Die Testmanager haben in Schritt 2 ihren Wirkungskreis im Rahmen des Story-Lifecycles ausgeweitet. Sie sind nicht nur am Anfang und am Ende beteiligt, sondern tragen bei jeder Station der Story einen wichtigen Teil zur Zielerreichung bei. Für die Umsetzung kann dies beispielsweise bedeuten, dass sie aktiv ins Pairing mit den Entwicklern gehen, um gemeinsam hochwertige und gut getestete Software zu kreieren. Auch selbstständig einen Unittest zu schreiben, ist keine Seltenheit mehr. Die Aufgaben der „klassischen“ Testmanager haben sich so stark verändert, dass wir bei otto.de nun von Quality Specialists [Otto16] reden.
Rollenverständnis Quality Specialist:
- Wir agieren als Quality Coach.
- Wir begleiten den kompletten Story-Lifecycle.
- Wir treiben Continuous Deployment.
- Wir balancieren die unterschiedlichen Testarten der Testpyramide.
- Wir helfen dem Team, gängige Methoden für hohe Qualität einzusetzen.
- Wir sind im Pairing aktiv.
- Wir sind Kommunikationstalente.
- Wir vertreten unterschiedliche Perspektiven.
Schritt 3: Hello Cloud
Mit wachsender Bedeutung des Online Shops für das Geschäft von OTTO und der damit steigenden Zahl an Visits auf otto. de scheint die Migration in die Cloud rückwirkend wie der nächste natürliche Schritt. Für einen Konzern wie OTTO ist dieser aber weder leicht noch unumstritten. Da 2018 der Vertrag mit dem lokalen Rechenzentrum ausläuft und der Wunsch nach infrastruktureller Skalierbarkeit besteht, hat sich das Unternehmen letztendlich der Herausforderung gestellt, sämtliche Systeme des Online Shops in die Cloud zu migrieren. Dazu wurde im Vorfeld ein Vergleich aller großen infrage kommenden Cloud-Services vorgenommen. Nachdem die Grundpfeiler beschlossen sind, geht alles ganz schnell. Innerhalb eines Jahres, ab Beginn der intensiven Evaluationen wird der gesamte Online Shop mit allen Fachlichkeiten in die Cloud migriert. Auch die Tatsache, dass nebenbei noch andere „Kleinigkeiten“, wie die EU DSGVO, umgesetzt werden, hat den ambitionierten Zeitplan nicht zu Fall gebracht.
Durch die Akzeptanz und Verbreitung von Microservices sind die Voraussetzungen für eine erfolgreiche Migration günstig. Das Projekt kann ohne größere Probleme umgesetzt werden. Mittlerweile sind die meisten Teams zu Continuous Deployment übergegangen, was die Aufrechterhaltung der Fachlichkeiten trotz Migration mit einem überschaubaren Risiko ermöglicht. Vorhandene Consumer-Driven Contracts (CDCs) werden weiter ausgebaut, wodurch der Testaufwand in der Integration weiter reduziert wird. In der Folge wird eine komplette Testumgebung eingespart und der Deploymentprozess weiter vereinfacht und beschleunigt.
Mit der Cloud steht OTTO nun ein flexibler und hochskalierbarer Shop zur Verfügung. Mit diesem erhoffen wir uns, Lastspitzen erfolgreich bewältigen zu können.Neben den bereits angesprochenen Einflüssen auf die gesamte Organisation hat sich speziell im E-Commerce einiges geändert. In der Zeit der Migration ist die Entwicklung neuer Fachlichkeiten auf ein Minimum reduziert und die Wünsche der Fachbereiche müssen warten. Die Entwickler arbeiten sich in teils komplett neue Gebiete ein und widmen sich anfangs überwiegend Infrastrukturthemen. Mit der Migration gewinnen die Teams weiter an Selbstständigkeit. Sie müssen sich nun noch stärker Gedanken über Kritikalitäten und Betriebsverantwortung machen.
Für unsere Quality Specialists ergeben sich aus dem oben Beschriebenen folgende Dinge. Die Tatsache, dass anfangs weniger Fachlichkeiten umgesetzt werden, schafft Zeit, den Fokus auf die Aufrechterhaltung der Qualität vorhandener Software und der Ausarbeitung von Testkonzepten für die Cloud zu entwickeln. Relevant ist bei dieser Neuausrichtung die beschränkte eigene Möglichkeit, Fehler zu korrigieren. Konnte früher die Software noch selbst bei Bedarf in Minuten repariert werden, ist dies bei genutzter Cloud-Software nicht mehr der Fall. Die Cloud kann den Quality Specialists einiges an Arbeit abnehmen, schafft aber auch neue Dimensionen von Fragestellungen. Hier gilt es, klar abzuwägen und die neuen Möglichkeiten zu nutzen.
Fazit
Die Metamorphose von Testmanagern hin zu in Teams fest verankerten Quality Specialists hat sich über Jahre gestreckt. Die Rolle wird derzeit, je nach Bedürfnis des jeweiligen Teams, mit Testspezialisten, Entwicklern oder Quereinsteigern gleichermaßen besetzt. Auf dem beschriebenen Weg haben wir als Organisation viele verschiedene Keyfindings in Bezug auf das agile Testen gemacht. Einer davon ist, dass jedes Team seinen eigenen Weg zu guter Softwarequalität geht. So gibt es beispielsweise Teams, in denen ein spezialisierter Testautomatisierer benötigt wird, aber ebenso auch solche, in denen mehr Bedarf an einem explorativen Tester besteht. Wichtig ist, dass alle Quality Specialists in der Lage sind, die Qualitätswerte zu leben und in die Teams zu tragen.
Als besonders lohnenswert hat sich darüber hinaus die Etablierung einer offenen Fehlerkultur gezeigt. Live Bugs, die zu Ausfällen des Shops führen, werden umgehend korrigiert und analysiert. Die Erkenntnisse werden aufgearbeitet und an einen großen Adressatenkreis geteilt. Daraus können wiederum andere Teams lernen und derartige Fehler vermeiden. Als weiteren Punkt hat sich die Einführung einer Community of Practice (CoP) mit dem Fokus auf agiles Testen und Qualitätssicherung bewährt. Durch die unterschiedlichen Skills der Quality Specialists findet eine guter Austausch der ansonsten dislozierten Quality Specialists statt. Neben einer besseren Vernetzung können beispielsweise teamindividuelle Problemstellungen gemeinschaftlich diskutiert und gelöst werden. Auf der aktuellen Agenda stehen mit Multi-Cloud, Security und Ausbau zur Plattform [Otto18] weitere große Themen vor der Tür. Für die Quality Specialists ist dies ebenso eine Herausforderung wie für den Rest der Organisation. Sie lernen mit Veränderungen umzugehen, neue unkonventionelle Lösungen zu finden und den Mut, Dinge auszuprobieren.
Referenzen
[Fow12]
M. Fowler, TestPyramid, 1.5.2012, siehe:
https://martinfowler.com/bliki/TestPyramid.html
[Otto13]
G. Steinacher, Architekturprinzipien, Otto, 14.4.2013, siehe:
https://dev.otto.de/2013/04/14/architekturprinzipien-2/
[Otto16]
N. Volk, F. Lorbeer, D. Kruse, T. Mangner, Sind wir wirklich nur Testmanagerinnen?, Otto, 8.6.2016, siehe:
https://dev.otto.de/2016/06/08/sind-wir-wirklich-nur-testmanagerinnen/
[Otto18]
Ch. Finckler, Otto’s Weg zur Plattform, Otto, 3.5.2018, siehe:
https://dev.otto.de/2018/05/03/ottos-weg-zur-plattform/
