Klassisches Testen von Software versus TDD
Im Januar hatte die Agile Grupppe Bremen Andreas Spillner zu Gast. Andreas hat an der Hochschule Bremen eine Professur, sein Gebiet ist das klassische Testen von Software. Er stellte beim Treffen der Agilen Gruppe vor, was das sei: Testen von Software. Die Diskussion drehte sich um die Frage, ob denn TDD klassisches Testen ersetze oder wie das Verhältnis zu bestimmen sei.
Im April hatte ich das Glück von der GI-Regionalgruppe zu einem Vortrag eingeladen zu sein. Mein Thema war: 'TestDrivenDevelopment - Letzte Fragen. Warum testgetriebene Softwareentwicklung nichts mit Testen zu tun hat und was sie denn dann ist.' Wie der Titel unschwer verrät, habe ich versucht meinen Unmut mit der Diskussion im Januar auf den Begriff zu bringen und bin bei der These 'TDD hat nichts mit Testen zu tun' gelandet.
Der Kern meines Argumentes war, dass TDD eine Technik der Entwickung von Software ist, während klassisches Testen von Software eine Methode beschreibt, wie die Anforderungskonformität eines Programms festgestellt wird. Beide Techniken besitzen so etwas wie eine Orthogonalität zueinander. Das was für die eine wichtig ist, ist für die andere nicht substantiell und umgekehrt.
Beispiel Testsuite: Für TDD ist es wesentlich, dass die Suite vor dem produktiven Code geschrieben wird. Für klassisches Testen kann man das machen (Test First), es spielt aber eigentlich keine Rolle. Die nackte Existenz der Suite ist im Feld des Softwaretestens die Essenz, was wiederum für TDD nicht die entscheidende Frage ist.
Ein anderes Beispiel ist die Frage 'Wann ist man fertig'. Die Frage ist für klassisches Testen substantiell, im Kontext des TDD wird sie in der Regel lapidar gehandhabt: 'Man ist fertig, wenn man fertig ist.'
Noch ein Beispiel: 'Wer testet' - für TDD ist substantiell, dass Entwicklung und Testen integriert sind, für klassisches Testen spielt das keine Rolle.
Diese Orthogonalität zieht sich wie einer roter Faden durch die gesamte Diskussion. Wenn sie ignoriert wird, wird die Debatte relativ unproduktiv. Klassische Tester halten TDD für eine amateurhafte Form des Testens. TDDler rümpfen die Nase ob der Neutralität gegenüber der Qualität des erzeugten Codes. Deshalb endete die Diskussion mit der These, dass klassisches Testen und TDD erst sinnvoll ins Zusammenspiel gebracht werden können, wenn ihr grundsätzlicher Unterschied verstanden ist.
Ich freue mich über Kommentare an: self(ät)jenshimmelreich.de
Kommentare
-
Ich hatte das Glück diesen Vortrag bei der GI zu hören. Ich empfand es als sehr produktiv diese Trennung einmal so klar herauszuarbeiten wie es in dem Vortrag geschah. Es hat mir geholfen in Diskussionen um TDD und Testing bzw. dem Verständnis von Softwarequalität klarer Positionen beziehen zu können. Beide Dimensionen waren zuvor in Diskussionen immer zu spüren, aber man hat häufiger unbemerkt mal zwischen Ihnen gewechselt und dadurch aneinander vorbeigeredet. Das kann ich seit dem sehr effektiv vermeiden, in dem ich frühzeitig die beiden Dimensionen anspreche. Was ich mir noch wünschen würde wäre eine einschlägigere Terminologie, die das Verwechslungsproblem entweder expliziter macht oder sogar vermeidet: BDD wird sich gegenüber TDD vermutlich nicht mehr durchsetzen können. Aber es ist ganz klar die treffendere Bezeichnung und verhindert die Verwechslung mit klassischem Testen.