Agile & Test-Driven: Der Kunde im Mittelpunkt

Wie Test-Driven-Development sowohl für Kund*innen als auch für das Entwicklerteam einen Vorteil bringt

Mit agilen Methoden werden Kund*innen aktiv in den Entwicklungsprozess einbezogen. In regelmäßigen Abständen bekommen sie die Möglichkeit, mit ihrem Feedback den Fortschritt und die Richtung ihres Produkts zu überprüfen. Auf diese Weise entsteht ein wertvolles Produkt, das schnell ausgeliefert werden kann. Mit dem Einsatz von Test-Driven-Development wird dieses Kernkonzept auch in die technische Entwicklung übertragen.

Was ist Test-Driven-Development?

Test-Driven-Development (TDD) ist ein Vorgehensmodell in der Softwareentwicklung, das darauf aufbaut, Software über diverse Testmethoden automatisiert zu testen. Traditionell wird dabei ein Feature zuerst implementiert und dann getestet. Test-Driven-Development kehrt diesen Prozess um: Hier wird für ein neues Feature zuerst ein Test geschrieben und dann die zugehörige Logik schrittweise implementiert, bis der Test erfolgreich abläuft. Anschließend wird der Code überarbeitet, um ihn zu säubern und verständlicher zu machen. Zu guter Letzt wird er in die Codebasis integriert und dort mit allen vorhandenen Tests überprüft. Erst dann gilt das Feature als erfolgreich implementiert.

Diese Vorgehensweise kann zunächst sehr unintuitiv und zeitintensiv wirken. Tatsächlich bringt sie aber – vor allem in einen agilen Arbeitsmodus integriert – viele Vorteile mit sich und kann den Entwicklungsprozess sogar nachhaltig effektiver gestalten.

Abbildung 1: Test-Driven-Development beschreibt einen zyklischen Entwicklungsprozess, bei dem zuerst getestet wird, bevor implementiert wird.

Qualitätssteigerung

Die wahrscheinlich naheliegendste Folge des Test-Driven-Developments ist die höhere Qualität, die aus den getroffenen Maßnahmen entsteht. Über diverse Qualitätsparameter wie die Anzahl von „Code Smells“ (Unschönheiten im Code), Bugs, etc. wird diese Steigerung messbar. Diese Parameter werden auch unter dem Begriff „Technische Schuld“ zusammengefasst. Auch diese Messwerte können automatisiert ermittelt werden und geben einen Überblick über den allgemeinen Zustand eines Softwareprodukts. Das Ziel von TDD ist hier, die technische Schuld im Blick zu behalten und möglichst gering zu halten. Das führt dazu, dass die Kosten für Veränderungen und Erweiterungen später wesentlich niedriger ausfallen.

Durch die eingezogene Feedbackschleife kann sichergestellt werden, dass sich der Code richtig verhält, es kann aber auch überprüft werden, dass ein unerwünschtes Verhalten nicht auftritt. Entwickler*innen beschäftigen sich also nicht nur mit dem Optimalfall, sondern auch mit möglichen Fallstricken, welche sonst erst in tatsächlichen Nutzertests auffallen würden. Die aufwendige und zeitintensive Testphase mit Benutzer*innen kann somit wesentlich verkürzt werden, Entwickelnde behandeln die Fälle direkt und versuchen nicht erst ein gemeldetes Fehlerszenario nachzustellen und zu verstehen. Außerdem bearbeiten sie Fehler, wenn der Code noch „frisch“ im Kopf ist und müssen sich nicht erst wieder hineindenken.

Code Reviews sind dabei in der Überarbeitungsphase eine gute Möglichkeit, Kolleg*innen einen Einblick in den geschriebenen Code zu geben. Einerseits wird dadurch vermieden, dass sich sogenannte „Wissenssilos“ bilden. Dabei besitzt nur ein einzelnes Teammitglied Wissen über eine bestimmte Codekomponente. Diese Abhängigkeit möchte man vermeiden. Andererseits steigt die Codequalität, da konstruktives Feedback eingebracht wird. Code Reviews können auch dazu dienen neue Mitarbeiter*innen in ein Projekt einzuführen oder insgesamt Wissen im Team zu verteilen. Durch den Prozess kann so auch die Arbeitsteilung und Teamdynamik langfristig verbessert werden.

Falls Anwender*innen trotzdem noch weitere Fehler finden, unterstützen vorhandene Tests beim Lesen des Codes und somit bei einer schnellen Behebung des Fehlers. Durch neue Tests wird dann sofort sichergestellt, dass ein konkreter Fehler sich in der Zukunft nicht erneut einschleichen kann.

