12.11.2008 von Jens Coldewey.

Nach einer Umfrage von Martinig & Associates ist der Einsatz testgetriebener Entwicklung zwischen 2006 und 2008 von 14% auf 20% der befragten Organisationen gestiegen. Das ist auf der einen Seite erfreulich, auf der anderen Seite zeigt es aber, dass wir noch immer bei den “Early Adoptern” sind. Daran gemessen, dass TDD im Gegensatz zu informellem “Nachtesten” bei gleichem oder sogar verringertem Aufwand fast die doppelte Testabdeckung erreicht (persönliche Erfahungen sowohl von mir als auch von Johannes Link), dürfte die geringe Nutzung weder an wirtschaftlichen noch an methodischen Gründen liegen. Ich vermute eher, dass viele Entwickler sich zunächst subjektiv langsamer fühlen, wenn sie testgetrieben arbeiten — und nicht das Durchhaltevermögen haben, sich einmal zwei oder drei Monate auf das Verfahren einzulassen, bevor sie aufgeben. Dann würden Sie nämlich feststellen, dass sie deutlich weniger Fehler beheben müssen und damit wesentlich schneller sind, als vorher. Vielleicht nicht bis zu ersten “hingerotzten” Version, aber sicher bis zum produktionsfähigen Code. Nur wenige Teams schaffen dieen Schritt denn auch aus eigener Kraft ohne Coaching.

Geschrieben in Testgetriebene Entwicklung, Agilität | Drucken | Keine Kommentare »

30.10.2008 von Jens Coldewey.

Brian Marick fasst in seinem Blog-Eintrag “Barriers to acceptance-test driven design” die wichtigsten Startprobleme gegen den Einsatz von Akzeptanztests zusammen.

Interessanterweise habe ich vor allem bei größeren Mengen alten Codes genau die umgekehrte Erfahrung gemacht: Teams waren eher bereit, Akzeptanttests als Grundlage für ihre Entwicklung zu nehmen, als Unit-Tests. Das liegt möglicherweise daran, dass Unittests gut funktionieren, wenn man auf der grünen Wiese startet. Sind erhebliche Mengen alten Codes vorhanden, ist der in der Regel so schlecht testbar, dass Akzeptanztests den leichteren Weg darstellen, schnell die Testabeckung zu erreichen, die man braucht, um das System sicher ändern zu können.

Geschrieben in Surftipp, Testgetriebene Entwicklung, Agilität | Drucken | Keine Kommentare »

14.3.2008 von Jens Coldewey.

Nach längerer Zeit nun der zweite Teil meiner Serie über agile Prakitken. Bisher finden Sie in dieser Kategorie die folgenden Einträge:

• Neue Serie: Agile Praktiken
• Praktiken I: Retrospektiven

Der zweite Teil beschäftigt sich mit automatisierten Akzeptanztests:

Auch agile Entwicklung startet mit den fachlichen Anforderungen. Allerdings werden sie direkt als Akzeptanztests aufgeschrieben, statt in Anforderungsdokumenten. Akzeptanztests sind fachliche Beschreibungen dessen, was das System können soll und zwar so, dass sie automatisch ausgeführt werden können. Automatisch ausführbare Tests steuern die Anwendung und überprüfen deren Ergebnisse ohne menschlichen Eingriff. Der Weg zu diesen Akzeptanztests ist noch eher uneinheitlich, man geht aber in der Regel von den geplanten geschäftlichen Abläufen aus (siehe dazu auch “Use Cases oder User Stories“).

Den Rest des Eintrags lesen »

Geschrieben in Praktiken, Werkzeuge, Testgetriebene Entwicklung, Buchtipp, Agilität | Drucken | Keine Kommentare »

11.3.2008 von Jens Coldewey.

Johannes Link hat einen Werkzeugsatz geschrieben, mit dem man größere Mengen an FitNesse-Seiten umstellen und Refaktorisieren kann. Derzeit präsentiert sich ReFit, wie er das Werkzeug nennt, recht spartanisch als Groovy-Konsole, Johannes hat mir aber versichert, dass er jeden unterstützt, der Lust hat, dazu eine schicke grafische Oberfläche zu schreiben. Im Projekt verwendbar ist ReFit jetzt schon, zumindest wenn die Entwickler sich noch nicht auf die Maus beschränken, sondern noch mit der Tastatur umzugehen wissen…

Weitere Informationen und Links finden Sie auf Johannes Links Blog unter dem Titel Refactoring FitNesse Tests.

Geschrieben in Werkzeuge, Refactoring, Testgetriebene Entwicklung, Agilität | Drucken | Keine Kommentare »

11.12.2007 von Jens Coldewey.

Häufig wird testgetriebene Entwicklung von jenen in Frage gestellt, die sich eigentlich besonders über vermehrtes Testen freuen müssten: Professionellen Testern und Qualitätssicherer. Es sei widersinnig, wenn Entwickler auch Tests für ihren eigenen Code schrieben, bemerken Sie - korrekter Weise. Das wird von dem agilen Testansatz aber auch gar nicht in Frage gestellt, ebenso wenig, wie agile Ansätze eine eigene Testtruppe obsolet machen würden.

Tatsächlich halten sich die verbreiteten agilen Ansätze eher bedeckt, wenn es um die klassischen Testaufgaben geht. Ich persönlich orientiere mich in diesen Fragen stark an den Ideen von Brian Marick (http://www.exampler.com), der seit langer Zeit als Testconsultant arbeitet und dort agile Ansätze voran treibt. Er ist Co-Autor des agilen Manfiests und war mehrere Jahre Präsident der Agile Alliance Non-Profit Organisation (http://www.agilealliance.org).

Brian Marick kategorisiert die Testarten in agilen Projekten entlang zweier Dimensionen. Zum einen anhand ihrer Intention:
Den Rest des Eintrags lesen »

Geschrieben in Testgetriebene Entwicklung, Agilität | Drucken | 2 Kommentare »

8.12.2007 von Jens Coldewey.

Ein kurzer Hinweis auf Martin Fowler’s Blog-Eintrag “Test Cancer” sei mir hier erlaubt. Er beschreibt das Phänomen, dass man nach einiger Zeit seinen Code einmal wieder sieht und ein guter Teil der Tests auskommentiert sind, oder nicht mehr laufen. Der lesenswerte Eintrag entspricht dem, was auch ich meinen Kunden immer wieder predige: Nur wenn alle Tests zu 100% laufen, sind die Testfälle das Sicherheitsnetz, das man benötigt, um sicher Software zu testen.

In diesem Sinne sind agile Verfahren Hoch-Disziplin-Methoden. Am ehesten erreicht man dieses Ziel, wenn man alle Tests im Buildserver laufen lässt und mehrmals täglich verifziert. Dann kann die Änderung, die zum Brechen des Tests geführt hat, relativ schnell identifziert werden.

Ein Entwickler beschwerte sich neulich bei mir, durch eine Änderung von Kollegen an der Testinfrastruktur habe er sieben Stunden lang die Tests nicht laufen lassen können, das sei die Hölle gewesen und hätte ihn letztlich zwei Überstunden gekostet. Er verlange, dass die Tests in Zukunft lauffähig bleiben. Diese Einstellung ist das beste Mittel gegen Testfall-Erosion, eine der Todsünden agiler Entwicklung.

Geschrieben in Testgetriebene Entwicklung, Agilität | Drucken | Keine Kommentare »