QConf 2016 Hamburg Recap (Qualitätskonferenz)

Gestern und heute fand die QConf 2016 bei Otto in Hamburg stand. Hierbei ging es um alles rund ums Thema Qualität: Was sind Microservices? Was muss ich mitbringen, um Quality Specialist zu sein? In welchem Teil der Testpyramide stecken welche Tests? Die Organisation war, wie im letzten Jahr auch schon, super, danke nochmal an Diana. Die Location war klasse, das Essen lecker und die Zeiten für Pausen und Gespräche ausreichend. Kommen wir nun zu meiner Zusammenfassung der Talks:

Welche Softskills brauche ich um Qualität voran zu treiben?

Mihaela Manolescu & Torsten Mangner & Peter Grunwald
Zu allererst sollte man darauf achten, dass die Qualität von Beginn an in die Prozesse eingebunden wird. Man sollte direkt am Anfang eines Projektes definieren, welche Tests geschrieben werden sollen. Neue Features sollten mit einem Toggle versehen werden, sodass man sie schnell wieder rückgängig machen kann, wenn bei einem Deployment etwas schief gehen sollte.

Wenn man agil unterwegs sein möchte, dann sollte man Continuous Deployment betreiben. Damit können Features schnell live gehen, wodurch ein direktes Feedback erfolgen kann, was man im Anschluss umsetzen sollte. Jede Zeile Code sollte testbar und auch getestet sein. Sollte man einen Fehler finden, schreibt man bestenfalls direkt einen Test dafür (Stichwort: TDD – test driven design), damit dieser nicht wieder auftaucht. Am besten setzt man dabei auf 100% automatisierte Regressionstests. Insgesamt sollte es so wenige Dinge wie möglich geben, die man manuell testen muss. Damit hat man einfach mehr Zeit für andere Dinge und die Fehleranfälligkeit ist geringer. Natürlich gibt es auch einige Dinge, auf die man manuell schauen sollte – z.B. die Oberfläche und die Funktionen auf verschiedenen Devices, um auf Nummer sicher zu gehen.

Pro Team gibt es unterschiedliche Anforderungen, so sollte es auch jeweils einen Quality Specialist geben, der sich um die Qualität des Produkts kümmert. Ein Monitoring, am besten durch automatisierte Tests und passende Metriken, sollte eingerichtet werden, um die wichtigsten Bereich immer im Auge zu haben. Dazu sollte es ein Alerting geben, welches dann auch an die richtige Person gesendet wird.

Ein Testmanager sollte technisches Know-How mitbringen und Programmierkenntnisse besitzen. Er sollte ein Kommunikationstalent sein, um mit verschiedenen Abteilungen reden und eine Schnittstelle sein zu können. Weiterhin sollte er Tests definieren und im besten Fall auch automatisieren können. Um immer auf dem neuesten Stand zu sein, sollte er sich außerdem ständig weiterbilden.

World Café

Dieser Teil war eine große Diskussionsrunde in Teams. Man wurde wild zusammengewürfelt per Losverfahren und es gab sechs Themen, zu denen man sich austauschen konnte. Hier die Ergebnisse:

Noch bin ich in keinem crossfunktionalen Team unterwegs. Was für Herausforderungen erwarten mich und wie begegne ich diesen?

Zwischenmenschlich:

Einstellung im Kopf anpassen
gemeinsames Verständnis / Akzeptanz
gemeinsame Sprache finden
Lernbereitschaft zeigen
gemeinsame Ziele setzen

Organisatorisch:

früher getrennte funktionale Teams – Denkweise ändern
ständige Kommunikation notwendig
wie organisieren sich die Teams?
bessere Doku schreiben
Tools als Unterstützer sehen
thematische Teams bilden

Vorteile:

bessere Kommunikation / gemeinsames Verständnis
alle Aspekte in ganzem Prozess betrachten
mehr Inspiration
direkte Kommunkationswege

