Eigentlich ist jedem bekannt: Software testet man, bevor sie live geht. Und jeder weiß auch um die Sinnhaftigkeit dieser Maßnahme. Trotzdem wird oft das Testen abgekürzt, wenn das Projekt in Zeitnot gerät. Testen wird plötzlich als Zeitfresser ohne entsprechenden Nutzen wahrgenommen. Doch was passiert, wenn man diese Abkürzung nimmt?

Technical Debt

Der Begriff Technical Debt mag einigen bereits bekannt sein, andere mögen ihn vielleicht schon wieder verdrängt haben. Ich möchte ihn noch einmal kurz erklären:

In dem Moment, in dem ein Entwicklungsteam einen Auftrag annimmt, befindet es sich in der Schuld.
Die Schuld wird aus den noch nicht umgesetzten Anforderungen erzeugt. Hierzu zählen neben der reinen Funktionalität auch Dinge wie Korrektheit, Robustheit, Verfügbarkeit und noch viel mehr schöne Dinge, die man auch als Software-Qualität bezeichnet und deren Vorhandensein durch automatisierte Tests sichergestellt werden kann.

Schuldenabbau

Dieser Berg an Schulden wird durch die Entwicklung Stück für Stück abgetragen, bis am Ende ein Stück Software entstanden ist, das allen Anforderungen
genügt. Soweit die Theorie.

Technical Debt bleibt bestehen, wenn man in der Entwicklung „abkürzt“

In der Praxis ist es dann doch leider so, dass man Zwängen unterliegt, die einem das vollständige und saubere Abtragen dieser Schuld erschweren. Zeit, Ressourcen und Kollegen sind selten in der benötigten Menge und Qualität verfügbar oder werden während der Entwicklungszeit gekürzt bzw. abgezogen. Kurzum, man ist nicht in der Lage, den ganzen Berg abzutragen, ohne den Rahmen des Projekts zu sprengen. Oftmals wird in so einer Situation entschieden, auf Tätigkeiten zu verzichten, die scheinbar unproduktive Zeitfresser sind: Dokumentation und Tests.
Dass dies zudem die Tätigkeiten sind, die den meisten am wenigsten Spaß bereiten, ist dabei auch kein Zufall. Selbsterklärende Quelltexte schreibt ja jeder, wozu also noch dokumentieren, was eh schon leicht verständlich im Code steht? Und die fehlenden Tests braucht man – seien wir ehrlich – doch auch nur einmal am Ende durchzuführen, um dem Ganzen den letzten Feinschliff zu geben.

Die Gefahr der Abkürzung

Was man leider leicht übersieht und meist auch erst glauben mag, wenn man sich genügend an dem Thema verbrannt hat, ist die unangenehme Wahrheit, dass man nichts von alledem weglassen kann – vorausgesetzt, man hat es vorher nicht übertrieben, aber KISS und YAGNI sind nicht Thema dieses Beitrags.

Natürlich kann man aus dem Quelltext entnehmen, WAS ein Stück Code tut. Man erkennt aber nicht, WARUM es das auf diese Art und Weise tut – und, um wirklich ehrlich zu sein, die Frage nach dem Warum (auch gerne als WTF? formuliert) ist doch eine der am häufigsten gestellten beim Code Review, oder? Also bitte, ein jeder sollte sich selbst und seinen Kollegen (besonders den zukünftigen) einen Gefallen tun, und die vermurksten weniger leicht verständlichen Code-Stellen so dokumentieren, dass man später noch weiß, warum es dort so aussieht. Und wenn es nur ein ehrliches „Ich weiß nicht warum, aber es funktioniert“ ist.
Aber warum noch mal soll man Doku hinterlassen? Tut man’s nicht, ist der Code schwerer veränderbar. Veränderbarkeit ist aber Grundvoraussetzung für agile Projekte, für Wartbarkeit und spätere Weiterentwicklung. Was ist am Ende schlimmer? Kundenwünsche nicht oder nur unter finanziellem Verlust umsetzen zu können oder über die Entwicklungszeit hinweg etwas Doku geschrieben zu haben?

