Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
Die beste Maßnahme für einen guten, erholsamen Schlaf ist das Testen Ihrer Software – und zwar noch vor dem Go-Live. Denn wer seine Software vor der Inbetriebnahme auf Herz und Nieren prüft, minimiert das Risiko von Fehlern und Ausfällen erheblich und muss diesbezüglich keinerlei Sorgen mit ins Bett nehmen.
Zum Beispiel die, dass der mögliche Ausfall einer einzelnen Softwarefunktionen negativen Einfluss auf das Betriebsergebnis haben könnte – etwa, weil der Endkunde in der Applikation auf unvorhergesehene Stolperfallen stößt, deren Folgen je nach Kritikalität des Einsatzbereiches z. B. Umsatzeinbußen oder Schadenersatzansprüche hervorrufen können.
In diesem Artikel erfahren Sie, wie man diese Risiken mithilfe von Test Driven Development abschwächen kann.
Warum „klassisches“ Testen nicht mehr zeitgemäß ist
„Kann mir nicht passieren, wir haben vor dem Release ja alles getestet“, hört man in manchen Softwareprojekten. Allerdings ist der klassische Testingprozess bei der Entwicklung von Standardsoftware relativ weit am Ende angesiedelt:
Neue Anforderungen und ihre Seiteneffekte
Unabhängig davon, wie agil man unterwegs ist – zwischen Implementierung und Release ändern sich Anforderungen: Änderungen an Features können jedoch unbeabsichtigte Seiteneffekte zur Folge haben, die unbemerkt auf das Produktivsystem zu gelangen drohen.
Selbst nach einem gut getesteten und erfolgreichen Release hat die Implementierung einer neuen Anforderung Auswirkungen auf die bestehende Funktionalität; selbst ein Update einer Drittbibliothek kann Seiteneffekte verursachen. Auch wenn unklar ist, wer oder was ein Problem verursacht hat: Tritt dieser Fall einmal ein, kann das weitreichende Folgen haben, denn auch eine Fehlerbehebung oder Konfiguration kann Folgefehler verursachen. Die Entwicklung verläuft dann plötzlich so, wie sich ein Elefant im Porzellanladen verhält. Alleine ein Patchrelease kann teuer werden, wenn mehrere Stakeholder an Installation und Betrieb der Anwendungen beteiligt sind. Und dann das Team: übermüdete Entwickler, die seit Tagen oder Wochen Überstunden schieben, Projektleiter, die irgendwie versuchen, das nächste Release zu retten und ein unzufriedener Auftraggeber, der draufzahlt.
Um solche fiktiven Horrorszenarien gar nicht erst Realität werden zu lassen, bietet es sich an, Software testgetrieben zu entwickeln.
Test Driven Development
Was bedeutet es, „testgetrieben“ zu entwickeln? Wenn eine Anforderung spezifiziert ist und implementiert werden soll, wird nicht, wie sonst üblich, die Funktionalität zuerst implementiert, sondern zunächst die Tests; Tests, die ohne die dazugehörige Implementierung natürlich zunächst fehlschlagen müssen. Erst dann wird die Implementierung durchgeführt. Auf diese Weise bestimmt also der Test, wie die Software entwickelt werden muss, und zeigt an, ob sie die Anforderungen erfüllt. Sobald die Implementierung abgeschlossen ist, muss ergo auch der Test erfolgreich abschließen, gemäß einem Ampelsystem zeigt er dann „grün“. Dies führt zu einer Softwarearchitektur, die genau auf die Anforderungen abgestimmt und gut testbar ist. Schlägt ein Test fehl, gibt es entweder noch keine Implementierung dazu oder es liegt ein Problem im Quellcode vor. Softwareentwickler sprechen dann von „roten“ Tests.
Die Tests werden auf verschiedenen Ebenen und für verschiedene Zwecke geschrieben. Integrationen zu anderen Systemen können geprüft und behobene Seiteneffekte mittels eigener Tests ausgeschlossen werden. Test Driven Development bedeutet kurz gesagt: „Test first“.
Mit solchen Tests erhält man von Anfang an eine hohe Testabdeckung und damit eine Risikominderung für das Softwareprojekt.
Qualität sichtbar machen: Wie Test Driven Development im Projekt hilft
Die Tests sind eine Art Versicherung für das Projekt. Denn wenn alle relevanten Anforderungen und Funktionen durch Tests abgesichert sind, können diese automatisiert durchlaufen werden. Bevor eine Änderung überhaupt in die Versionskontrolle gelangt, kann vorher schon geprüft werden, ob die Anwendung im Ganzen weiterhin funktioniert. Über Continuous Integration (CI) erhält man ein automatisiertes Feedback, ob die Gesamtanwendung einwandfrei läuft. Auch kurzfristige Änderungen sind damit plötzlich möglich, denn Software ist nie wirklich fertig. Mit diesen Verfahren erreicht man auch Regressionstests, denn Tests alter Funktionen müssen genauso erfolgreich bleiben wie die getesteten Änderungen. Als Entwickler merkt man also ganz schnell, ob man etwas gravierend zerstört hat – und das, bevor der Fehler Schaden anrichten kann.
Die Tests decken die gesamte Funktionalität der Software ab, man spricht deshalb von Testabdeckung: Eine hohe Testabdeckung bedeutet weniger Seiteneffekte und dadurch eine höhere Qualität. Damit ist Test Driven Development ein Qualitätskriterium und ein Erfolgsfaktor für das Softwareprojekt.
Bonus für neue Entwickler: Wenn man die Tests durchschaut, versteht man schnell, worum es im Projekt geht und ist schnell handlungsfähig.
Wie bringt man Test Driven Development ins Projekt?
Das wichtigste ist zunächst, überhaupt tätig zu werden: 1 % Testabdeckung ist besser als 0 % Testabdeckung, unabhängig davon, ob zusätzlich manuell getestet wird. Zum Projektstart ist der Aufwand für Tests geringer. Mehr Aufwand hat man, wenn man beispielsweise bereits ein paar Releases oder Sprints ohne Unittests durchgeführt hat: Die Softwarearchitektur ist dann noch nicht auf das Testen der einzelnen Anforderungen abgestimmt. Wer also aus Kostengründen zunächst darauf verzichtet, hat im Nachhinein größere Aufwände, da zu den Unittests auch die Anwendung grundlegend umgebaut werden muss.
Wer mit testgetriebener Entwicklung starten will, setzt sich zunächst ein Ziel für die Testabdeckung, zum Beispiel alle Anforderungen zu testen. Wer es gerne messbar hat, kann die Testabdeckung in Prozent über den Quelltext messen (Stichwort Codecoverage). Ein Richtwert für eine solide Testabdeckung sind 80 %, heißt 80 % des Quellcodes sollten durch Testfälle automatisiert ausgeführt werden. Neben dem Ziel legt man fest, auf welchen Ebenen die Tests durchgeführt werden sollen. Einzelne Funktionen sind schnell getestet, allerdings benötigt man dann mehr Tests. Prüft man die Integration oder macht Oberflächentests, sind diese meist schwergewichtig und müssen aufwendig gepflegt werden. Was konkret benötigt wird, hängt ganz vom Projekt ab, für den Start empfiehlt es sich, mit Anforderungen und der Fachlichkeit zu beginnen. Den Aufwand sollte man nicht unterschätzen, denn Testcode kann bis zu 2/3 des Gesamtquelltextes einnehmen und will ebenfalls gewartet werden. Spezialwerkzeuge und Sonderwünsche können den Aufwand nochmals steigern, zum Beispiel, wenn verantwortliche Entwickler keinen Einfluss auf die Wahl der Werkzeuge oder Methodik haben. Je nach Risiko und Kritikalität der Anwendung lohnt es sich, mehr Aufwand zu betreiben.
Wer schreibt die Tests?
Wenn man Test Driven Development betreiben will, schreiben die Programmierer die Tests. Geeignet sind Entwickler, die verstanden haben, wie hilfreich diese Methodik tatsächlich ist. Bei der Umsetzung gilt aus eigener Erfahrung: Disziplin ist hilfreicher als jedes Werkzeug. Wenn ich verstanden habe, worauf es beim Testen ankommt, und ich die Anwendung selbst manuell testen könnte, kann ich mir Gedanken darüber machen, wie ein Test dafür auszusehen hat. Die Wahl des Testwerkzeuges ist dann nebensächlich, denn die Tests müssen ohnehin bei der Implementierung geprüft und gepflegt werden. Eher sollte man darauf achten, dass die Testsuite schnell einsatzbereit ist und man die Anwendung jederzeit testen kann. Langsame Tests bremsen die Entwicklung unnötig aus. Wenn man also noch auf die Performance der Testausführung achtet, dann kann man wirklich schnell agieren.
Wer also gerne schläft und seine Nächte nicht mit ungewollten Seiteneffekten verbringen will, sollte in Betracht ziehen, seine Software testgetrieben zu entwickeln. 1 % Testabdeckung ist schon mal ein Anfang, das Ziel sollte jedoch höher sein.
Empfehlung der Redaktion: Lesen Sie auch den Blogbeitrag zum Thema Clean Code von Arek Roczniewski.
