Literatur zur Einführung testgetrieber Softwareentwicklung gesucht

[Christian Soltenborn]

Hallo zusammen,

aller Voraussicht nach werde ich demnächst in meiner Firma die Aufgabe bekommen, automatisches Testen in unseren Entwicklungsprozess zu integrieren. Ich verfüge zu dem Thema bereits über halbwegs solide Kenntnisse (so hoffe ich zumindest) aus Entwicklersicht, aber leider nicht aus Managementsicht.

Kennt jemand Literatur, die sich mit dieser Fragestellung aus Managementsicht beschäftigt? Z.B. erhoffe ich mir Antworten auf Fragen wie die folgenden:

• Gibt es "Standard-Vorgehensweisen" für solche Projekte?
• Um wieviel sinkt die Produktivität in der "Einführungsphase"? (Dazu habe ich bisher nur [1] gefunden)
• Wie lange sollte man für eine solche Einführungsphase einplanen?
• Gibt es Ansätze, um (grob) den erwarteten Return on Investment abzuschätzen?
• Wie geht man mit der schon vorhandenen Codebasis um? Ich kenne [2] (sehr empfehlenswert!), aber die "Strategieebene" kommt dort recht kurz (und ist wohl auch out of scope)

Die Literaturempfehlungen dürfen auch gerne in englischer Sprache sein!

Danke im Voraus und beste Grüße

Christian Soltenborn

[1] https://groups.yahoo.com/neo/groups/testdrivendevelopment/conversations/topics/29461

[2] Michael Feathers: Working Effectively with Legacy Code. Prentice Hall, 2005

[Ralf Westphal]

Schön, dass es mit automatisierten Tests losgehen soll.

Aber leider hört sich das Vorgehen nicht erfolgversprechend an. Da ist wieder ein Masterplan am Start. Tut mir leid, das so sagen zu müssen.

Es beginnt schon mit "automatisches Testen". Was ist damit gemeint? Unit Tests, Integrationstests, Akzeptanztests? Tests durch das UI hindurch? Und was steckt unten drunter? RDBMS oder Dateisystem oder Kommunikation mit SAP? Ohne Definition keine Antwort auf Fragen wie "Um wieviel sinkt die Produktivität?".

Aber auch ohne die Definition:

Um wieviel sinkt die Produktivität? Das kann erstens keiner für euer Szenario sagen - und zweitens kann das ohnehin keiner sagen, solange die heutige Produktivität nicht gemessen wird. Oder kannst du sagen, wie produktiv ist seid? Worin messt ihr das?

Wie lange dauert einer Einführung? Von was? Was ist das Kriterium, dass eine Einführung beendet ist und nun die Produktivphase begonnen hat? Wenn eine Testabdeckung von X% erreicht ist? Oder wenn Y% der Entwickler die Frameworks zu Z% kennen?

Und auch wenn ich die Frage nach dem ROI verstehe... Sie zeigt doch, dass nicht verstanden ist, worum es geht. Sorry. Denn was muss man denn dafür wissen:

1. Die Höhe des Investments. Die kann nicht angegeben werden. Weil nie klar sein wird, wieviel ins Testen investiert wird. Oder wollt ihr in Zukunft erheben, "2,45 Std Aufwand in Tests gesteckt gegenüber 4,23 Std in Produktionscode"?

2. Die Höhe des Returns, d.h. des Betrages, der durch (!) das Testen gewonnen wird, ist sehr wahrscheinlich immer unklar. Oder messt ihr heute, was ihr durch nicht-Testen an Kosten habt? Das mindeste wäre, dass ihr beim Support zählt, wieviele Bugs dort auflaufen. Deren Zahl müsste ja über die Zeit im Mittel sinken. Aber auch das ist keine verlässliche Zahl. Denn die könnte auch gleich bleiben bei steigendem autom. Testaufwand, weil eure Software komplexer wird.

Vorhandene Codebasis? Die nachträglich mit Tests auszustatten funktioniert nicht. Das Kind ist im Brunnen. Vergesst größere Refaktorisierungsorgien.

Meine Empfehlung:

1. Wenn ein Bug aufschlägt, dann dafür gezielt Reproduktionstests in Rot schreiben und auf Grün bringen.

2. Wenn irgendwo refaktorisiert werden muss, dann dafür Tests schreiben, die heute grün sind und über die Refaktorisierung grün bleiben.