Auch Kleinvieh macht Mist: Technical Debt häuft sich über mehrere Iterationen zu einem Schuldenberg an.

Schauen wir mal rüber zu den Tests. Der Gedanke, es würde reichen, einmal am Ende des Projekts alles durchzutesten und gegebenenfalls Bugfixes vorzunehmen, ist ein großer Irrtum. Unterstreichen wir mal die Worte einmal und alles. Wartet man mit der QS bis zum Ende und führt man sie dann gründlich durch, kann man nochmal mindestens das an Zeit hinten ‚ranhängen, was man durch das Abkürzen gespart hat. Mindestens bitte auch unterstreichen.
Das Problem mit dem Nicht-Testen sind nicht die kleinen scharfkantigen Rückstände an den Rändern oder winzige Toleranzen im Millimetermaß, sondern die ganzen kleineren und größeren Designfehler, die man erst beim Zusammensetzen bemerkt.
Designfehler am Ende noch einmal schnell beheben? Das funktioniert nicht. Nur wenn man sie frühzeitig entdeckt, behebt und aus ihren Ursachen lernt, um sie danach zu umgehen, vermeidet man, in diese Sackgasse zu geraten.

Ist es wirklich so schlimm?

Ja. Leider. Mir ist mindestens ein Entwicklungsteam bekannt, das just eine derart große Bugwelle vor sich herschiebt, dass womöglich ein weiterer Sprint vonnöten ist, um das geplante Release fertigzustellen. Natürlich wären sie auch nicht viel früher fertig, wenn sie „alles richtig“ gemacht hätten, aber darum geht es nicht. Der Punkt ist,  dass das Problem erst jetzt, in der Mitte des Projekts, allen Beteiligten auf die Füße fällt. „Immerhin schon so früh“, werden jetzt vielleicht manche denken, aber wäre das Problem früher transparent gemacht worden, hätte man auch früher gegensteuern können. Symptomatisch erkennt man diese Bugwelle übrigens an dem leicht, aber stetig steigenden Verhältnis von Restanten aus dem letzten Sprint zu neuen Storys. Auch die nicht mehr funktionierenden Integrationstests sind ein weiteres Symptom, das deutlich auf Debt hinweist.

Nun weiß ich aber auch, dass es nicht am Können oder Wollen der Einzelnen oder des Teams liegt. Hier spielen äußere, hemmende Einflüsse eine große Rolle.

Und die Moral?

Regelmäßiges Testen und sinnvolles Dokumentieren der eigenen Arbeit entfalten ihre Wirkung zwar erst spät, sind deswegen aber kein unnötiger Ballast, sondern Notwendigkeiten, um ein Projekt erfolgreich durchzuführen und abzuschließen.

Test und Dokumentation sind auch keine Einwegprodukte, die nach der ersten Verwendung entsorgt bzw. liegengelassen werden können – auch wenn sie zugegebenermaßen langsam bis zum DELETE verrotten ;)

Das Thema Continuous Integration/Delivery kommt hier sofort in den Sinn. Nächtliche Builds sind ein Anfang, fortwährendes Verteilen von vollständig automatisiert getesteten Softwarekomponenten auf Produktion ist das Ziel. Aber CI alleine schafft noch keine Qualität – dafür braucht es Qualitätsbewusstsein als gelebten Wert im gesamten Unternehmen. Und das ist dann auch leider zu häufig die Wurzel des Übels. Jeder will Qualität, möchte dafür aber nichts tun oder geschweige denn etwas verändern. Wenn Technical Debt leichtfertig akzeptiert wird, muss erst ein Wertewandel stattfinden, bevor unterstützende Maßnahmen wie CI richtig greifen können.