Technical Debt
„Technical Debt“ ist ein Begriff für mangelhafte Software. Er soll die Problematik unzulänglicher Softwarequalität in betriebswirtschaftlichen Kategorien zum Ausdruck bringen 1. Managern soll damit gezeigt werden, dass Versäumnisse in der Software Entwicklung negative Folgen haben, die ihnen später Kosten verursachen. Der Begriff debt erinnert daran, dass man sie irgendwann abzuzahlen hat. Die Höhe der Software Schulden eines Projektes ist messbar. Sie kann als absolute Kostenzahl oder relativ zu den Entwicklungskosten des jeweiligen Projektes ausgedrückt werden.
Der Begriff wurde von Ward Cunningham auf der OOPSLA Tagung in 1992 geprägt. „Technical Debt“ ist im originalen Sinne von Cunningham „all the not quite right code which we postpone making it right“ 2. Damit meinte er die innere Qualität des Codes. Später wurde der Begriff ausgedehnt, um all das zu bezeichnen, was zu einem ordentlichen Software-System gehört, aber aus Zeitgründen verschoben wird. In seinem Buch „Managing Software Debt – Building for Inevitable Change“ geht C. Sterling auf diese Versäumnisse ein 3. Es sind nicht wenige, die im Laufe der Entwicklung mehrfach vorkommen. Je länger man ihre Korrektur vor sich hin schiebt, desto unwahrscheinlicher wird es, dass sie je korrigiert werden.
Genau hier kann eine wichtige Aufgabe des Testers im Team entstehen: Schulden aufzuzeigen und zu bewerten um möglichst schnell eine Korrektur herbeiführen. Dazu müssen sie jedoch in der Lage sein zu erkennen, was alles fehlt. Einfache Metriken wie die Testüberdeckungsmessung reichen dazu nicht aus, denn z.B. Funktionen, die nicht da sind, können auch nicht getestet werden. Der Tester benötigt daher auch mehr technische Skills, z.B. Programmierkenntnisse und ein Verständnis für Software-Design und –Architektur. Es geht zum einen darum, alles aufzudecken, was zu dem Code gehört und nicht da ist. Dies macht den größten Teil der technischen Schulden aus 4.
Der andere Teil der technischen Schulden macht die Qualität des Codes aus. Das ist es, was Ward Cunningham ursprünglich gemeint hat. Es werden vielleicht Kompromisse bezüglich der Architektur des Systems und der Implementierung des Codes gemacht, um schneller voran zu kommen. Das Ergebnis ist zwar lauffähig aber nicht wartbar und fortschreibungsfähig. Der Benutzer merkt zunächst nichts davon. So wächst der technische Schuldenberg von Release zu Release.
Rechtzeitige Problemaufdeckung
Ein Vorteil von agilen Teams ist das ständige Feedback. Deshalb sind Tester mit im Team. Wenn es darum geht, einen Qualitätsverfall zu vermeiden, haben die Tester in einem agilen Team mehr zu tun als nur zu testen. Sie sichern die Qualität des Produktes während seiner Entstehung an Ort und Stelle. Dies geschieht durch eine Reihe von Maßnahmen. Dazu gehören laufende Reviews von den User Stories über das Design bis zum Code, die Unterstützung des Teams mit Testmethodik für die verschiedenen vorgesehenen Tests und natürlich auch direkt die Implementierung und Durchführung von Tests 5.
Die agilen Tester müssen den Entwicklern immer rasch Feedback geben können 6. „Continuous Integration“ macht dies möglich 7. Der Tester hat einen Integrationstestrahmen, in den er die neuen Komponenten hineinsteckt. Die bisherigen Komponenten sind bereits vorhanden. Sie werden täglich mit den neuen ergänzt. Natürlich spielt hier die Testautomation eine entscheidende Rolle. Mit den Testwerkzeugen ist es möglich, den Regressionstest täglich zu wiederholen und dabei auch noch den Funktionstest der neuesten Komponenten zu fahren. Probleme, die auftreten, können dann sofort zurückgemeldet werden. Dies ist der entscheidende Vorteil gegenüber der konventionellen, bürokratischen Qualitätssicherung, bei der es oft Wochen dauert, bis Fehlermeldungen und Mängelberichte an das Entwicklungsteam zurückgemeldet werden konnten. So gingen wertvolle Stunden und Wochen verloren.
In der agilen Entwicklung ist dies nicht mehr der Fall. Es gibt keine derartigen Leerzeiten mehr. Um mit den Entwicklungsergebnissen mithalten zu können muss ein Tester im Team
- sich in der Entwicklungsumgebung gut auskennen
- über leistungsfähige Werkzeuge verfügen
- ein gutes Verhältnis zu den anderen Teammitgliedern haben
Wenn diese drei Bedingungen nicht erfüllt sind, dann können die Tester nicht den von ihnen erwarteten Nutzen erbringen, egal, wie gut sie die Testtechnologie beherrschen. Der agile Test verlangt eben mehr von den Testern, als dies bisher der Fall war.
Die rechtzeitige Aufdeckung von Problemen und die schnelle Rückkopplung zu den Entwicklern sind der Hauptnutzen eines agilen Tests 8. Die Qualität der Software ist zwar eine Angelegenheit des Teams in seiner Gesamtheit, aber die Tester im Team haben eine besondere Verantwortung. Sie müssen dafür sorgen, dass die technischen Schulden eingegrenzt und abgebaut werden.
- Kruchten, P./Nord, R.: „Technical Debt – from Metaphor to Theory and Practice“. IEEE Software, Dez. 2012, S. 18
- Cunningham, W.: “The WyCash Portfolio Management System” Proc. of ACM Object-Oriented Programming Systems, Languages and Applications – DOPSLA, New Orleans, 1992, S.29
- Sterling, C.: Managing Software Dept – Building for inevitable Change, Addison-Wesley, 2011
- Lim, E./Taksande, N./Seaman, C.: “A Balancing Act – What Practioneers say about Technical Debt”, IEEE Software, Dez. 2012, S. 22
- Janzen, D., Hossein, S.: “Test-Driven Development – Concepts, Taxonomy and Future Direction”, IEEE Computer, Sept. 2005, S. 43
- Bloch, U.: „Wenn Integration mit Agilität nicht Schritt hält“, Computerwoche, Nr. 24, Juni 2011, S. 22
- Duvall, P./Matyas, S./Glover, A.: Continuous Integration – Improving Software Quality and reducing Risk, Addison-Wesley, Reading Ma., 2007
- Cockburn, A.: Agile Software Development, Addison-Wesley, Reading, Ma., 2002