HackordnungDie Vorteile der Testautomatisierung liegen auf der Hand, die Vorgehensweisen sind etabliert, die langfristigen Ersparnisse diese Verfahrensweise sind unbestritten:

Testautomatisierung

  • sorgt für den guten Schlaf des Projektleiters – auch bei größeren Umbauarbeiten/Erweiterungen
  • erzeugt zufriedene, erfolgreiche und stolze Entwickler
  • untermauert das Kundenvertrauen durch eine hohe Softwarequalität
  • gehört zum Handwerkszeug eines jeden Entwicklers
  • wird in schier endlosen Fachartikeln angepriesen
  • ist ein No-Brainer

Und trotzdem: Testautomatisierung ist ein ätzendes, dröges, schwieriges Thema, manchmal bedarf es eines missionarischen Eifers, die Skeptiker, die direkt Betroffenen, die Entwickler, die Manager davon zu überzeugen. Warum ist das so?

1.   Hackordnung

In einem sehr hörenswerten Podcast auf se-radio.net mit Kent Beck (er hat zusammen mit Erich Gamma JUnit erfunden) lässt sich Mr. Beck auch über einen Grund aus, warum Testing so ein dröges Thema ist.

Some of the barriers are probably social. … The good, the A students got to be programmers and the B students had to be testers.

Entwickler befinden sich in der Hackordnung eines IT-Projekts sicher über den Testern. Warum soll ein Entwickler dann überhaupt testen?

I’m a programmer, you know, I don’t have to write tests.

Kent Beck hat es nach gut 10 Jahren aufgegeben, diesen Standesdünkel abzubauen: “I don’t try to convince people any more.“

2.   Unterstützung durchs Management

Nicht nur die Entwickler müssen einen Sinn in der Testautomatisierung sehen, auch die Projektleitung und das Management müssen sich der Vorteile bewusst sein. Ich hatte es Anfangs schon erwähnt, dass Testautomatisierung langfristig Vorteile bringt. Quick Win versus Nachhaltigkeit – was klingt interessanter?

3.   Top-Down

In einem ziemlich großen Projekt habe ich es einmal erlebt, dass das Management Zielvorgaben für den Testabdeckungsgrad der zu erstellenden Software gemacht hat. Leider waren die abgelieferten Tests teilweise von sehr schlechter Qualität, es gab keine Abnahmen oder Reviews dafür und irgendwann ist die ganze Sache dann auch eingeschlafen. Und da ist es wieder – das Team muss funktionieren, alle müssen mitmachen, jeder muss überzeugt sein. Schwierige Sache, das. Wer will schon eine durch das Team festgelegte „Definition of Done“ finden und dann auch noch einhalten?

4.   Infrastruktur

Wenn die Ergebnisse von Testläufen schnell und unkompliziert für jeden einsehbar sind, dann ist schon die halbe Miete gewonnen. Die Tests sollen auf dem Repository laufen und nicht auf irgendeinem Entwicklerrechner. Das bedeutet aber auch, dass die entsprechende Infrastruktur besorgt, installiert, eingerichtet und betreut werden muss. Gibt es jemand, der sich um einen Buildserver kümmert, der eine CI-Umgebung einrichtet?

5.   Schnell-schnell

Je weniger Ressouren (Manpower, Rechenzeit, Laufzeitumgebung) ein automatisierter Test benötigt, desto besser sind seine Überlebenschancen. Kent Beck hat sein neues Framework JUnit Max darauf ausgelegt, möglichst wenig Zeit des Entwicklers für die Durchführung von Tests zu verbraten. Eine Testsuite, die nur mit einem mehrstündigen Aufwand Ergebnisse bringt, kämpft dagegen ständig ums Überleben. Automatisierte Tests immer anzupassen, zu erweitern und gleichzeitig ausreichend schnell zu halten, stellt durchaus eine intellektuelle Herausforderung an die Entwickler dar. Kann man seine Zeit nicht mit lohnenderen Dingen verbringen?

6.   Zeitpunkt

Der richtige Zeitpunkt für das Erstellen von automatisierten Tests ist bei Implementierungsstart. Idealerweise wird test-driven entwickelt (TDD). Wenn der Entwickler die Unit-Tests aufschiebt, weil er erst mal was zum „Laufen“ bringen muss, dann bleibt erfahrungsgemäß für das Testen keine Zeit mehr. Es passieren also immer wieder zwei Dinge: Der produzierte Code ist schwer testbar, es besteht keine Möglichkeit mehr, die Tests „hinterher zu schieben“. Und dann „klappt“ ganz plötzlich das Projekt um, es ist zeitlich nicht mehr möglich die vorher weggelassenen Tests zu erstellen. Keiner fasst mehr bestehenden und funktionierenden Code an. Refactoring findet nur mehr unter höchster Not statt. Da wir das aber schon viele Mal genauso gemacht haben, kann es nicht so schlecht sein, oder?

7.   Konsequenz

Es kommt vor, dass man in einem Projekt „nur schnell was ausprobiert“. In dieser frühen Phase – man ist sich noch gar nicht sicher, dass der Code den Tag überlebt –  werden oft keine automatisierten Tests geschrieben. Aber irgendwann passiert es doch, dass dieser Code mit der einen oder anderen Modifikation in die Produktivumgebung einfließt. Jetzt müsste man mit einer gewissen Konsequenz dafür sorgen, dass auch dieser Code testbar wird – eventuell steht hier erst mal ein Refactoring an – und dann auch letztendlich getestet wird. Was für ein Aufwand für ein bisschen Wiederverwendung!

Fazit

Testautomatisierung ist kein Selbstzweck, Kent Beck spricht in dem Interview Short-Term- und Long-Term-Benefits und Short-Term- und Long-Term-Costs an. Es war immer schon schwierig, Long-Term-Benefits mit Short-Term-Costs zu verargumentieren – wieso soll das jetzt ausgerechnet bei der Testautomatisierung anders sein?