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 ([1] 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 ([2] http://www.agilealliance.org).

Brian Marick kategorisiert die Testarten in agilen Projekten entlang zweier Dimensionen. Zum einen anhand ihrer Intention:

• Qualitätssichernde Tests werden gegen bereits existierenden Code geschrieben, also nachdem entwickelt wurde. Diese Tests können manuell oder automatisiert sein und werden nicht von den Entwicklern entworfen. Ihr Ziel ist es, Schwächen in der erstellten Software zu finden, bevor diese in Produktion geht.
• Entwicklungsunterstützende Tests werden vor oder während der Entwicklung erstellt. Sie werden von den Entwicklern selbst oder in enger Zusammenarbeit mit ihnen erstellt und sind immer vollständig automatisiert und in den Buildprozess eingebunden. Bei testgetriebener Entwicklung wird immer erst der Test erstellt, dann der Code erweitert. Ihr Ziel ist es, die Entwicklung zu leiten und sie bei Änderungen zu unterstützen und abzusichern.

Daneben gibt es als zweite Dimension den Inhalt eines Tests:

• Fachliche Tests testen fachliche Eigenschaften des Systems, also alle Eigenschaften, die einen Anwender
  auch auf einer idealen Maschine interessieren würden
• Technische Tests testen hingegen Eigenschaften, von denen der Endanwender eigentlich nichts wissen will
  - sie werden vorausgesetzt. Dies sind zum Beispiel klassische nicht-funktionale Anforderungen wie Performance, Skalierbarkeit,
  Datenschutz und Ergonomie, zum anderen interne Qualitäten, wie das Design des Systems.

Aus diesen zwei Dimensionen ergeben sich nun vier Kategorien von Tests entsprechend der folgenden Tabelle:

Während die rechte Spalte die klassischen Tests einer (gut organisierten) Testabteilung darstellt, hat agile Entwicklung die linke Spalte neu eingeführt. Als Faustregel gilt, dass Schwächen, die auf der rechten Seite gefunden werden, zunächst mit Hilfe entwicklungsunterstützender Tests nachgestellt werden sollten, bevor sie behoben werden. Das ist zwar nicht immer mit angemessenem Aufwand möglich, sollte aber angestrebt werden. Nur so wird sicher gestellt, dass diese Probleme in Zukunft nicht mehr auftreten können.
Der Schluss, für die Testteams würde agile Entwicklung also gar nichts ändern, ist allerdings so falsch, wie fatal. Die Qualitätssicherungstests müssen sich ebenso in den Iterationsrhythmus einfügen, wie alle anderen Projekttätigkeiten. Um die dafür notwendige Geschwindigkeit zu erreichen, ohne Qualitätseinbußen in Kauf zu nehmen, muss auch bei der QS in hohem Maße automatisiert werden. Zudem kann nicht, wie oft üblich, von Anforderungsdokumenten aus gearbeitet werden, sondern Kollegen von der QS müssen von Anfang an an der Planung und Entwicklung beteiligt werden. Aber darüber ein anderes Mal.