Wie testgetriebene Entwicklung die Qualität wirklich verbessert
Über Erwartungen, Übersetzungsfehler und warum Code selten das eigentliche Problem ist
Es gibt viele Gründe, warum Software scheitert.
Zu wenig Zeit.
Zu wenig Budget.
Zu viele Anforderungen.
Aber erstaunlich selten scheitert sie am Code.
1. Das eigentliche Problem liegt davor
In den meisten Projekten, die ich gesehen habe, beginnt der Qualitätsverlust lange vor der ersten Codezeile.
Er beginnt im Anforderungsmanagement.
Nicht, weil Anforderungen falsch wären.
Sondern weil sie übersetzt werden müssen.
Von:
- vagen Erwartungen
- zu Tickets
- zu Aufgaben
- zu Code
Jede dieser Übersetzungen ist eine potenzielle Fehlerquelle.
Und je später ein Fehler auffällt,
desto teurer wird er.
2. Tickets sind keine Anforderungen
Ein Ticket ist kein Ziel.
Ein Ticket ist ein Behälter.
Darin liegen:
- Annahmen
- Hoffnungen
- Halbsätze
- implizites Wissen
„Button einbauen“
„Checkout optimieren“
„Performance verbessern“
Das klingt konkret.
Ist es aber nicht.
Was fehlt, ist fast immer die Antwort auf eine einfache Frage:
Woran erkennen wir, dass es richtig ist?
3. Erwartetes Ergebnis ist keine Selbstverständlichkeit
Viele Teams glauben, sie wüssten,
was ein „erwartetes Ergebnis“ ist.
Bis jemand fragt.
Dann kommen Sätze wie:
- „Na, das sieht man doch.“
- „So wie immer.“
- „Das ist Standard.“
Tests beginnen genau hier.
Nicht beim Tool.
Nicht beim Framework.
Sondern beim Explizitmachen von Erwartungen.
Ein guter Test ist nichts anderes als eine präzise formulierte Erwartung:
Unter diesen Bedingungen soll genau das passieren – und nichts anderes.
4. Testgetriebene Entwicklung ist Übersetzungsarbeit
Testgetriebene Entwicklung wird oft missverstanden als:
- Technikspielerei
- Zusatzaufwand
- Entwicklersache
In Wahrheit ist sie eine Übersetzungsschicht.
Sie übersetzt:
- fachliche Erwartungen
- in überprüfbare Aussagen
Bevor Code entsteht.
Der Code ist dann nur noch die Antwort auf eine bereits gestellte Frage.
5. Warum das die Qualität verbessert
Nicht, weil Tests Fehler finden.
Sondern weil sie Denkfehler sichtbar machen.
Wenn ein Test schwer zu formulieren ist,
ist meist nicht der Code kompliziert.
Sondern die Erwartung unklar.
Testgetriebene Entwicklung zwingt dazu,
- Annahmen offenzulegen
- Randfälle zu benennen
- Verantwortung zu übernehmen
Nicht nur technisch, sondern fachlich.
6. Automatisierte Tests sind nur der letzte Schritt
Ob man am Ende mit Playwright, Cypress oder etwas anderem testet,
ist fast nebensächlich.
Wichtiger ist:
- Was getestet wird
- Warum es getestet wird
- Wann entschieden wurde, dass etwas „fertig“ ist
Automatisierte Tests sind kein Ersatz für Denken.
Sie sind dessen Konservierung.
7. Gute Tests wollen getestet werden
Code, der getestet werden soll,
muss testbar sein.
Das führt fast automatisch zu:
- klareren Schnittstellen
- weniger Seiteneffekten
- besserer Struktur
Nicht, weil es „Best Practice“ ist.
Sondern weil untestbarer Code oft auch unverständlicher Code ist.
8. Qualität ist kein Feature
Qualität entsteht nicht am Ende.
Nicht in der Abnahme.
Nicht im Bugfixing.
Sie entsteht dort,
wo Erwartungen präzise genug sind,
um geprüft zu werden.
Testgetriebene Entwicklung ist deshalb weniger eine Methode
als eine Haltung:
Wir versuchen, uns selbst nicht zu täuschen.
Schlussgedanke
Wer testgetrieben arbeitet,
schreibt nicht mehr Tests.
Er trifft früher Entscheidungen.
Und das ist meistens genau das,
was einem Projekt gefehlt hat.