Nachteile:

wichtige Sachen ggf. nicht genug dokumentiert
keine Unterscheidung zwischen Testern und Entwicklern
Integration schwer für Teammitglieder
reichen die eigenen Skills? Sind wirklich alle Spezialisten?

Pairing soll ich machen, muss das sein? Was heißt das eigentlich und wie kann ich das am besten lernen?

Es kann sein, dass einige Angst vor dem Pairing haben, da sie befürchten, überwacht zu werden. Sie könnten es als Zeitfresser sehen und Angst um die Außenwirkung haben (es sieht aus, als ob nur einer arbeitet und der andere Däumchen dreht). Dafür ist eine Teamkultur notwendig und man sollte versuchen, zusammen etwas Tolles zu erarbeiten und Feedback für seine Arbeit zu erhalten.

Das Pairing ist eine gute Sache, denn es steigert die Qualität und Codereviews sind nicht mehr so nötig, da nach dem Vier-Augen-Prinzip gearbeitet wurde. Dadurch wird der Code insgesamt auch besser, da man sich über diesen austauschen kann. Dadurch, dass nun mehr Know-How zur Verfügung steht, spart man Zeit und es wird insgesamt auch viel weniger Inselwissen aufgebaut, da man gemeinsam an Aufgaben arbeitet. Man sollte es also einfach machen.

Wie, ich muss jetzt Code lesen können? Wozu und ich wie kann ich mir das aneignen?

Wenn man als Qualitätsmanager Code lesen kann spricht man eine gemeinsame Sprache mit den Entwicklern und wird von diesen auch ernster genommen, da man weiß, wovon man spricht. Man bekommt selber ein besseres Verständnis für deren Arbeit und kann auch selber bessere Tests schreiben, weil man weiß, was dahinter steckt. Man kann die Entwickler unterstützen und sich dabei selber weniger Arbeit machen, indem man automatisierte Tests selber schreibt. Ein weiterer Pluspunkt ist, dass es gut auf dem Lebenslauf aussieht.

Lernen kann man das Code lesen durch Bücher oder das Internet und indem man Seminare besucht. Eine weitere sehr gute Methode ist das Pairing, damit kommt man auch noch mehr in den Kontakt mit seinen Kollegen.

Was vielleicht dagegen sprechen könnte, ist, dass es sein kann, dass Entwickler gar nicht wollen, dass man in ihrem Code herumpfuscht. Außerdem könnte man vom Code beim Test schreiben beeinflusst werden. Wenn dem Qualitätsmanager die Motivation dazu fehlt oder dieser vielleicht gar nicht dazu fähig ist, Code zu lesen, dann bringt es auch nichts, Zeit dazu zu investieren, ihn anzulernen.

Alle reden von Testautomatisierung, ich bin froh, wenn meine Entwickler Unittests schreiben. Wie kann man Leute überzeugen, dass Qualität eine gute Sache ist?

Die Automatisierung von Tests dient als Frühwarnsystem. Es kann immer passieren, dass wenn man an einer Stelle etwas baut, man damit an einer anderen Stelle etwas kaputt macht. Diese Fehler kann man damit schneller finden und beheben und es gibt weniger Bugs im Livegeschäft. Außerdem kann man entspannter arbeiten, da nicht mehr der große Druck besteht, dass bei einem zu spät bemerkten Fehler Geld verbrannt wird.

Insgesamt braucht man dann viel weniger Zeit für das Bugfixing und die Sicherheit und die Stabilität des Produktes sind höher. Man kann die Kosten, die während des Behebens von Bugs entstehen, nun besser nutzen. Auch wenn man initial etwas Zeit benötigt, um die Tests aufzusetzen, ist im Nachhinein alles viel einfacher und schneller.

Testfälle in einem Testmanagementtool erfassen und pflegen, ist das eigentlich noch state-of-the-art und wie kann ich das vielleicht anders lösen?