3. Wenn ihr neue Sachen schreibt, dann gleich richtig mit Tests.

Und ansonsten: Nicht von blinden/naiven Managementforderungen ablenken lassen. Nicht glauben, dass es anytime soon "ein Ende" gibt. Ihr steigt gerade erst in Clean Code ein. Damit werdet ihr noch Jahre zu tun haben. Aber ihr wollt ja auch noch Jahrzehnte im Business bleiben :-)

Die Fragen nach dem ROI usw. hören sich an, als würde ein Raucher fragen, ab wann es sich lohne, mit dem Rauchen aufzuhören. Wann ist break even beim Nichtrauchen? Lohnt es sich erst ab 1 Jahr oder ab 10 Jahren? Für den Fall sind wir uns hoffentlich einig, ist die Antwort klar: Regelmäßiges Rauchen ist immer der Gesundheit abträglich - und zwar auf unabsehbare Weise. Wer regelmäßig raucht, spielt mit seiner Gesundheit, mit seinem Leben.

Das ist ok. Darf jeder machen. Live fast, die young - das ist eine legitime Lebenseinstellung. Nur darf man sich dann nicht beklagen, wenn die Kondition schneller sinkt als bei anderen oder andere Malaisen einsetzen, weil der Körper konstant und immer mehr belastet wird.

Wer ein gesundes langes Leben haben will, der fängt am besten nicht mit dem Rauchen an. In einer Welt, in der viele Belastungen nicht vermieden werden können (z.B. im Bereich Ernährung oder Luftverschmutzung), ist eine solche zusätzliche Belastung freiwillig einzugehen töricht.

Dito bei der Softwareentwicklung mit dem nicht-Testen. Auch das ist eine Sucht wie das Rauchen. Denn es wird für kurzfristigen Gewinn (Produktivitätskick) die mittel- bis langfristige Projektgesundheit aufs Spiel gesetzt. Da muss man genauso wenig nach dem ROI fragen wie beim Rauchen.

In jedem Fall für die viel Erfolg bei der Umsetzung des Masterplans ;-)

-Ralf

[Christian Soltenborn]

Hallo Ralf,

erst mal vielen Dank für Deine schnelle und ausführliche Antwort! Ein paar Kommentare bzw. Nachfragen inline...

Am Montag, 22. September 2014 11:51:45 UTC+2 schrieb Ralf Westphal:

Schön, dass es mit automatisierten Tests losgehen soll.

Aber leider hört sich das Vorgehen nicht erfolgversprechend an. Da ist wieder ein Masterplan am Start. Tut mir leid, das so sagen zu müssen.

Den Einwand verstehe ich nicht ganz - willst Du auf einen "Masterplan" im Gegensatz zu einem agilen Vorgehen hinaus? Dann habe ich mich vielleicht nicht genau genug ausgedrückt... Zu einem "Masterplan" gehören für mich Überlegungen wie "Wann muss ich unsere Entwickler in welchen Inhalte schulen?", "Welche Infrastrukturmaßnahmen (z.B. CI-Server) sind nötig?", "Wie bringe ich welchen Code unter Test? (siehe unten)". Das ist m.E. aber a) unerlässlich und b) orthogonal zum eigentlichen (agilen) Entwicklungsvorgang.

Es beginnt schon mit "automatisches Testen". Was ist damit gemeint? Unit Tests, Integrationstests, Akzeptanztests? Tests durch das UI hindurch? Und was steckt unten drunter? RDBMS oder Dateisystem oder Kommunikation mit SAP? Ohne Definition keine Antwort auf Fragen wie "Um wieviel sinkt die Produktivität?".

Aber auch ohne die Definition:

Um wieviel sinkt die Produktivität? Das kann erstens keiner für euer Szenario sagen - und zweitens kann das ohnehin keiner sagen, solange die heutige Produktivität nicht gemessen wird. Oder kannst du sagen, wie produktiv ist seid? Worin messt ihr das?

Wie lange dauert einer Einführung? Von was? Was ist das Kriterium, dass eine Einführung beendet ist und nun die Produktivphase begonnen hat? Wenn eine Testabdeckung von X% erreicht ist? Oder wenn Y% der Entwickler die Frameworks zu Z% kennen?

Und auch wenn ich die Frage nach dem ROI verstehe... Sie zeigt doch, dass nicht verstanden ist, worum es geht. Sorry. Denn was muss man denn dafür wissen:

1. Die Höhe des Investments. Die kann nicht angegeben werden. Weil nie klar sein wird, wieviel ins Testen investiert wird. Oder wollt ihr in Zukunft erheben, "2,45 Std Aufwand in Tests gesteckt gegenüber 4,23 Std in Produktionscode"?

2. Die Höhe des Returns, d.h. des Betrages, der durch (!) das Testen gewonnen wird, ist sehr wahrscheinlich immer unklar. Oder messt ihr heute, was ihr durch nicht-Testen an Kosten habt? Das mindeste wäre, dass ihr beim Support zählt, wieviele Bugs dort auflaufen. Deren Zahl müsste ja über die Zeit im Mittel sinken. Aber auch das ist keine verlässliche Zahl. Denn die könnte auch gleich bleiben bei steigendem autom. Testaufwand, weil eure Software komplexer wird.

Zu meiner Entschuldigung: Ich wollte hier keine Consulting-Leistungen in Anspruch nehmen, sondern hatte gehofft, dass es Literatur gibt, die genau solche Fragen (danke dafür!) aufwirft und Ansätze zur Beantowrtung aufzeigt... Die ROI-Frage habe ich gestellt, weil es gut sein kann, dass sie mir gestellt werden wird. Ein "Ist leider nicht messbar, vertraut mir einfach!" scheint mir da nicht zielführend zu sein. Die Hoffnung war, dass es entweder sehr einfache Ansätze gibt, das sehr grob abzuschätzen, oder aber eine überzeugende(re) Antwort zur Selbstverteidigung :-)

Vorhandene Codebasis? Die nachträglich mit Tests auszustatten funktioniert nicht. Das Kind ist im Brunnen. Vergesst größere Refaktorisierungsorgien.

Meine Empfehlung:

1. Wenn ein Bug aufschlägt, dann dafür gezielt Reproduktionstests in Rot schreiben und auf Grün bringen.

2. Wenn irgendwo refaktorisiert werden muss, dann dafür Tests schreiben, die heute grün sind und über die Refaktorisierung grün bleiben.

3. Wenn ihr neue Sachen schreibt, dann gleich richtig mit Tests.

Die Schritte 1-3 beschreiben im Wesentlichen meinen Plan. Ich denke auch nicht daran, unser System Refaktorisierungsorgien zu unterziehen (jedenfalls nicht kurz- oder mittelfristig). Allerdings liest sich das bei Feathers m.E. etwas anders: Der Großteil seines Buches beschäftigt sich ja gerade damit, alten Code (Feathers: Code ohne Tests ist Legacy-Code) unter Test zu bringen. Er schlägt im Wesentlichen vor, bei neu zu schreibendem Code den Code, von dem der neue Code abhängig ist (bzw. sein wird) unter Test zu bringen (und den neuen sowieso). Dadurch erreicht man im Laufe der Jahre (!) hoffentlich eine vernünftige Testabdeckung, die dann irgendwann auch größere Refactorings erlauben wird.

Soweit sein Ansatz - ob das so funktionieren kann, mag ich nicht beurteilen, dafür fehlt mir die Erfahrung. Mein Ansatz wäre ungefähr gewesen, unseren alten Code in Risikoklassen zu unterteilen und dann unterschiedlich zu handhaben:

• Risiko hoch: Code aktiv unter Test bringen (+ "Risiko mittel")
• Risiko mittel: Code unter Test bringen, wenn in seinem "Kontext" neuer Code hinzugefügt wird (+ "Risiko niedrig")
• Risiko niedrig: Code unter Test bringen, wenn ein Fehler behoben wird (also Dein 1. Schritt)

Unabhängig davon ist (für mich zumindest) klar, dass neuer Code immer mit Tests unterlegt wird.

Gibt es hier in der Gruppe andere Erfahrungen mit dem Unter-Test-bringen von altem Code?

 

Und ansonsten: Nicht von blinden/naiven Managementforderungen ablenken lassen. Nicht glauben, dass es anytime soon "ein Ende" gibt. Ihr steigt gerade erst in Clean Code ein. Damit werdet ihr noch Jahre zu tun haben. Aber ihr wollt ja auch noch Jahrzehnte im Business bleiben :-)

Ich habe Deinen Smiley schon zur Kenntnis genommen, aber trotzdem: "Nicht von blinden/naiven Managementforderungen ablenken lassen" ist natürlich leichter gesagt als getan :-)

 

