„Build in Quality“ – Wie Test-Driven Development nicht nur Tests, sondern Haltung verändert

Ich erinnere mich noch gut an den Moment, als ich zum ersten Mal fragte:
👉 Können wir Qualität nicht einfach einbauen – direkt beim Entwickeln?
Damals schien das fast naiv. Heute weiß ich: Test-Driven Development (TDD) ist genau dieser Weg. Und er verändert weit mehr als nur die Reihenfolge beim Coden.

In dieser Session ging es nicht um Theorien, sondern um Erfahrungen aus der Praxis: in einem agilen, crossfunktionalen Team, eingebettet in ein komplexes Automotive-Umfeld mit Anforderungen wie ASPICE, funktionaler Sicherheit und kontinuierlicher Integration.

Die Idee ist einfach. Die Wirkung ist tiefgreifend.

Test-Driven Development beginnt mit einem Perspektivwechsel:
📌 Zuerst schreibe ich den Test.
📌 Dann implementiere ich nur so viel Code, dass der Test grün wird.
📌 Und dann: Refactoring, bis der Code sauber ist – strukturell, lesbar, regelkonform.

Was so trivial klingt, verändert alles:

Ich denke in Erwartungen, nicht in Funktionen.
Ich baue von Anfang an auf Verständlichkeit und Testbarkeit.
Ich bin verantwortlich für die Qualität – und zwar sofort, nicht irgendwann.

Kleine Schritte, große Wirkung

Die Magie von TDD liegt in der Wiederholung:

Rot: Ich schreibe einen Test – er schlägt fehl.
Grün: Ich implementiere minimalen Code – der Test läuft.
Blau/Grau: Ich refaktoriere, bis der Code „sauber“ ist.

💡 Nur ein Test pro Durchlauf. Keine 10 auf einmal.
So entstehen kurze Feedbackzyklen, klare Ergebnisse und ein stabiles Entwicklungstempo.

Voraussetzungen – und was wir daraus lernen

Test-Driven Development ist kein Selbstläufer. Es funktioniert nicht „einfach so“.
Es ist wie ein präzises Musikinstrument: Wer es nur oberflächlich beherrscht, erzeugt Lärm. Wer es meistert, schafft Klang – klar, strukturiert, kraftvoll.

Und wie jedes präzise Instrument braucht auch TDD das richtige Umfeld, die passende Kompetenz und eine geteilte Haltung.

Hier sind aus meiner Sicht die entscheidenden Voraussetzungen, damit TDD nicht nur umgesetzt, sondern gelebt werden kann:

🧠 1. Gemeinsames Verständnis – Klarheit über Erwartungen

Bevor ein Test geschrieben werden kann, muss klar sein:
👉 Was genau wird eigentlich erwartet?
Dafür braucht es ein gut vorbereitetes Backlog Refinement, in dem nicht nur Funktionalitäten diskutiert, sondern Zielbilder und Testideen entwickelt werden.

Denn: Wer Anforderungen nicht versteht, kann keine sinnvollen Tests schreiben.
Und wer keine Tests hat, wird im Nebel entwickeln.

🧭 2. Definition of Ready & Done – Orientierung auf allen Ebenen

Diese beiden Definitionen sind für TDD essenziell:

Definition of Ready:
🔹 Wissen wir, was zu tun ist?
🔹 Haben wir Komplexität und Abhängigkeiten verstanden?
🔹 Wissen wir, woran wir merken, dass wir fertig sind?
Definition of Done:
🔹 Sind alle funktionalen Anforderungen abgedeckt?
🔹 Erfüllen wir die Nicht-Funktionalen? (z. B. Architekturregeln, Guidelines)
🔹 Haben wir sichtbare, messbare Ergebnisse?

Nur wenn beides gemeinsam getragen wird – vom Team, PO, QA, Architekten – entsteht echte Klarheit.

👥 3. Das richtige Teamprofil – interdisziplinär, reflektiert, verantwortungsvoll

Ein TDD-Team braucht mehr als Entwickler:innen mit Coding-Kenntnissen. Es braucht:

Architekturverständnis
Designkompetenz
Testdenken
Reflektierte Kommunikation
Den Mut, Qualität nicht zu delegieren

