Wie bringe ich meinem Auftraggeber bzw. meiner Auftraggeberin bei, dass ich zukünftig testbasiert entwickeln möchte? Wann rechnet sich welches Qualitätsniveau? Wie argumentiere ich für dieses Vorgehen? 

Teil 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 |  Kapitelauszug aus "Software-Qualität in PHP-Projekten", 2. Auflage. Erschienen im Hanser-Verlag, April 2013.

Viele Software-Projekte starten – entsprechend des Ausbildungsstands der Entwickler und Entwicklerinnen – mit prozeduralem Code. Es folgt der Umstieg in objektorientierte Pro- grammierung. Mit dieser ist die Einführung testbasierter beziehungsweise testgetriebener Entwicklung möglich. Mit wachsender Erfahrung formulieren Entwickler und Entwicklerinnen das Ziel, qualitätsvolle Software entwickeln zu wollen. Der Weg dorthin erfolgt über ein durch Tests abgesichertes Verfahren, wie es in diesem Buch für PHP beschrieben wird.

Während sich der Umstieg von prozeduraler zur objektorientierten Programmierung aus Auftraggebersicht nahezu kostenneutral darstellt, führt die Einführung testbasierter Ent- wicklung zu Mehraufwänden. Weil der erste Schritt sich weitestgehend kostenneutral für den Auftraggeber oder die Auftraggeberin darstellt, wird dieser gegenüber den Auftraggebern häufig nicht erwähnt.

Mit der Umstellung auf ein testbasiertes Vorgehen verändert das Software-Team den Kostenrahmen. Initial sind höhere Aufwände zu finanzieren. Es entsteht Kommunikationsbedarf über die Übernahme dieses Mehraufwands, indirekt entsteht Kommunikationsbedarf über das Vorgehen des Software-Teams. Dieser Kommunikationsbedarf wird induziert durch einen Vorgehensvorschlag – Vorgehensmodelle sind häufig zu diesem Zeitpunkt nicht Bestandteil der üblichen Projektkommunikation. Mit der Kostendebatte, die durch den Wunsch nach einer testbasierten Entwicklung ausgelöst wird, wird erstmals ein Vor- gehensmodell zwischen dem Software-Team und dem Auftraggeber beziehungsweise der Auftraggeberin verhandelt.

Die Erläuterung, warum nicht testbasiert entwickelt wird, enthält häufig eine Konjunktiv-Formulierung: „Das würde unser Auftraggeber sowieso nicht zahlen.“ Dieser Konjunktiv zeigt an, dass die eigentliche Verhandlung um die initialen Mehraufwände für testbasierte Entwicklung nicht geführt wurde. Die Software-Teams verzichten wider besseren Wissens auf eine testbasierte Entwicklung, weil sie die einmalige Verhandlung beziehungsweise Auseinandersetzung um die Herangehensweise des Teams fürchten.

Dabei sind zwei hauptsächliche Beweggründe zu bemerken, die Software-Teams davon abhalten, testbasierte Entwicklung in das Projektvorgehen hinein zu verhandeln:

• Im Projektumfeld herrscht ein hoher Kostendruck. Zum üblichen Ritual zwischen dem Auftraggeber beziehungsweise der Auftraggeberin und dem Software-Team gehört es, dass der Auftraggeber beziehungsweise die Auftraggeberin unter Hinweis auf den hohen Kostendruck eine Kürzung der anfangs vorgelegten Aufwandsschätzung verlangen. In diesem Umfeld ist es schwer, für ein verändertes Vorgehen Mehraufwände aufzurufen.

• Das Software-Team fürchtet um seine Reputation. Die offensive Benennung von Qualitätssicherung oder Tests als Aufwandstreiber führt zu der Frage, ob das Team bisher nicht auf Qualität geachtet hat. Das veränderte Vorgehen stellt das bisherige Vorgehen infrage.

  Im ersten Fall ist durch Aufruf höherer, initialer Kosten eine unangenehme, druckvolle Ver- handlung zu erwarten. Das Software-Team fürchtet, durch die Erhöhung der Kosten nicht mehr als Entwicklungspartner beauftragt zu werden. Im zweiten Fall verspürt das Software- Team ein latent schlechtes Gewissen über die bisherige, nicht ausreichende Qualität.

  Aus dieser Haltung heraus sind Mehraufwände schlecht zu vermitteln und positiv zu verhandeln. Dabei ist testbasierte Entwicklung im Interesse des Software-Teams und des Auftraggebers beziehungsweise der Auftraggeberin: Funktionale, gebrauchstaugliche, zuverlässige, effiziente und wartbare Software reduziert die Betriebs- und Wartungskosten.

  Software-Teams entscheiden sich für eine durch Tests abgesicherte Entwicklung, um die interne Qualität der Anwendung zu erhöhen. Im laufenden Betrieb notwendige Erweiterungen sind leichter implementierbar. Es ist insbesondere möglich, fachlich wie technisch sicherzustellen, dass die vorgenommenen Änderungen beziehungsweise Erweiterungen keine ungewollten Seiteneffekte im bereits vorhandenen Code auslösen.

  Die Umstellung auf ein testbasiertes Vorgehen führt initial zu Mehraufwänden. Wie können Software-Teams intern wie extern diese initialen Mehraufwände sinnhaft erläutern?

• Nächster Artikel: PHP Magazin | Erfolgreich lernen!
• Vorheriger Artikel: In eigener Sache: Schreibstille