Des DevOps Kern: Wie hältst du’s mit der Agilität?

Auch im Jahr 2021 hat SwissQ wieder die Trends & Benchmarks im Quality Engineering veröffentlicht. Zum Thema des Vorgehensmodells antworteten mehr als die Hälfte der Befragten, dass sie ein hybrides Modell fahren. Die spannende Frage ist nun: was heisst denn hybrid? Wie lassen sich Wasserfall und Agilität oder gar DevOps in einem Konstrukt vereinen? In diesem Blog möchte ich über meine ganz persönlichen Erfahrungen schreiben rund um das Thema Testing im Kontext Agilität und DevOps und wieso ein Wasserfall ein Wasserfall bleibt, auch wenn man ihn in Sprints schneidet.

Im Vergleich dazu gibt es auch die Trends & Benchmarksanalyse im QE für das Jahr 2023.

Eine Kette ist nur so stark wie ihr schwächstes Glied

Mit unserem Test Driven DevOps Poster haben wir bei der SwissQ das Thema Testing im Umfeld von DevOps genauer beleuchtet. Betrachten wir die klassische Darstellung der DevOps Tätigkeiten, sehen wir die typischen Disziplinen, die wir auch aus dem Wasserfall kennen. Was wollen wir entwickeln? Wir bauen es. Wir testen es. Schlussendlich nehmen wir es in Betrieb.

So manch einer könnte jetzt auf die Idee kommen, dass DevOps nichts anderes ist als ein Wasserfall. Nur eben viel schneller und in kürzeren Iterationen. So habe ich es auch in vielen Kundenmandaten erleben müssen. Man ist überzeugt, dass man agil arbeitet, weil man ja in Sprints macht und mit so modernen Tools wie Jira, Azure DevOps und anderen Werkzeugen schafft. Wenn man aber genauer hinsieht, dann sind es kleine Wasserfälle. Häufig ist die eigentliche Programmierung mit agilen Elementen versehen. Man arbeitet mit Stories, nutzt Pull Requests und hat sogar Definitions of Done (DoD). Doch genauso häufig endet hier dann auch schon die Agilität.

Das Testing passiert dann wieder wie in der alten Welt. Man wirft den Testern Artefakte über den Zaun und ist als EntwicklerIn froh, mit dem Kram nichts mehr zu tun haben zu müssen. Das führt oft dazu, dass die Tester am Sprintanfang eher unausgelastet sind oder Stories aus dem vorherergehenden Sprint nachtesten. Gegen Sprintende können sie sich dann aber nicht mehr vor Arbeit retten. Dies weil unbedingt noch alle Stories geschlossen werden sollen, um den Sprint abschliessen zu können. Und genau dort verlieren die Teams die Vorteile der Agilität. Das Feedback und die Effizienz aus dem Testing sind unzureichend und zu langsam, sodass die Teams manchmal das Gefühl haben, Agilität funktioniere einfach nicht.

Aus unserer Sicht werden immer wieder die gleichen 3 Fehler gemacht:

1.    Unfertige User Stories gehen in den Sprint

Wie in unserer Grafik beschrieben, beginnt Qualitätssicherung schon bei der User Story. Elementare Grundvoraussetzungen wie das gemeinsame Verständnis, was in der Story umzusetzen ist und ob die Akzeptanzkriterien vollständig und testbar sind, werden oft nicht wirklich vom Team beherzigt. Das führt dazu, dass Stories in den Sprint gelangen, die eigentlich nicht die Definition of Ready erfüllen (sofern es eine gibt). Die Folge davon ist dann, dass ohne gemeinsames Bild Entwicklung und Test aneinander vorbei arbeiten. Dadurch entstehen Mehraufwände um wieder ein gemeinsames Bild einer Story zu erschaffen. Da das erst während des Sprints passiert, verliert das Team hier dann wieder Velocity.

2.    Testing als Stiefkind der Entwicklung

Gerade im Rahmen von DevOps und agiler Softwareentwicklung kommt den Entwicklern eine besondere Verantwortung rund um die Qualitätssicherung zu. Allzu oft erlebe ich, wie Entwickler das Thema Testing behandeln wie ein 12-Jähriger seine Mathe-Hausaufgaben: Eigentlich würde man viel lieber was anderes machen, aber leider kommt man da jetzt nicht drum herum, weil sonst die Eltern (oder der Scrum Master) schimpfen. Die Qualität der Entwicklertests ist dann wenig überraschend, eher ausbaufähig.

Dabei sind die Entwickler für das Herzstück der Qualitätssicherung verantwortlich. Durch effektives Unit-Testing wird ein Sicherheitsnetz aufgespannt, dass gerade in weiter fortgeschrittenen Projekten eine Regression vermeidet und der Entwicklung quasi schon zum Check-In ein Feedback liefern, ob etwas kaputt gemacht worden ist. Dabei sind aber neben der Motivation noch die Fähigkeiten sehr essenziell. Wie gut kenne ich mich als Entwickler mit den Testtools meiner Programmiersprache aus? Kann ich mit Jasmin oder JUnit umgehen? Kenne ich die Bordmittel von Spring Boot oder Angular und kann sie anwenden? Die Folgen mangelnder Testabdeckung durch die Entwicklung schlagen dann später beim Testing auf. Die Tester sind dann mehr damit beschäftigt, die Regression sicherzustellen, als sich auf die Korrektheit der neuen Features konzentrieren zu können. Im Endeffekt leidet dann die Effizienz des Testings darunter. Dies weil entweder die neuen Stories nicht ausreichend getestet werden können oder Regressionen nicht entdeckt werden.

3.    Silos werden aufrechterhalten

Sehr eng mit dem letzten Punkt verbunden sind Probleme, die aus mangelnder Abstimmung und Kommunikation entstehen. Obwohl ein Team, das sich agil nennt oder gar nach DevOps arbeitet, nicht mehr räumlich getrennt zusammenarbeitet, sind die Wände in den Köpfen häufig noch nicht eingerissen. Die Entwickler sitzen zusammen und tauschen sich aus, auf die Business Analysten wird bei Bedarf zugegangen und mit den Testern spricht man nur, wenn sie behaupten, einen Bug gefunden zu haben.

Diese mangelnde Abstimmung führt dann dazu, dass die Tester Dinge testen, die die Entwickler schon abgetestet haben (sollten) mit ihren Unittests. Oder aber Dinge nicht testen, weil man vermutet, dass diese vonseiten Entwicklung schon getestet worden sind. Zu oft erleben wir in der Praxis Teams, die, überspitzt ausgedrückt, nicht merken würden, ob ihr Tester 2 Wochen in den Ferien ist oder nicht. Dieser Punkt ist aber auch bidirektional zu verstehen. Ein Tester muss aktiv auf das Team zugehen, sich einbringen und Fragen stellen. Nur dann kann man wirklich von einem agilen Team sprechen und nicht nur von agilen Einzelkämpfern.

Wenn Sie Fragen haben zu Agilität, DevOps oder Quality Engineering, würden wir uns sehr freuen, wenn Sie mit uns in Kontakt treten. Sehr gern beantworten wir alle Ihre Fragen rund um Testing, DevOps und wie man erfolgreich die Qualität im Projekt sicherstellt. Und wenn Sie Interesse an der 2023 Trends & Benchmarks Analyse in Quality Engineering von uns haben, so können sie dies auf unserer Homepage gratis herunterladen