In einem solchen Setup kann jedes Teammitglied mitdenken und mitverantworten, was entstehen soll – nicht nur liefern.

🧪 4. Technisches Fundament – Automatisierung als Rückgrat

Ohne eine performante, automatisierte Testumgebung wird TDD schnell frustrierend.
Warum? Weil das Versprechen schneller Feedback-Zyklen nicht eingelöst wird.

Ein gutes Setup bietet:

Automatische Unit-Tests, Integrationstests, statische Codeanalysen
Schnelle Ausführung (idealerweise < 5 Minuten)
Klare Rückmeldung (grün/rot) zu funktionalen und nicht-funktionalen Anforderungen

Nur so wird Feedback zum Freund – nicht zum Flaschenhals.

🔄 5. Organisation und Struktur – von Modul bis Funktion konsistent

TDD darf kein isolierter „Methodenversuch“ einzelner Entwickler:innen sein. Es braucht:

Ein gemeinsames Commitment auf Team- und Release-Train-Ebene
Klare Schnittstellen und stabile Architekturen, die Refactoring erlauben
Synchronisation über Teamgrenzen hinweg (z. B. durch gemeinsame PI-Ziele)

Besonders in komplexen Systemen muss klar sein:
Jede Zeile Testcode ist auch ein strategisches Statement zur Qualität.

🔧 6. Lern- und Verbesserungsräume – TDD ist auch Kulturarbeit

Zu guter Letzt:
TDD braucht eine Kultur, in der Lernen, Nachfragen und Verbesserung gewollt – und nicht als „Zeitverschwendung“ gebrandmarkt werden.

Hat das Team Raum, um neue Testideen zu entwickeln?
Werden Clean Code und Refactoring als wertvoll angesehen – oder als „nicht messbar“?
Wird reflektiert, warum Tests nicht grün werden – oder wird nur „durchgeschoben“?

Ohne diese Fragen bleibt TDD ein Tool. Mit ihnen wird es zur Haltung.

Fazit dieses Abschnitts:

Wenn wir Test-Driven Development als echtes Transformationsinstrument verstehen wollen, dann beginnt alles hier – bei den Voraussetzungen.

Wer sie schafft, eröffnet den Raum für Qualität, Verantwortung und nachhaltigen Erfolg.
Und ja, es braucht Mut. TDD zwingt uns, uns der Qualität sofort zu stellen – nicht „irgendwann später“.

Skalierung: Vom Modul zur Funktion zur Organisation

Was im Kleinen funktioniert, lässt sich auch im Großen nutzen:

Auf Modulebene entwickeln einzelne Entwickler:innen nach TDD.
Auf Funktionsebene kooperieren mehrere Teams innerhalb eines Release Trains.
Auf Organisationsebene brauchen wir gemeinsame Strategien, Infrastruktur, Standards – und geteilte Verantwortung.

Das bedeutet:
🛠 Die Zeiten von Silos und separaten Testabteilungen sind vorbei.
🚀 Wir brauchen integrierte Test- und Integrationsstrategien, die auf jeder Ebene greifen.
💡 Und wir brauchen ein gemeinsames Verständnis dafür, was „fertig“ bedeutet – egal ob auf Team-, Train- oder Solution-Ebene.

TDD erfüllt mehr als nur agile Prinzipien

Was mich besonders begeistert:
TDD erfüllt nicht nur agile Grundwerte wie Transparenz, Feedback und Verantwortung –
es erfüllt auch klassische Standards wie Automotive SPICE.

Denn dort zählt am Ende das Ergebnis:
✅ Funktioniert die Software?
✅ Sind die Anforderungen nachvollziehbar erfüllt?
✅ Ist der Code strukturiert, regelkonform, wartbar?

Mit TDD beantworten wir all das – nicht am Ende des Projekts, sondern jeden Tag.

Fazit: Verantwortung beginnt bei mir

Wenn ich eines mitnehmen möchte, dann dies:
👉 Wer den Fehler verursacht, ist auch für die Lösung verantwortlich.

Das ist kein Vorwurf – das ist Empowerment.
Und genau das ist die Kraft von Test-Driven Development:
Es verändert nicht nur den Code. Es verändert unser Denken.