Die Fragen nach dem ROI usw. hören sich an, als würde ein Raucher fragen, ab wann es sich lohne, mit dem Rauchen aufzuhören. Wann ist break even beim Nichtrauchen? Lohnt es sich erst ab 1 Jahr oder ab 10 Jahren? Für den Fall sind wir uns hoffentlich einig, ist die Antwort klar: Regelmäßiges Rauchen ist immer der Gesundheit abträglich - und zwar auf unabsehbare Weise. Wer regelmäßig raucht, spielt mit seiner Gesundheit, mit seinem Leben.

Musste es wirklich ein Vergleich mit dem Rauchen sein für mich? :-)

 

Das ist ok. Darf jeder machen. Live fast, die young - das ist eine legitime Lebenseinstellung. Nur darf man sich dann nicht beklagen, wenn die Kondition schneller sinkt als bei anderen oder andere Malaisen einsetzen, weil der Körper konstant und immer mehr belastet wird.

Wer ein gesundes langes Leben haben will, der fängt am besten nicht mit dem Rauchen an. In einer Welt, in der viele Belastungen nicht vermieden werden können (z.B. im Bereich Ernährung oder Luftverschmutzung), ist eine solche zusätzliche Belastung freiwillig einzugehen töricht.

Dito bei der Softwareentwicklung mit dem nicht-Testen. Auch das ist eine Sucht wie das Rauchen. Denn es wird für kurzfristigen Gewinn (Produktivitätskick) die mittel- bis langfristige Projektgesundheit aufs Spiel gesetzt. Da muss man genauso wenig nach dem ROI fragen wie beim Rauchen.

Kleiner Einwand: Bei mir rennst Du da offene Türen ein, aber ich glaube nicht, dass die Vorteile automatischer Tests schon so eindeutig nachgewiesen sind wie die von "nicht rauchen". Mal davon abgesehen, dass man beim Rauchstopp nicht viel falsch machen kann (außer wieder anfangen - glaub mir: da weiß ich, wovon ich rede :-) ). Das sieht bei automatischen Tests ganz anders aus: Nach meiner Einschätzung können Tests im Extremfall mehr schaden als nützen (auch wenn man sich wahrscheinlich schon etwas Mühe geben muss, um das zu erreichen). Damit will ich nur sagen, dass das Management sich mit einem solchen Vergleich ggf. nicht zufrieden geben wird, und zwar vermutlich nicht ganz unberechtigterweise...

Viele Grüße,

Christian

[Thomas Maierhofer]

Neben der Methodik stellt sich irgendwann auch die Frage nach den Tools. Für uns ist automatisiertes Testen Teil des Build-Prozesses (grob: Bauen, Testen, Paketieren, Veröffentlichen)

Ich selber hab das Problem, dass der Build-Prozess ne Geschichte ist, die irgendwo auf einem Server läuft und meistens irgendwie äzend konfiguriert werden muss. Ich wollte für men neues Startup einen viel agileren Ansatz haben, und hab einen Teil des Build Prozesses vom Buildserver entkoppelt.

Der Witz an der ganzen Sache ist nun, das jeder Entwickler den Build-Prozess (bzw. den herausgelösten Teil) auf seiner Maschine abfahren kann und soll. Somit ist es ganzen Teams möglich den Buildprozess kointunierlich weiterzuentwickeln, also z.B. Tests zu integrieren usw. ohne sich mit anderen koordinieren zu müssen. Der Build-Ppozess ist XML/Script konfiguriert und in der Quellcodeverwaltung enthalten. Somit kann der der ganz normale Fork/Merge mechanis mus genutzt werden um die Erweiterungen des Build Prozesses in die Main Development Line zu mergen. Da der einzelne Entwickler nun die Möglichkeit hat den Build-Prozess zu entwickeln und zu testen, ist die Chance das der Build in der Main Branch bricht minimal.

Da wir vorher schon ALM mit Powershell gemacht haben, ist die Toolbox auch in Powershell entwickelt. Das ist die BuildConfig.xml für das Open Source Projekt NHunspell :

http://sourceforge.net/p/nhunspell/code/ci/default/tree/NHunspell/BuildConfig.XML

Auf dem Build Server (Wir nutzen Jenkins) sieht der Powershell Build Step so aus:

Import-Module buildtools
Push-Location
Set-Location NHunspell
Clear-Build
Complete-Build
Pop-Location

