Wenn es in den Entwicklungsprojekten mit Requirements mühsam wird, wird Test Driven Development (TDD) oft als die Lösung propagiert. Ist das wirklich die Lösung? Falls ja, warum hat sich TDD bis heute nicht wirklich flächendeckend in der Softwareentwicklung durchgesetzt? Im Folgenden möchte ich meine Gedanken dazu darlegen.

Test Driven Development (TDD) – Was ist das?

TDD wurde von Kent Beck und Ron Jeffries in einem Projekt bei Chrysler Anfang 2000 entwickelt. Beim TDD wird der Test in den Mittelpunkt gestellt, nicht der Source Code. Das bedeutet, es wird zunächst der Test entwickelt und erst danach der Source Code. Man ist mit dem Source Code fertig, wenn der Test „Passed“ ist. Requirements spielen hier erst einmal keine Rolle. Das Akzeptanzkriterium des Source Codes ist der Test.
Wikipedia listet u.a. folgende Vorteile des TDD auf:

• Boolsche Metrik für die Erfüllung der Anforderungen: Test ist Passed oder Failed
• Es kann ohne großen Zeitaufwand getestet werden, daher arbeiten die Programmierer die meiste Zeit an einem korrekten System.
• Der Bestand der Unit-Tests dokumentiert das System. Diese Tests stellen eine ausführbare Spezifikation dar.
• Ein testgetriebenes Vorgehen führt in der Tendenz zu Programmcode der stärker modularisiert ist.

Test Driven Development (TDD) – Herausforderung:

Die Idee hinter TDD finde ich sehr gut, trotzdem ist auch festzuhalten, dass es sich bisher nicht durchgesetzt hat. Aus meiner Sicht ist der Ansatz der hinter TDD steht viel zu radikal und solche radikalen Änderungen setzten sich selten (auf Anhieb) durch. Wesentlich erfolgsversprechender sind evolutionäre Ansätze.
Wenn man die letzten 20 Jahre der Softwareentwicklung betrachtet, dann muss man festhalten, dass das Testen fast durchgehend als lästig, aufwendig, qualitativ schlecht und ineffektiv angesehen wurde. Das Testen hat es bis heute nicht geschafft, aus dieser negativen Sichtweise herauszutreten. TDD stellt aber gerade dieses „ungeliebte Kind“ der Softwareentwicklung zentral in den Mittelpunkt. Das ist konsequent und radikal. Doch die Wahrscheinlichkeit, dass die Projekte diesen Ansatz übernehmen ist dadurch auch eher gering.
Ein wesentlicher Nachteil von TDD liegt im vergleichsweise sehr hohen Aufwand, welcher in die Testerstellung gesteckt werden muss. Wenn in der klassischen Entwicklung der Source Code in vielen iterativen Schritten verbessert wird, dann muss beim TDD ein erheblicher Aufwand davon in das Ändern der Tests gesteckt werden.
Ebenso macht es TDD praktisch zur Methode keine Requirements zu haben. Der Preis hierfür ist sehr hoch, da durch den Verzicht auf Requirements oft nicht mehr nachvollziehbar ist

• …was genau die Kundenanforderungen sind.
• …für welchen Zweck die Software entwickelt wird.
• …welches Problem mit der Software gelöst werden soll.

Darüber hinaus sind sicher Zweifel angebracht, inwieweit TDD hilft Entwicklungskosten zu sparen. Ebenso ist nicht eindeutig ableitbar, dass die Entwicklungszeit wirklich verkürzt werden kann. Auch eine höhere, für den Kunden sichtbare, Produktqualität ist durch TDD nicht zwangsläufig gewährleistet.

Reviews sind die Lösung!

Aus meiner Sicht stellt das konsequente Review von Requirements (insbesondere in frühen Projektphasen) ein nahezu ideales Vorgehen dar, um die Ziele des TDD zu erreichen. Die wichtigsten Fragen im Review sind dabei folgende:
Ist das Requirement verifizierbar? Wie sieht die Verifikationsstrategie aus?
Die Implementierung wird dann erst gestartet, wenn auf diese Fragen zufriedenstellende Antworten gefunden wurden.
Der Vorteil ist, dass Requirementsreviews wesentlich schneller und kostengünstiger zu erstellen sind, als entsprechende Tests.
Auch während der Implementierung werden immer wieder Source Code Reviews durchgeführt, bei denen die richtige Umsetzung der Requirements überprüft wird.
Die Vorteile dieses Vorgehen gegenüber TDD liegen auf der Hand:

• Geringere Kosten, bei gleicher Qualität
• Requirements Reviews und Code Reviews sind prinzipiell auch im heutigen Entwicklungsprozess gut bekannt und stellen keine Revolution in der Entwicklung dar. Die Bewusstmachung der Mächtigkeit dieser Methode im Software Engineering stellt eher eine Evolution dar.

Fazit:

Requirements und Source Code Reviews sollte nicht länger als lästiges Übel zur Prozessbefriedigung verstanden werden. Richtig angewendet sind Reviews ein sehr effizienter und wirksamer Schritt in der Software Entwicklung. Um dieses Potential aber wirklich ausschöpfen zu können, müssen die Mitarbeiter die benötigten sozialen und fachlichen Voraussetzungen an die Hand bekommen.

Ihre individuellen Fragen zum Requirements Engineering beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).