Versteckte Kosten Manuellen Testens 1


Verbreitet die Message!

Es gilt heute als “Best Practice” testgetrieben zu entwickeln. Vor der Entwicklung einer Funktionalität, wird zu Beginn der minimalste (Unit-)Test für die Funktionalität geschrieben. Natürlich schlägt dieser Test erst einmal fehl (Red), denn erst im Anschluss wird die minimalste Funktionalität implementiert, die den Test zum positiven Ergebnis (Green) bringt. Nun folgt das Refactoring des Codes, da dieser in Reinform meist sehr unschön ist. Ist dies abgeschlossen wird ein neuer Unit-Test geschrieben und dieser Zyklus (Red –> Green –> Refactoring) beginnt von vorn. Die direkten Folgen dieser Entwicklungsmethodik sind zwei Hauptaspekte:

  1. anfänglicher Mehraufwand (vgl. quick & dirty)
  2. Qualitätssicherung

Indirekt folgt:

  • Der Code ist sehr gut lesbar und tatsächlich nach besten Wissen und Gewissen seines Autors geschrieben
  • Die Unit-Tests dienen als (Interpretation der) Spezifikation (warum sie manchmal auch spec heißen)
  • Testgetriebene Entwicklung führt zu einem genaueren Nachdenken über das gewünschte Verhalten, die Spezifikation und Randfälle
  • In der weiteren Entwicklung dienen die Unit-Tests der Erkennung und Bekämpfung von Regression

Leider ist das nicht die Berufsrealität vieler Entwickler. Diese sind auch nicht faul oder unfähig, sondern lassen sich vom Zeitdruck ihrer Vorgesetzten und Kunden dazu überreden eine “quick & dirty” Methode zu fahren. Ein folgendes Szenario kommt jedem Entwickler bekannt vor: Bis zu einem bestimmten Datum muss eine gewisse Funktionalität implementiert oder ein Bug behoben sein. Der Kunde macht Druck, also macht auch der Vorgesetzte Druck. Nach einer kurzen Sichtung des Problems ist klar, dass dies mit gründlicher Arbeitsweise nicht mit dem aktuellen Zeitplan vereinbar ist. Aber schnell eine ungetestete Funktionalität bereitzustellen, wäre möglich. Also wird es so umgesetzt, wie es geht. Man könnte ja später den Test nachschieben, dafür gibt es doch den Backlog..

Solche Codestellen nennt man auch “technische Schulden”. Sie heißen so, obwohl sie, wie wir sehen werden, auch in der wirtschaftlichen Realität Schulden sind.

Bei der Software-Entwicklung ist erst einmal festzuhalten, dass es ohne Testen nicht geht. Eine Anwendung wird zumindest manuell vom Entwickler oder einem Tester getestet. Wenn nicht überlässt man das Testen dem Endkunden, bzw. deren Qualitätssicherungs-Abteilung.

Nicht zu testen ist also keine Option und es besteht die Wahl zwischen den Extremen “Entwicklung und Übergabe an die Testabteilung” oder “Entwicklung mit automatisierten (Unit-)Tests”.

Kosten manuellen Testen vs. Kosten TDD

Bei der Betrachtung der Wirtschaftlichkeit der Verfahren stellen sich die Fragen:

  1. Wie hoch ist der Mehraufwand der durch Test Driven Development entsteht?
  2. Wie hoch ist die Einsparung die durch Test Driven Development realisiert werden kann.

Test Driven Development

Der Mehraufwand der durch das Schreiben von Tests entsteht ist besonders am Anfang hoch. Als Voraussetzung muss der Entwickler erst einmal das Test-Framework aufsetzen. Bei Sprachen wie Java ist das mit JUnit relativ einfach, bei Javascript mit Jasmine nicht ganz trivial.
Auch danach kann man nicht sofort loslegen, sondern muss vor der ersten Codezeile wissen, welche Funktionalität man überhaupt benötigt. Nach diesem Nachdenken über das Konzeptionelle kann man anfangen den Code und die Tests wie oben im Beispiel gezeigt zeitgleich zu entwickeln.

Die Kosten vom Test Driven Development sind also erhöhte einmalige “Fixkosten”, sowie verlangsamte Entwicklungszeit.

Manuelles Testen

Bei der Entwicklung mit manuellem Testen sind die Entwicklungskosten anfänglich deutlich geringer und gemeinhin das was der Schätzung des Developers entspricht. Außerdem können schnell Resultate gezeigt werden.

Mit laufender Projektlaufzeit fallen jedoch die technischen Schulden, also der unrefactored Code immer mehr ins Gewicht. Ich würde schätzen, dass nach mittlerer Projekt Laufzeit die Geschwindigkeit des Entwicklers auf die Hälfte sinkt, denn er muss immer mehr um “hässlichen” Code herum arbeiten. Beispielsweise könnte das zu sehr großen Controllern oder Repositories führen, die schwer verständlich und lesbar sind. Damit werden Fehler immer schwerer behebbar.
Ein weiterer Aspekt ist, dass gerade nahe der Abnahme nötiges Refactoring aus Angst unerkannter Regression nicht durchgeführt wird/werden kann. Das Konzept der Kurzfristigkeit konsequent durchgeführt, führt dies zu immer weiter wachsenden technischen Schulden. Ein Effekt den man als Entscheider daran erkennt, dass die Mitarbeiter das Projekt nicht mehr anfassen wollen, demotiviert sind und scheinbar ineffizient arbeiten. Spätestens jetzt ist es Zeit einzugreifen.

Mit steigenden technischen Schulden wird die Geschwindigkeit mit der Entwickler arbeiten können immer geringer und der Aufwand für einfachste Aufgaben immer größer. Es gibt einen enormen Abrieb im Team. Fallen Entwickler aus, ist dass der “Super-GAU”, weil eine Einarbeitung sehr schwierig ist – schlecht lesbarer Code, viel Geheimwissen.

Spätestens nach 3-4 Monaten Projektlaufzeit haben sich die erhöhten Kosten der Tests amortisiert. Eine Beispielhafter Projektverlauf könnte wie folgt aussehen:

Während durch TDD das Projekt langsam aber stetig voran kommt, hat die Quick & Dirty Variante immer wieder mit Regression und verlangsamter Entwicklung zu kämpfen

Fazit

Manuelles Testen ist deutlich teurer als der Einsatz von Test Driven Development. Um die Entwickler nach TDD entwickeln zu lassen müssen die Entscheider in ihre Entwickler Vertrauen haben, da viel langsamer Resultate zu sehen sind. Es kostet Zeit ein sauberes Produkt zu bauen, und mit Druck von oben lassen sich Probleme die durch Quick & Dirty auftauchen nun mal nicht lösen. Dieses Dilemma ist in Clean Coder sehr gut beschrieben.

Die Einsicht das gründliches Arbeiten besser ist als schnell Resultate vorm Kunden vorzeigen zu können, ist entscheidend um als Unternehmen langfristig Geld zu sparen, saubere, wartbare Produkte zu liefern und die eigenen Mitarbeiter durch Professionalität langfristig zu motivieren. Nur so können Unternehmen nach innen und außen bestehen.

Verbreitet die Message!

Schreiben Sie einen Kommentar

Ein Gedanke zu “Versteckte Kosten Manuellen Testens