Letzte Woche hatte ich ja kurz vom ObjektForum Nord berichtet und von dem Tool Fitnesse, welches es erlaubt Akzeptanz Tests (Functional Tests) in Wikiform zu schreiben.
Die Vorteile sind klar:
- Der Kunde oder Produkt Owner wird ohne technische Knowhow in die Lage versetzt, Akzeptanz Tests zu seinen User Stories zu schreiben.
- Solche Akzeptanz Tests sind sprachlich leicht verständlich und dennoch technisch exakt genug, um für ein gemeinsames Verständnis zwischen Anforderungs- und Umsetzungsseite zu sorgen.
- Da diese Form der Akzeptanz Tests nicht auf eine bereits vorhandene Implementation angewiesen ist, kann das gemeinsame Verständnis zum frühest möglichen Zeitpunkt erfolgen.
- Dieses Timing wiederum begünstigt Test getriebene Entwicklung (TDD).
Klingt alles hervorragend. Wir müssen nur zwei Dinge tun..
Als PHP Entwickler müssen wir zunächst einmal ein Tool finden, welches wir mit PHP nutzen können. Fitnesse scheint da ein Plugin zu haben und es gibt mindestens einen anderen Ansatz im Netz, der aber schon seit vielen Monaten keine Aktivität mehr zeigt. Aber das ist ein technisches Problem, welches eine technische Lösung haben kann.
Schwieriger wird da eine andere Frage:
Wie bringen wir unseren Kunden dazu, dieses Tool zu erlernen und aktiv zu nutzen?
Ich kann mir einige Konstellationen mit “internen Kunden” vorstellen, wo eine solche Tool Entscheidung gemeinsam getroffen und dann auch umgesetzt wird. In den meisten Fällen aber werden wir es mit externen Kunden zu tun haben. Wie bringen wir die dazu, sich an unsere Tool Vorgaben zu halten?
- By chance (mit Glück)
- By proxy (per Stellvertreter)
Die Stellvertreter Variante ist die wahrscheinlichere und für den Stellvertreter gibt es auch einen Namen: Product Owner.
Der Product Owner repräsentiert den Kunden innerhalb eines agilen Entwicklungsprozesses (Scrum, XP, Crystal, ..). Und das ist vielleicht die grösste Hürde, ein Tool wie Fitnesse einzuführen. Es setzt meiner Meinung nach vorraus, dass eine agiler Methode etabliert ist. Das ist in immer mehr Unternehmen und Teams der Fall, aber lange nicht in allen und gerade die grösseren tun sich oft schwer mit der Einführung.
Wenn aber diese Voraussetzung nicht gegeben ist, was für Möglichkeiten bleiben?
Im Grunde genommen, kann man nur versuchen innerhalb des Entwicklungsteams selber für die Akzeptanz Tests zu sorgen. Genau das scheint wiederum auch der symfony Ansatz zu sein, denn dort gibt es ein (natürlich) eigenes Functional Test Framework. Auch mit diesem Tool kann man Akzeptanz Tests schreiben, welche man das automatisiert ausführen kann.
Allerdings ist dieser Ansatz wesentlich näher an “Capture and Run” Tools wie Selenium als an Tools wie Fitnesse. Das Momentum geht verloren, wo es zu einer frühen Verständigung zwischen Kunde und Entwickler kommen kann. Es besteht keine Garantie, dass die Anforderungen korrekt verstanden wurden. Dieser Ansatz ist ideal ausschliesslich für Technik getriebene Unternehmen, für alle anderen ist er ein Kompromiss aus dem Bewusstsein, dass Akzeptanz Tests notwendig sind und dem Eingeständnis, dass der Kunde in vielen Fällen kein Interesse daran hat, sich diesem Ansatz anzupassen.
Dennoch besser als nichts! Mit viel Kommunikation mit dem Kunden wird es wohl gelingen können, die Missverständnisse einigermassen klein halten zu können.
Heute, morgen und übermorgen werde ich an der Symfony Live 2010 Veranstaltgung in Paris teilnehmen. In den kommenden drei Tagen werde ich ausführlich berichten und mit Sicherheit auch das ein oder andere Test verwandte Thema ansprechen.
Functional Tests · symfony · Test Driven Development · Tests
-
http://www.krsteski.de Gjero Krsteski
