Kampf gegen technische Schulden

Als Teil eines agilen Entwicklungsteams haben Tester eine besondere Verantwortung. Sie müssen unter anderem verhindern, dass die technischen Schulden (Technical Debt) ausufern.

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. 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”.

Eine Formel für die Kalkulation der Schulden haben Mitarbeiter der CAST Software Limited in Texas vorgeschlagen. Diese Formel verbindet Problemarten mit Aufwand und Aufwand mit Geld. Die Basisformel ist eine Erfahrungsdatenbank zahlreicher Projekte, aus der der mittlere Aufwand zur Beseitigung von Softwaremängeln hervorgeht. Das Refactoring einer Methode kann z.B. einen halben Tag kosten. Bei einem Stundensatz von US$ 70 sind das $ 280. Eine fehlende Ausnahmebehandlung einzubauen kostet vielleicht nur eine Stunde, aber die Implementierung erforderlicher Sicherheitsprüfungen in einer Komponente könnte mehrere Tage dauern. Der Verdienst der Texaner liegt darin, dass sie etliche Mangelarten identifiziert, klassifiziert und mit Aufwandszahlen versehen haben.

Beispiele für die Mangelarten sind:

• eingebaute SQL-Abfragen
• leere Catch-Blöcke
• zu komplexe Bedingungen
• fehlende Kommentare
• redundante Codeblöcke
• uneinheitliche Namensvergebung
• Schleifen ohne Notbremse
• zu tief verschachtelter Code

Die Schulden für solche Codemängel sind die Anzahl der Mängelvorkommnisse multipliziert mit den Stunden der Behebung mal die Stundenkosten.

Zu diesen statisch erkennbaren Mängeln kommen noch die ausgerechneten Fehler, die beim Test gelegentlich auftreten. Aus Zeitgründen werden nicht alle Fehler in einem Release beseitigt, sofern sie nicht die Lauffähigkeit der Software beeinträchtigen. Dazu zählen Fehler in den Ausgaben, z.B. falsch berechnete Beträge und verschobene Texte, sowie Fehler in der Eingabeprüfung. Hinzu kommen Performanzprobleme wie zu lange Antwortzeiten und Time-Out-Unterbrechungen. Die Benutzer können vorübergehend mit solchen Mängeln leben, aber irgendwann stören sie und bis zur endgültigen Freigabe müssen sie behoben sein. Der Aufwand für deren Behebung zählt zu den Projektschulden, die aufgrund des Aufwandes errechnet werden können. Bill Curtis schätzt den mittleren Schuldenstand für agile Projekte auf $ 3,61 pro Anweisung. Dies ist das absolute Maß der Schulden. Es ist auch möglich, technische Schulden relativ zu den Kosten der Entwicklung zu messen.

Rechtzeitige Problemaufdeckung zur Vermeidung von technical debts

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 rechtzeitiger Kontrollmaßnahmen. Dazu gehören Reviews der User Stories, die Prüfung des Codes, die Abnahme der Unit-Testergebnisse und einen fortdauernden Integrationstest.

Beim Review der Stories geht es darum, die Story-Texte zu analysieren, zu ergänzen und notfalls nachzubessern. Oft wird der Product Owner etwas übersehen oder unzureichend erklären. Die Tester sollen ihn darauf aufmerksam machen und mit ihm zusammen die fehlenden Punkte nachholen und die unzureichenden Passagen klären.

Bei der Prüfung des Codes können die Tester die Konformität mit den Codierregeln, die Einhaltung der Architekturrichtlinien und die Gestaltung des Codes bewerten. Viele Versäumnisse wie fehlende Sicherheitsprüfungen und mangelnde Fehlerbehandlung lassen sich nur im Code erkennen. Eine automatisierte Codeanalyse ist eine gute Möglichkeit diese schnelle Rückkopplung zu verwirklichen. Bei der Abnahme der Unit-Testergebnisse haben die Tester darauf zu achten, dass es genügend und qualitativ gute Testfälle gibt und eine ausreichende Modultestüberdeckung erreichen. Es ist nicht unbedingt ihre Aufgabe, den Unit-Test selber zu machen, obwohl es agile Projekte gibt, wo dies geschieht.

Die agilen Tester sollten bemüht sein, den Entwicklern immer rasch Feedback geben zu können. “Continuous Integration” macht dies möglich. 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 an die Entwickler zurückgemeldet werden. Dies ist der entscheidende Vorteil gegenüber der konventionellen, bürokratischen Qualitätssicherung, bei der es oft Wochen dauert, bis die Fehlermeldungen und Mängelberichte an die Entwickler zurückgemeldet werden konnten. So gingen wertvolle Entwicklerstunden verloren.

