Im November habe ich mit meinem Kollegen Andrej Thiele an den Agile Testing Days 2020 teilgenommen. Die Agile Testing Days sind eine der bekanntesten Konferenzen im europäischen Raum zum Thema Testing und insbesondere Agile Testing. Wie alle Veranstaltungen im Corona-Jahr fand auch diese Konferenz vollständig remote und online statt. Die Beiträge wurden dabei über CrowdCast zu den Teilnehmern gestreamt, die dann über Chat oder im Anschluss auch über Video miteinander in Austausch treten konnten.
Psychological Safety
Eines der beherrschenden Themen in der Testing-Community und im Grunde in der gesamten Softwarreentwicklungs-Community ist die „psychological safety“. Unter dem Begriff versteht man eine (Arbeits-)umgebung, in der Teammitglieder Fehler begehen und einräumen können, ohne dafür Verurteilung oder Benachteiligung von ihren Peers befürchten zu müssen.
Inzwischen besteht Konsens, dass psychological safety eine wichtige Voraussetzung für Hochleistungsteams ist. So fand das Thema in mehreren Keynotes und auch in einigen Beiträgen bei den Agile Testing Days Einzug. Man gewann den Eindruck, dass es gerade in Zeiten der Pandemie noch einmal an Bedeutung gewonnen hat, da viele auf die eine oder andere Weise unter der Kontaktreduktion leiden. Für mich war psychological safety eines der beherrschenden Themen bei der Veranstaltung.
How to tell it to the Tester…
Mein Kollege Andrej Thiele hat in seinem Beitrag mit dem Titel „How to tell it to the Tester…“ seine Ergebnisse aus vielen Gesprächen und Befragungen in echten Projektsituationen präsentiert. Dabei hat er sich dem oftmals leider spürbaren „Gap“ zwischen Entwicklern und Testern gewidmet – immer wieder erleben wir nämlich, dass eher „gegeneinander“ und weniger „miteinander“ gearbeitet wird.
Tatsächlich vereinen wir oft in unseren Projekteinsätzen die beiden Rollen, da wir testgetrieben entwickeln. In jedem Fall liegt der Schlüssel zur konstruktiven Zusammenarbeit in der Kommunikation zwischen den Parteien. Mit Verständnis der zu Grunde liegenden Kommunikationsmodelle und dem ein oder anderen Werkzeug aus dem Kommunikationsmethodenkoffer können beide Seiten zu einer wertschöpfenden Zusammenarbeit beitragen.
Testing is not the goal!
Nachhaltig beeindruckt hat mich Rob Meaney mit seiner Keynote „Testing is not the goal!“. Ich teile seine Einschätzung, dass das Testen von Software schon lange kein Selbstzweck mehr ist und sich auch längst nicht mehr auf Unit- oder Integrationstests beschränkt. Vielmehr muss in zeitgemäßer Softwareentwicklung ein ganzheitlicher Testing-Ansatz verfolgt werden, der den gesamten Softwarelebenszyklus abdeckt. Dieser beginnt zwar mit der Konzeption und Implementierung, endet dort aber nicht, sondern erstreckt sich über das Deployment bis in den Betrieb. Themen wie CI/CD, Testability, Operability und Observability sind bei modernen, verteilten Systemen von unschätzbarer Bedeutung.
Zum einen bedeutet dies in der Konsequenz natürlich, dass sich Tester mit neuen Konzepten, Tools und Vorgehensweisen auseinandersetzen müssen. Aber auch klassische „Developer“ sind gefragt, sich der neuen An- und Herausforderungen im Testing anzunehmen.
End-to-end testing microservices
In meinem eigenen Beitrag habe ich anhand konkreter Projekterfahrungen meine Sicht auf Ende-zu-Ende-Tests für Microservices geschildert. Denn Microservices sind noch immer in aller Munde. Sie sollen autark entwickelt, ausgeliefert und deployed werden. In der Realität können sie aber fast immer nur in Kombination sinnvoll benutzt werden.
Aus der Perspektive des Softwaretesters ist die Sache daher klar: wir wissen aus Erfahrung, dass Softwarekomponenten, die miteinander interagieren, auch integriert getestet werden müssen. Jeder musste sicher einmal die schmerzliche Erfahrung machen, dass es an dieser Stelle nicht genügt, eine einzelne Komponente in Isolation zu testen, um sicherzustellen, dass die Komponenten auch im Zusammenspiel sauber funktionieren.
Ein weiterer Vorteil von Microservices besteht in der hervorragenden Tauglichkeit für CI und insbesondere CD. Hier werden sämtliche Teststufen vollständig automatisiert in einer CI/CD-Pipeline durchlaufen. Wenn nun aber die E2E-Teststufe fehlschlägt, dann ist die Auslieferung von allen(!) beteiligten Microservices blockiert, bis die Ursache identifiziert und behoben ist!
An dieser Stelle zeigt sich der Widerspruch zwischen dem Ziel, über E2E-Tests die Qualität der Software sicherzustellen und dem Ziel, schnell und unabhängig einzelne Komponenten ausliefern zu können.
Ausblick auf 2021
Insgesamt herrschte bei den Agile Testing Days trotz des Remote-Formats eine herzliche und freundschaftliche Atmosphäre und gerade die Interationalität trägt enorm zum Charme der Veranstaltung bei. Für Testing-Interessierte sicherlich eine äußerst empfehlenswerte weil einsichts- und lehrreiche Konferenz. Wir freuen uns auf die kommende Ausgabe in 2021.
Unsere Beiträge sind übrigens so wie das gesamte Programm weiterhin über das Konferenztool CrowdCast online einsehbar. Zudem wurde ich aufgrund der sehr interessierten und positiven Resonanz zu meinem Beitrag zusätzlich zu dem Thema bei InfoQ interviewed. Und schließlich gibt es den Beitrag bald auch nochmal auf deutsch bei der kommenden JavaLand sowie den German Testing Days 2021. Ich würde mich freuen, den/die eine(n) oder andere(n) Leser(in) dort zu treffen!