Kund*innen haben dadurch den Vorteil, dass die Lebenserwartung ihrer Software erhöht wird und bei Benutzern weniger Fehler auftreten. Damit werden die Kosten für Support verringert. Die höhere Qualität ist allerdings nur ein Teilziel dieses Prozesses.

Abbildung 2: Das Ziel von Test-Driven-Development ist, die Cost of Change im Vergleich zu einem traditionellen Workflow nachhaltig zu verringern

Test-Driven-Development im agilen Kontext

In agilen Vorgehensmodellen, wie Scrum oder Kanban, wird im Gegensatz zu traditionellen Methoden ein iterativer Entwicklungszyklus abgebildet. Dieser ist darauf ausgelegt, Kund*innen möglichst schnell ein verwendbares Produkt zu liefern und möglichst früh Feedback einzuholen. Auf diese Weise kann im weiteren Entwicklungsprozess direkt auf Probleme eingegangen und die Richtung korrigiert werden. Test-Driven-Development überträgt diesen zyklischen Arbeitsablauf auf die technische Entwicklungsebene. Der Zyklus besteht, wie in Abb.1 gezeigt aus dem kontinuierlichen Schreiben von Tests, implementieren von Funktionen und Überarbeiten des geschriebenen Codes. Das zyklische Arbeiten reduziert punktuell die Komplexität einer Aufgabe und hilft den Fokus zu halten.

In agilen Prozessen können sich Anforderungen durch Kund*innen immer wieder verändern. Daher muss schon bei der Entwicklung auf Flexibilität und Änderungsfreundlichkeit in der Codebasis geachtet werden. Das ist wiederum nur möglich, wenn die Code-Basis schlank und zielgerichtet ist, was durch ständiges Überarbeiten sichergestellt wird. Hohe technische Schuld führt dazu, dass Änderungen oft zu Regressionen führen, welche oft zeitaufwendig und teuer zu beheben sind oder sogar erst auf dem Produktivsystem auffallen und somit zusätzliche Supportkosten verursachen können. Das Ziel von TDD ist in Abb. 2 gezeigt.

Testabdeckung, erfolgreiche Testdurchläufe und Reviews können in einem agilen Umfeld helfen, eine aussagekräftige “Definition of Done” zu formulieren und deren Erfüllung objektiv zu verifizieren. Eine gute “Definition of Done” ist notwendig, um klare Erwartungen für die Fertigstellung einer Funktion zwischen Entwickler*innenteam und Kund*innen zu schaffen. Sie beschränkt sich für gewöhnlich nicht nur auf die reine Entwicklungszeit bis, die ein*e Entwickler*in braucht, bis ein Feature sichtbar ist, sondern bis es alle gemeinsam vereinbarten Anforderungen erfüllt. Diese können funktionaler, qualitativer und sicherheitstechnischer Natur sein. Wenn hier kein gemeinsames Verständnis zwischen Entwickler*innenteam und Kund*innen herrscht, müssen eigentlich abgeschlossene Funktionen oft nachgearbeitet werden. Das kann den Arbeitsfluss stören und führt letztendlich dazu, dass Funktionen sehr lange in der Umsetzung brauchen.

Test-Driven Development baut auf agilen Werten auf und hilft, das volle Potenzial dieser Arbeitsweise auszunutzen. Initial kann sich die Cycle-Time in einem Team erhöhen, während die Entwickler*innen lernen, die neuen Methoden einzusetzen. Mit der Zeit, wenn aus neuen Konzepten Routine wird und Erfahrung aufgebaut wurde, wird der Aufwand vernachlässigbar und zahlt sich mit einer niedrigeren “Cost of Change” aus. Die kontrollierte Erhöhung der Softwarequalität ist letztendlich die einzige zuverlässige Methode, um den Entwicklungsprozess zu beschleunigen.

Fazit

Agile Workflows und Test-Driven-Development sind jeweils darauf ausgelegt, schnell Feedback einzuholen und darauf zu reagieren. Agile Vorgehensmodelle setzen hier vor allem auf der organisatorischen Seite an. Damit das technisch auch reibungslos funktionieren kann, führt Test-Driven-Development die agilen Werte auf der Entwicklungsebene ein. Wie bei der Implementierung des agilen Frameworks ist es hier essenziell, Test-Driven-Development an die Gegebenheiten, das Team, den Projektkontext, etc. anzupassen, damit es effektiv ist und sowohl für Kund*innen als auch für das Entwicklerteam einen Vorteil bringt.

Dieser Beitrag wurde ursprünglich unter https://www.risc-software.at/fachbeitraege-test-driven-development/ veröffentlicht.