In der agilen Entwicklung ist dies nicht mehr der Fall. Es gibt keine derartigen Leerzeiten mehr. Dafür müssen die Tester ständig hinter den Entwicklern herlaufen, um das gleiche Tempo zu bewahren, wie die Entwickler selbst. Dies hat zur Folge, dass Tester sich in der Entwicklungsumgebung gut auskennen, über leistungsfähige Werkzeuge verfügen und ein gutes Verhältnis zu den Entwicklern haben müssen. 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. Sie müssen gewährleistet werden. Sie sind auch der Grund, warum die Tester mit den Entwicklern zusammen sein sollten. Ob sie wirklich physisch präsent sein müssen, ist eine andere Frage. Hier scheiden sich die Geister.

Was ist “done”?

Auf den Belgium Testing Days im Jahre 2012 sind Johanna Rothman und Lisa Crispin auf diese Problematik eingegangen. Die Frage ist, was ist “done”. Nach Johanna Rothman ist das eine Frage, die das ganze Team beantworten muss. Die Tester sollen jedoch die Diskussion auslösen und vorantreiben. Sie sollen auch die Diskussion mit Argumenten für mehr Qualität füttern. Rothman behauptet “you have to get the team thinking about what is done. Does it mean partially done, as in it is ready for testing or fully done, as in it is ready for release?” Ein gewisser Qualitätsstand ist erforderlich, um ein vorübergehendes Release freizugeben. Ein ganz anderer Qualitätsstand ist erforderlich, um das Produkt endgültig fertig zu deklarieren. Zwischen diesen beiden Zuständen liegt ein weiter Weg. Die Tester müssen dafür sorgen, dass die Entwicklung weitergeht, bis der Sollzustand erreicht ist. Sie müssen den Product Owner davon überzeugen, dass dies erforderlich ist. Sonst verschiebt man die Probleme nur auf die Wartung, wie es früher bei konventionellen Entwicklungsprojekten der Fall war. Rothman schlägt deshalb vor, Kanban Fortschrittsbretter zu verwenden, um den relativen Qualitätsstand einzelner Komponenten darzustellen. Damit kann jeder sehen, wie weit die Komponenten vom gewünschten Qualitätsstand entfernt sind. Eigentlich braucht das Team zwei Fortschrittsbretter, eins für den Funktionenstand und eins für den Qualitätsstand.

Der funktionale Stand eines Software-Produktes ist leichter zu beurteilen, als der qualitative. Es ist sichtbar, ob eine Funktion vorhanden ist oder nicht. Der Qualitätsstand ist nicht so ohne weiteres sichtbar. Wie viele Fehler noch in der Software stecken, kann man erst wissen, wenn man alle Funktionen der Software getestet hat. Wie gut der Code ist, kann man erst beurteilen, wenn man den Code ausführlich analysiert hat, und wie gut das Gesamtsystem ist, kann man erst beurteilen, wenn man es eine Weile verwendet hat. Die besten Indikatoren für die Qualität der Software ist die Anzahl der bisher gefundenen Fehler relativ zur funktionalen Testüberdeckung und die Anzahl der Codemängel relativ zur Anzahl der geprüften Code-Anweisungen. Für beide Maße sollte es Sollwerte geben, welche die Tester vorschlagen und mit den anderen Teammitgliedern abstimmen. Damit wird die Position der einzelnen Komponente am Kanban-Board fixierbar und der Abstand des Istzustandes vom Sollzustand für alle im Team erkennbar.

Lisa Crispin weist darauf hin, dass die Softwarequalität das endgültige Maß für die agile Entwicklung ist. Der funktionale Fortschritt darf nicht auf Kosten der Softwarequalität gewonnen werden. Nach jedem Release – alle 2 bis 4 Wochen – soll die Qualität wieder gemessen werden. Wenn sie nicht ausreichend ist, kann sie im Laufe des nächsten Releases neben der funktionalen Weiterentwicklung nachgebessert werden. Wenn sie allzu schlecht ist, muss das nächste Release ein Überarbeitungs-Release sein, bei dem die Fehler entfernt werden und die Software refaktoriert wird. Crispin räumt sogar ein separates Qualitätssicherungs-Team ein, welches neben dem Entwicklungsteam daran arbeitet, die Qualität der erstellten Software zu verfolgen und an das Entwicklungsteam zu berichten. Damit wäre die alte Trennung zwischen Entwicklung und Test wieder da.

Johanna Rothman meint, die Tester müssen mitbestimmen, was “done” bedeutet, und das vom Anfang des Projektes an. “To be done also means that the quality criteria set by the team are met”. Dies hat zur Folge, dass diese Kriterien von allen Beteiligten akzeptiert und praktiziert werden. Jeder im Team muss sich seiner Verantwortung für die Qualität bewusst sein und seinen Teil dazu beitragen. “Everybody in the team needs to take responsibility for quality and for keeping technical debt at a manageable level. The whole team has to make a meaningful commitment to quality”. 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.