Testgetriebene Entwicklung: Vorteile, zentrale Statistiken & Studien
In diesem Artikel werte ich einige Statistiken und Studien zur testgetriebenen Entwicklung (TDD) aus, um zu verstehen, wie sie eingesetzt wird, welche Vorteile sie bietet und welche Herausforderungen Teams mit diesem Ansatz haben.
Traditionell verläuft die Softwareentwicklung linear. In den letzten Jahrzehnten jedoch, mit der immer größeren Beliebtheit agiler Systeme (bis zu 87 % der Teams arbeiten nach einem agilen oder agil-ähnlichen Ansatz), hat die Softwareentwicklung begonnen, verschiedene Methoden zu übernehmen, die die Anforderungen und Eigenheiten des jeweiligen Projekts berücksichtigen.
Die testgetriebene Entwicklung (TDD) ist eine der Methoden, die im Bereich der agilen Softwareentwicklung zunehmend Beachtung findet.
In einer von der "Institute of Electrical and Electronics Engineers" veröffentlichten Forschungsarbeit sagen die Autoren Yahya Rafique und Vojislav Misic: „Die testgetriebene Entwicklung (TDD) gehört zu den Grundpraktiken des Extreme Programming (XP) Entwicklungsprozesses“ (Quelle).
Demjenigen, dem die Entwicklung von TDD zugeschrieben wird, wird nachgesagt, er habe „2003 erklärt, dass TDD zu einfachen Designs anregt und Vertrauen schafft“ (Quelle). Dennoch gibt es weiterhin Fragen bezüglich der behaupteten Produktivitäts- und Qualitätsgewinne von TDD.
Wir haben uns die Zeit genommen, die neuesten TDD-Statistiken zu recherchieren, um die aufgestellten Behauptungen zu überprüfen.
Der Artikel beginnt mit einer Definition des TDD-Konzepts und wie es sich vom traditionellen Ansatz unterscheidet. Anschließend betrachten wir Statistiken, die die Behauptungen zu TDD entweder belegen oder widerlegen.
Was ist testgetriebene Entwicklung?
Testgetriebene Entwicklung ist ein Ansatz, bei dem ein Test geschrieben wird, bevor der Softwareentwickler den Produktionscode erstellt, der den Test erfüllt. Die Grundidee dieser Technik besteht darin, dem Code-Autor Zeit zu geben, über sein Design oder die Anforderungen nachzudenken, bevor er funktionalen Code schreibt.
TDD-Prozess
- Test schreiben: Bei TDD beginnen alle neuen Features mit dem Schreiben eines Tests. Der Programmierer muss die Spezifikation und die Anforderungen des Features verstehen. Dafür muss er User Stories und Use Cases durchgehen, um das Ziel des neuen zu entwickelnden Codes zu verstehen.
- Test schlägt fehl: Sobald der Programmierer den Test geschrieben hat, wird dieser ausgeführt. Da der entsprechende Code noch nicht existiert, schlägt der Test fehl. Dies bestätigt, dass das automatisierte Testframework korrekt funktioniert und schließt die Möglichkeit aus, dass der neue Test immer besteht, weil er fehlerhaft ist.
- Code schreiben: Nun weiß der Programmierer, dass das Feature wie gewünscht funktioniert. Er schreibt jetzt den Code, der den Test besteht. Der Code muss nicht perfekt sein oder den Test mustergültig bestehen – das ist nicht entscheidend. Der Entwickler soll nicht mehr Code schreiben, als für die überprüfte Funktionalität erforderlich ist.
- Tests ausführen: Da das Feature wie vorgesehen funktioniert, kann der Programmierer bei jeder neuen Codeveröffentlichung ein Testmanagement-Tool nutzen, um den Test erneut durchzuführen – so wird sichergestellt, dass durch das neue Update keine vorherigen Funktionen fehlerhaft werden.
- Code refaktorieren: Da der Code-Bestand im Laufe der Zeit wächst, muss er kontinuierlich überarbeitet werden. Da sich der Programmierer in den obigen Stufen zunächst ausschließlich auf die Funktionalität konzentriert hat, dient diese Phase der Effizienzsteigerung. Der interne Aufbau des Quellcodes des Programms wird verbessert, während die äußeren Merkmale erhalten bleiben. In diesem Schritt können Dopplungen entfernt und neue Funktionen hinzugefügt werden.
- Wiederholen: Die oben genannten Schritte werden automatisch wiederholt, damit die TDD-Zyklen alle Funktionen abdecken.
Unterschiede zwischen TDD und traditioneller Entwicklung
Um TDD zu verstehen, ist es sinnvoll zu klären, wie es sich von traditionellen Ansätzen der Programmierung unterscheidet.
Der Hauptunterschied liegt darin, dass herkömmliche Methoden einen linearen Prozess verfolgen, während TDD einen zyklischen Ansatz wählt.
Programmierer, die herkömmliche Testmethoden anwenden, beginnen mit der Erstellung des Codes und konzentrieren sich erst am Ende des Entwicklungsprozesses auf den Test. Im Gegensatz dazu beginnt jemand, der dem TDD-Modell (Testgetriebene Entwicklung) folgt, mit der Erstellung des Tests und entwickelt anschließend den Code, der den Test besteht. Dieser Ansatz teilt viele Grundsätze mit der Shift-Left-Bewegung im Software-Testing.
Während der Programmierer, der den traditionellen Ansatz nutzt, auf die Korrektheit des Codes achten kann, läuft er Gefahr, nicht alle Fehler des Codes zu erkennen. Der Programmierer, der die TDD-Methode nutzt, arbeitet so lange am Code, bis dieser durch Refaktorierung den Test besteht. Dies geschieht so lange, bis der Code die gewünschte Funktionalität aufweist – ein Prozess, der wahrscheinlich zu weniger Fehlern führt.
Ist TDD langsamer oder schneller als traditionelle Testentwicklung?
Bezüglich der Frage, ob TDD den Programmierprozess beschleunigt, gibt es widersprüchliche Statistiken aus unterschiedlichen Quellen.
Eine Fallstudie mit Teams von Softwareingenieuren bei Microsoft und IBM kam zu dem Schluss, dass die „Teams bei Verwendung der TDD-Technik einen 15-35%igen Anstieg der anfänglichen Entwicklungszeit erlebten“. Allerdings weist die Studie darauf hin, dass diese Zahlen „subjektiv von der Geschäftsleitung geschätzt“ wurden (Quelle).
Betrachtet man jedoch, dass die Studien von Microsoft und IBM Verbesserungen in der Qualität aufzeigen, könnte man argumentieren, dass TDD auf lange Sicht die Zeit spart, die sonst zum Beheben von Problemen benötigt würde. Die Teams bei Microsoft und IBM stimmten diesem Standpunkt zu (Quelle).
Eine Studie, die sich auf die anfänglichen Wahrnehmungen erfahrener Fachleute beim Einsatz von TDD konzentrierte, kommt zu dem Schluss, dass „nachdem die anfänglichen Schwierigkeiten überwunden sind, zu verstehen, wo man beginnt und wie man einen Test für eine noch nicht existierende Funktion erstellt, die Teilnehmer mehr Vertrauen gewinnen, um neue Funktionen zu implementieren und Änderungen vorzunehmen – dank einer breiten Testabdeckung“ (Quelle). Das scheint darauf hinzudeuten, dass sich mit der Zeit vieles verbessert.
Erick Elliot, Programmierer und Autor von „Composing Software“ und „Programming JavaScript Applications“, schreibt auf der Online-Plattform Medium.com darüber, wie TDD sein Leben verändert hat. Elliot stimmt zu, dass der Prozess anfangs langsam sein kann, sagt aber: „Irgendwann, nach etwa zwei Jahren, geschah etwas Magisches: Ich begann, mit Unit-Tests schneller zu programmieren als jemals zuvor ohne sie“ (Quelle).
Es scheint, dass die Anwendung von TDD anfangs zu einer Verlangsamung führen kann. Betrachtet man jedoch den langfristigen Nutzen, könnte die Zeit, die durch bessere Codequalität eingespart wird, den anfänglichen Mehraufwand ausgleichen. Zudem ist zu erwarten, dass Programmierer mit wachsender Erfahrung in TDD auch schneller werden.
Außerdem gibt es viele weitere Faktoren, die zu berücksichtigen sind, wenn es darum geht, die Zeit bis zu einem hochwertigen Ergebnis zu messen. Mehr dazu erfährst du in Niall Lynchs Folge des QA Lead Podcasts über die Messung von T2Q (Time To Quality).
Führt TDD zu weniger Fehlern?
In der obigen Diskussion wurde als einer der Hauptvorteile von TDD genannt, dass dadurch weniger Fehler entstehen. Aber stimmen die Statistiken dem zu?
Die gleichen oben erwähnten Studien mit den Engineering-Teams von Microsoft und IBM kamen zu dem Ergebnis, dass „die Fehlerdichte vor der Freigabe bei den vier Produkten im Vergleich zu ähnlichen Projekten, die TDD nicht einsetzten, um 40% bis 90% sank.“ Konkret berichteten die IBM-Teams von einem Rückgang der Fehlerdichte um 40%, während die bei Microsoft einen Rückgang um 60-90% meldeten (Quelle).
Stützen Statistiken zur Testgetriebenen Entwicklung die Aussage, dass TDD bessere Qualität liefert?
Laut den Ergebnissen einer Studie, die auf dem 2007 First International Symposium der IEEE in Finnland vorgestellt wurde, berichten Maria Siniaalto und Pekka Abrahamsson, dass TDD nachweislich bessere Codequalität erzeugt als Software, die nicht mit TDD entwickelt wurde (Quelle).
In ihrer Arbeit zitieren Siniaalto und Abrahamsson eine in China durchgeführte Studie, die zu dem Schluss kam, dass TDD die Nachverfolgung von Prozessen und die Schätzung von Aufgaben verbessert. Dieselbe Studie stellt fest, dass „TDD auch das Befolgen konsistenter Praktiken und Richtlinien fördert.“ Dies führt zu höherer Qualität mit weniger Fehlern. Außerdem konnten die Teams, die TDD einsetzten, ihre Fehler schneller beheben (Quelle).
Eine unter Entwicklern durchgeführte Studie – mit durchschnittlich etwa zehn Jahren Berufserfahrung – untersuchte deren Wahrnehmung beim Einsatz von TDD. Hier wird ein Entwickler wie folgt zitiert: „TDD hat mir geholfen, den Code zu verbessern, was ihn lesbarer macht.“ Ein weiterer Teilnehmer berichtet: „TDD ermöglicht eine höhere Wartbarkeit“ (Quelle).
Fördert TDD ein einfacheres Design?
Boby George und Laurie Williams, beide am Department of Computer Science der North Carolina State University tätig, führten ein Experiment durch, bei dem 24 Programmierer in zwei Gruppen aufgeteilt wurden: Eine nutzte TDD und die andere einen linearen Ansatz.
George und Williams berichten, dass von den Teilnehmern „92 % der Entwickler glaubten, dass TDD zu hochwertigerem Code führt, 79 % waren der Ansicht, dass TDD ein einfacheres Design fördert, und 71 % hielten den Ansatz für deutlich effektiv“ (Quelle).
Diese Statistiken zur testgetriebenen Entwicklung bezüglich der Qualität deuten stark darauf hin, dass TDD tatsächlich zu hochwertigerem Code und einem einfacheren Design führt.
In einem Artikel, der vom kostenlosen Lernportal Guru99.com veröffentlicht wurde, schreibt Kanchan Kulkarni: „TDD macht den Code einfacher und übersichtlicher. Es ermöglicht dem Entwickler, weniger Dokumentation zu pflegen“ (Quelle).
Ist es einfach, das TDD-Design zu übernehmen?
Aus dem Experiment von George und Williams glaubten 56 % der professionellen Entwickler, dass es schwierig sei, sich auf eine TDD-Denkweise einzulassen, während 23 % angaben, dass das Fehlen einer initialen Designphase Grund für diese Schwierigkeit sei. Insgesamt hielten 40 % die Einführung von TDD für schwierig (Quelle).
Diese Statistiken zur Einführung von testgetriebener Entwicklung zeigen, dass TDD als schwierig einzuführen angesehen wird.
Ist TDD überbewertet?
In einem auf Medium.com veröffentlichten Artikel verwendet Tylor Borgeson, der sich selbst als Full Stack Softwareentwickler mit Interesse an Machine Learning, KI, Infrastruktur, DevOps und Agile bezeichnet, die Überschrift „Testgetriebene Entwicklung ist überbewertet“. Dass er die Überschrift jedoch in Anführungszeichen setzt, zeigt, dass es keine Aussage von ihm selbst ist.
Anschließend richtet sich Borgeson an diejenigen, die die Methode als überbewertet und langsam bezeichnen, und sagt ihnen, dass die meisten, die diese Meinung vertreten, die Methode nicht lange genug genutzt haben. Am Ende seines Artikels schreibt er: „Jetzt üben Sie testgetriebene Entwicklung, bis es nicht mehr weh tut“ (Quelle).
Wie geht's weiter?
Lernen Sie QA-Ansätze von Experten im The QA Lead Podcast
Melden Sie sich für den The QA Lead Newsletter an, um unsere neuesten How-to-Anleitungen und Podcast-Episoden zu erhalten
Setzen Sie sich auf die Warteliste für das The QA Lead Online-Community-Forum, in dem Sie Best Practices mit anderen QA- und Softwaretest-Fachleuten austauschen können.
Hoffentlich sehen wir uns dort!