Das ist ganz abhängig vom Umfeld und damit von der Teamgröße/-verteilung, dem Entwicklungsmodell, den Ressourcen und der Größe des Testgegenstands. Anforderungen an ein Tool wären eine gute Dokumentation, eine bewertbare Testabdeckung und das Defectmanagements. Alternativen zu Testmanagementtools wären Mindmaps, Excel, Jira.

Wie tief muss ich eigentlich in die Fachlichkeit einsteigen? Werde ich dann zum Anforderer?

Dies ist ganz abhängig von den technischen und geschäftlichen Rahmenbedingungen und der Flughöhe. Bei der Testqualität und dem Verständnis von Anforderungen hilft es auf jeden Fall. Außerdem hat man dann eine gemeinsame Sprache mit dem Team. Man sollte sich nicht als Anforderer, sondern als Berater sehen, denn Wissen ist Vorteil.

Wie kann HP ALM Octane als Testwerkzeug bei uns eingesetzt werden?

Henning von Ketelhodt

Es gibt keine „out of the box“ Lösung und es stimmt auch nicht, dass es kein zentrales Applikationsmanagement für verschiedene Werkzeuge geben kann. HPE Alm Octane ist ein Application Lifestyle Management, das Tests, Entwicklung und Versionierung an einem Ort verwaltet. Open Source wie GIT, Gherkin, Jenkins und Selenium kann angebunden werden. Es ist eine zentrale Anlaufstelle für Tester und Entwickler und alle Parteien werden in den Fehlerbehebungsprozess und damit zur Sicherung der Qualität eingebunden. Man sollte sich allerdings überlegen, wie man seine Tickets dort hin bekommt und die Defects zurück und ob es das Richtige für die eigenen Tools ist. Man sollte abwegen, ob man genug Ressourcen dafür hat und ob die Kosten ihren Nutzen wert sind.

Der Cycle bei agilen Projekten ist planen, definieren, bilden, testen, tracken. Beim Planen/Definieren geht es darum, die Fortschritte der Stories des Sprints zu bestimmen, Tests zu planen, den Workflow zu skizzieren und Änderungen zu erfassen. Beim Bilden stellt man die Pipeline grafisch dar (Jenkins) und verbindet die Tests mit den App-Modulen. Das Testen ist für das Durchführen von automatisierten Tests, das Schreiben und Einbinden von Tests sowie ein Alerting z.B. per Mail bestimmt. Beim Tracken sollte man Fehler erfassen, ein Reporting erstellen und Prios hervorheben.

Vorteile:

1 Werkzeug
zentral
komplette Infrastruktur
Sync möglich
für agile Teams

Nachteile:

Aufwand für Sync
Kosten
Migration?
keine Erfahrung?

11 Microservices müsst ihr sein – Testmethoden, Testarten und Teststufen

Dirk Hilburger

Zu Beginn sollte man ein Szenario überlegen. Was möchte ich erreichen? Wer oder was nimmt daran teil? Wie kann man das schaffen?

Zu den Teststufen gehören:

Programmierung
Komponententests (z.B. Microservices)
Integrationstests (Schnittstellen zwischen Systemen)
Systemtests (funktioniert das System)
Abnahmetests

Bei den Testarten unterscheidet man in Blackbox- und Whitebox-Methoden. Blackbox-Methoden sind funktionale (meist manuelle, sogenannte „klicky bunty“ Tests) und nicht funktionale Tests (Last, Performance, Security). Whitebox-Methoden sind strukturbasierte Tests (Codeanalyse, Codeabdeckung, Pfadabdeckung) und änderungsbezogene Tests (Regressiontests).

Die Testmethoden sind folgende:

Äquivalenzklassenbildung: gültige/ungültige Wertebereiche definieren und einige davon testen
Grenzwertanalyse: Erweiterung der Äquivalenzklassenbildung
Entscheidungstabellentests: bei ganz komplexen Systemen mit vielen Testarten / Kombinatorik
anwendungsfallbasierte Tests: Use Cases
zustandsbasierte Tests

