What you get is what you see – was passiert jedoch, wenn man beim Testen nicht sieht, was man sehen wollte? Werden Tests und Entwicklung zu sehr getrennt, dann kann „zurück auf Los“ ein sehr weiter Weg sein. Besonders ein großer zeitlicher Abstand zwischen der Codeerstellung und den Tests kann die Entwicklungsgeschwindigkeit deutlich verlangsamen. Je später mangelhafte Codequalität offen gelegt wird, umso aufwändiger wird es, sie zu verbessern. Agiles Testen verfolgt daher den Ansatz, Testen und Entwickeln eng zu verzahnen.

Automatisierte, einfache Tests von Anfang an reduzieren die Zahl komplexer Tests am Ende. Außerdem fungieren die Tests als Sicherheitsnetz für Entwickler beim Refaktorisieren. Dadurch bleibt der Code flexibel und kann kontinuierlich an die gegebenen Anforderungen angepasst werden. Eine hohe Testabdeckung wird so zum Schlüssel für bessere Softwarequalität.

Es klingt paradox und ist doch nur eine Frage von Ursache und Wirkung: Softwaretests stehen für einen Anfang, unabhängig davon, an welcher Stelle des Produktionsprozesses sie platziert sind. Das gilt zumindest dann, wenn sie nicht hundertprozentig fehlerfrei durchlaufen werden. Ein Test legt die funktionale Qualität der Software offen; verändern kann und soll er sie nicht. Insofern ist er die Instanz, die entscheidet, ob die Marschrichtung hin zur Auslieferung eingeschlagen wird oder zurück an den Start. Aber das ist nur die Wirkung. Die Ursache liegt nicht im Test selbst, es sei denn, er wurde fehlerhaft aufgesetzt. Sie liegt im Code. Und damit verlangt jeder Fehler im Code, an den Anfang der Programmierung oder gar der Konzeptionierung zurückzukehren.

Diese Rückkehr kann aufwändig und teuer werden, und das umso mehr, je größer das Delta zwischen Entwicklung und Eintreffen des Feedbacks wird. Gerade der klassische Ansatz, der Entwicklung und Test personell wie zeitlich komplett trennt, kann hier problematisch werden. Anstatt also das Testen einer eigenen – und autark agierenden – Abteilung zu überlassen, bringt die agile Vorgehensweise die Testexperten und die Entwickler zusammen, idealerweise ins gleiche Team. Denn der rein „externe“ Blick hat einige Nachteile: Es bedeutet Zeit und Aufwand, sich in Produktinkremente hineinzudenken, die jemand anders erstellt hat. Je länger die Zeitspanne zwischen Programmierung und Feedback wird, desto höher ist die Wahrscheinlichkeit, dass auch der Entwickler inzwischen gedanklich in andere Themen involviert ist und sich dann selbst erneut einarbeiten muss. Nicht zuletzt steigt die Gefahr, dass auf den fehlerhaften Code längst andere Inkremente aufbauen, die dann zwangsläufig mitbetroffen sind – ein Dominoeffekt der unerwünschten Art.

Das ist ein Grund, warum agiles Software Engineering auf konstantes und direktes Feedback setzt und dazu Entwicklung und Testen zu engen Freunden oder Kooperationspartne...