so, und das ist nämlich genau der Witz an der Sache, dass der Build Server keine konkrete Konfiguration des Builds mehr hat, sondern die aktuelle Konfiguation über die Code-Repository bekommt.

Das ist eine Lösung für uns, die natürlich in keinerlei Literatur beschrieben ist bzw. sicher auch kein standardisiertes Vorgehen ist. Auch Kostenabschätzungen gibt es hierfür nicht, weil es neu ist.

Auf was ich raus will: Automatisiertes Testen (z.B. mittels eines automatisierten Build Prozesses auf einem CI Server) ist ne firmenspezifische Sache und kein standardisierter Prozess. Es muss entwickelt werden und damit hängt alles an den Leuten und den bestehenden Strukturen.

[Christian Soltenborn]

Hallo Thomas,

das klingt sehr interessant - tatsächlich hatte ich auch schon das Problem auf dem Schirm, dass man einerseits einen Build auf dem Buildserver fahren und dort (alle) Tests ausführen will, andererseits die Entwickler auch auf ihrer Maschine möglichst einfach bauen und (eine Auswahl von) Tests ausführen können sollen. Wenn es bei uns so richtig konkret wird, werde ich mir Deine Lösung noch mal genau anschauen (und vielleicht sogar nachzufragen wagen)!

Danke auch dafür, dass Du noch mal ganz klar darauf hinweist, dass das sehr firmenspezifisch ist und keine Standardlösung existiert. Ich hatte halt gehofft, dass es bestimmte Dinge gibt, die man bei einer solchen Einführung auf jeden Fall (oder auf gar keinen Fall) machen sollte, und dass die irgendwo aufgeschrieben sind. Scheint aber nicht der Fall zu sein...

Viele Grüße,
Christian

Am Montag, 22. September 2014 11:25:51 UTC+2 schrieb Christian Soltenborn:

[Sebastian Jancke]

Thomas,

was du beschreibst ist seit Jahren Standard im Java-Ökosystem ;-) Manchmal muss ich mich sehr über MS wundern... 

Testen ist integraler Teil eines Builds im Java-Ökosystem (siehe Apache Maven). Hier ist es also sehr wohl standarisiert für sehr sehr viele Projekte und große Unternehmen und gleichzeitig dennoch flexibel für lokale Spezialitäten. Das sollte in .Net, Ruby, ... genauso gehen. 

Aus meiner Sicht darf es da keinen Unterschied machen. Lokal und auf dem Server sollte immer das gleiche Buildskript im Kern laufen. Der CI hat idR natürlich weitere Schritte, Analysen oder ganze Buildstufen hintendran. Wenn das "ätzend" zu konfigurieren ist, wechsle das Tool. Aus ätzend folgt nach meiner Erfahrung häufig "instabil" oder "unflexibel".  Und dazu gibt es heute eigentlich keine Not mehr ;-)

Die eigentliche Herausforderung liegt heute nicht in diesen technischen Details sondern für mich eher in der Frage nach einer konsequenten Teststrategie, die Waste vermeidet und die Energie vor Allem auf die Wesentlichen Details eines Systems richtet. 

Gruß

Sebastian

--
Sie erhalten diese Nachricht, weil Sie in Google Groups E-Mails von der Gruppe "Clean Code Developer" abonniert haben.
Wenn Sie sich von dieser Gruppe abmelden und keine E-Mails mehr von dieser Gruppe erhalten möchten, senden Sie eine E-Mail an clean-code-devel...@googlegroups.com.
Wenn Sie in dieser Gruppe einen Beitrag posten möchten, senden Sie eine E-Mail an clean-code...@googlegroups.com.
Gruppe besuchen: http://groups.google.com/group/clean-code-developer
Weitere Optionen finden Sie unter https://groups.google.com/d/optout.

[Jan Schubert]

Generell zum Lesen kann ich nur safaribooksonline.com empfehlen. Da kann man gegen eine monatliche Gebühr, sehr viele Fachbücher lesen. Da sind Verlage, wie z.B. Addison-Wesley, O'Reilly oder auch Microsoft Press Deutschland mit ihren Büchern vertreten. Man kann sich somit selbst einen ganz guten Überblick über die Buücher machen, indem man das ein oder andere einfach mal anließt! Auch die Volltextsuche über alle Bücher ist sehr empfehlenswert!