Mehr Inhalte dieses Speakers? Kein Problem, schaut doch mal bei sigs.de vorbei:
https://www.sigs.de/autor/thomas.much

Tester werden in agilen, crossfunktionalen Teams zunehmend zu Qualitäts-Spezialisten und -Moderatoren und arbeiten gemeinsamen mit den Entwicklern an der Testautomatisierung auch auf den unteren Teststufen. Es ist also wichtig, dass Tester nicht nur die Test-Grundlagen kennen und vermitteln, sondern auch die Herausforderungen bei der Programmierung verstehen: Wann Code bzw. die Komponenten einer Anwendung gut automatisiert testbar sind - und was dem häufig im Wege steht. In diesem Vortrag zeige ich mit einfachen Beispielen, wie man eine gute Testbarkeit im Code-Design und in der Architektur erreicht: Durch das Beherrschen von Abhängigkeiten.

Zielpublikum: Tester, Testmanager, Entwickler, Architekten
Voraussetzungen: Erfahrungen mit dem Schreiben von Code und automatisierter (Unit-)Tests sind hilfreich, aber nicht erforderlich
Schwierigkeitsgrad: Basic

Extended Abstract:
Tester werden in agilen, crossfunktionalen Teams zunehmend zu Qualitäts-Spezialisten und -Moderatoren. Dabei arbeiten sie gemeinsamen mit den Entwicklern an der Testautomatisierung auch auf den unteren Teststufen. Es ist also wichtig, dass Tester nicht nur die Test-Grundlagen kennen und vermitteln, sondern auch die Herausforderungen bei der Programmierung verstehen: Wann Code bzw. die Komponenten einer Anwendung gut automatisiert testbar sind - und was dem häufig im Wege steht. In diesem Vortrag zeige ich mit einfachen Beispielen, wie man eine gute Testbarkeit im Code-Design und in der Architektur erreicht: Durch das Beherrschen von Abhängigkeiten. Ziel dieser Session ist, dass man als Tester Impulse bzw. erste Anregungen bekommt, wie man Softwareentwicklungsteams durch geeignete Fragen und Ideen unterstützen kann, damit Testen und Testbarkeit ein nachhaltiger, integraler Bestandteil der gemeinsamen Arbeit ist.

Auf welchem Hintergrund entstand dieser Vortrag, warum liegt der Fokus auf Testbarkeit von Code-Design und Architektur? Bei meiner Arbeit mit zahlreichen Teams habe ich während der letzten Dekade ein wiederkehrendes Muster beobachtet: Teams mit guter, schneller Testautomatisierung liefern oftmals bessere Lösungen kontinuierlicher ab - und arbeiten dabei oft auch sehr gut rollenübergreifend zusammen. Aber warum erreichen manche Teams eine gute Testautomatisierung, während sich andere damit über Jahre abmühen?

Meiner Erfahrung nach hängt dies davon ab, ob der Code einfach testbar ist. Das hat positive Auswirkungen nicht nur auf die unteren (Unit-)Teststufen, sondern erleichtert meist auch das Testen auf höheren Stufen. Gerade bei Unit-Tests denkt man dann sofort an Programmierpraktiken wie Test-Driven Development (TDD), durch die ein besseres - besser testbares! - Code-Design entsteht. Aber darum soll es in diesem Vortrag nicht (oder nur ganz am Rande) gehen. Denn es gibt auch einige Architekturstile bzw. -muster, die ein einfacheres Testen mit schnelleren Feedback-Schleifen ermöglichen. Und das ist nicht nur für Entwickler interessant, sondern auch für andere Rollen wie beispielsweise Tester.

Wir schauen uns in dieser Session an, was es bedeutet, Geschäftslogik von Integrationscode zu trennen, welche unterschiedlichen Code-Designs und Architekturmuster es gibt, um dieses Ziel zu erreichen - und warum damit kleinere und schnellere automatisierte Tests möglich sind. Es geht dabei um die absoluten Grundlagen von testbarem Code und testbarer Architektur. Wer sich nicht täglich mit diesen Themen beschäftigt, wird Anregungen und Tipps bekommen, worauf es sich bei der täglichen Arbeit zu achten lohnt.

Die gezeigten Beispiele bestehen aus einfachem, sprachunabhängigem Pseudo-Code und einfachen Architekturdiagrammen.