Workshop: Wie bekomme ich die richtige Zuordnung in die Testpyramide hin?

Jan Kelb

Es gibt je Unternehmen verschiedene Modelle und Definitionen der Teststufen. Am wichtigsten ist es daher, die Testfälle für sich zu definieren und durchzuführen und sich dabei nicht strikt an Modelle zu halten. Die User-Stories, die man erarbeitet, haben bestimmte Akzeptanzkriterien, ohne die die Stories nicht erfüllt sind. Diese Kriterien muss man testen und die Tests können dabei in die Testpyramide eingeordnet werden. Unten stehen dabei Unittests, bei denen die einzelnen Komponenten getestet werden. Es folgt der Bereich „Services“, wo das System und die Integration in dieses getestet werden. Darauf folgen UI-Tests und ganz oben stehen Abnahmetests.

Testarten können sein: Security-Tests, Unit-, Funktions- oder Schnittstellentests, Usabilitytests, Code Analyse, Code Review, Smoke Tests (Strom anmachen und schauen, ob es irgendwo brennt), Migrations-, Komponenten-Integrations- und explorative Tests. Nicht funktionale Tests sind Tests zur Performance (z.B. Antwortzeit), Last (skalierte Tests) und Stresstests (Peaks herstellen).

Was haben wir aus dem Workshop mitgenommen?

häufig von oben anfangen und dann nach unten denken (eventuell themenabhängig)
Microservices werden anders getestet
User Story bestimmt, wie man über das Testing nachdenkt
UI auch auf Unittestebene testbar (z.B. Template-Tests)
Umfang von E2E Verständnis sehr variabel, Zuordnung von Teststufen braucht Bezug
nicht zu dogmatisch sein (aber auch nicht beliebig)
Kommunikation und Abstimmung sind wichtig

Was sind Microservices?

Guido Steinacker

Monolithen sind sehr groß und komplex und es bedarf zu vieler Prozesse. Der Kommunikationsaufwand ist enorm und eine Skalierbarkeit ist schwierig. Es muss allerdings nicht nur eine Applikation sein für die gesamte Webseite, man kann diese auch aufdröseln und in mehrere Applikationen aufteilen, in dem man mit Bausteinen arbeitet (z.B. Header, Navi, Inhalt, Footer). Die Vertikalen müssen allerdings synchronisiert werden. Ziel davon ist es, unabhängig voneinander deployen zu können. Störungen gehören dazu und sind nicht vorhersehbar, bei Ausfall eines Features sollte der Rest der Seite weiterfunktionieren. Damit können Fehler schneller behoben sein. Diese self-contained-systems sind unabhängige Web-Anwendungen, die sich keinen Code teilen und asynchron kommunizieren.

Microservices sind also:

separate Prozesse
Teil eines distributed Systems
fachlich geschnitten
1 Fachlichkeit / Service
unabhängig deploybar
lose gekoppelt
mit eigenen Daten versehen

Hier findet ihr einen Artikel, der noch näher auf Monolithen und Microservices eingeht.

Wie testet man Microservices?

Finn Lorbeer

Microservices leben selten allein und werden für sich alleine getestet. Allerdings darf man nicht vergessen, auch die Integration mit anderen zu testen. Man sollte das ganze System als eins betrachten und kann zum Testen Tools wie Appium, Selenium, Cucumber, Gherkin oder Nightwatch nutzen. Man muss sich zu Beginn gut überlegen, welche Features in welchen Service gehören und generell wissen, was man tut. Um eine hohe Qualität gewährleisten zu können, sollte man schon früh anfangen zu testen und das Testing am besten auch mit anderen zusammen testen und darüber kommunizieren. Wenn man gemeinsam als Team testet, erhält man die besten Ergebnisse. Wie consumer driven contract tests und das Testen mit der Testpyramide funktioniert, findet ihr in meinen Sketchnotes von dem Vortrag nochmal visuell verdeutlicht:

Wie kommt man vom Wasserfall- zum agilen Vorgehen?

Christian Cramer

1. Technische Voraussetzungen schaffen:

continuous delivery
test driven development

2. Organisatorische Voraussetzungen schaffen:

Produktmanagement einrichten (crossfunktionale Produktteams, business services)
Schulungen
gemeinsame Taktung (Sprints, Supersprints)
Abhängigkeiten zwischen Teams identifizieren
Transparenz schaffen

3. Haltung anpassen:

agiles Manifest
hilfreiche Leitplanken setzen
harte und kontinuierliche Arbeit in der Umsetzung: am Ball bleiben

Insgesamt ist es wichtig, dass man sich permanent austauscht und gut zusammenarbeitet. Selbstverantwortliches Arbeiten sollte gefordert und gefördert werden. Die Feedback-Schleifen sollten so kurz wie möglich gehalten werden (continuous integration und deployment). Die Performance-Messung sollte objektiv erfolgen (wo stehen wir und werden wie besser?). Am besten macht man dafür Retrospektiven, um sich stetig verbessern zu können.

Qualitätssicherung als die treibende Kraft in Richtung von continuous deployments

Finn Lorbeer

„Einige unerwartete schlimme Dinge werden passieren“ (Dan North)

Es ist unvermeidlich, dass schlimme Dinge passieren werden. Man sollte daher dafür sorgen, dass der Effekt so klein wie möglich ist. Dies schafft man mit Hilfe von Microservices. Wenn schlimme Dinge passieren, stirbt nicht die ganze App, sondern nur ein kleiner Teil. Die Voraussetzungen dafür sind, dass neue Services ganz einfach aufzusetzen sein müssen, es ein gutes Monitoring gibt und Deployments schnell durchlaufen können.

Was kann man als Testmanager tun? Prozess definieren? Nein, denn einen Prozess definieren, per Mail rumschicken und hoffen dass es klappt funktioniert nicht. Die Technologie dafür bereitstellen? Nein, das machen die Entwickler. Eine Kultur der Qualität erschaffen? JA! Testmanager sind analytische Köpfe und schaffen es durch Coaching und permanentes Lernen ihr Wissen weiter zu vermitteln. Außerdem können sie ihr Team motivieren und zu Challenges anstacheln. Man sollte im Unternehmen ein Quality Mindset erstellen, damit alle von Anfang an an die Qualität denken und sie nicht erst am Ende draufgesetzt wird. Dazu gibt es einen sehr interessanten Artikel auf dem Otto Entwickler Blog.

Das Ziel sollte es sein, öfter zu deployen und damit ein risikoärmeres Deployment zu haben. Das funktioniert, wenn Microservices eingeführt werden. Der typische Ablauf beim Entwickeln eines Features läuft so ab: build -> test-server -> smoke-test -> test-suite -> monitor -> alert -> go-live -> test-suite

Diese Schritte kann man alle automatisieren und damit eine flexible Applikation erschaffen werden, die einfach zu verändern ist, der Feature schnell hinzugefügt werden können und die eine kurze cycle time und eine hohe Qualität hat. Dazu gibt es einige Open Source Anwendungen, die helfen können:

Gatekeeper (Reihenfolge der Deployments, Zeiten des Starts)
Lineup (Screenshots vor Deployment mit Screenshot nach Deployment abgleichen)
Lambda CD (Pipelines als Code erstellen)

Insgesamt war es eine sehr interessante Konferenz mit vielen spannenden Inputs. Trotz der Hitze haben auch noch alle bis zum Ende durchgehalten, was auf jeden Fall für die Speaker und die Themen spricht 🙂

QConf 2016 Hamburg Recap~ 13 min.