Die Nutzung von agilen Methoden ist kein uneingeschr\u00e4nkter Garant f\u00fcr bessere Software. Der Grund daf\u00fcr ist, dass viele der klassischen Verfahrensweisen zur Qualit\u00e4tssicherung im agilen Kontext vor einer Bew\u00e4hrungsprobe stehen. Denn wie soll in einem System mit h\u00e4ufigen \u00c4nderungen auf Dauer sichergestellt werden, dass die bereits als funktionst\u00fcchtig geltenden Bestandteile nicht durch zuk\u00fcnftige Nachbesserungen wieder in einen undefinierten Zustand verfallen?<\/p>\n\n\n\n
W\u00e4hrend das Wasserfallmodell den Test erst zu Projektende vorsieht und auch im vielfach eingesetzten V-Modell (siehe Abbildung 1) eine zeitlich klar definierte Abfolge vorliegt, ist es im agilen Umfeld unabdingbar, dass Tests aufgrund der H\u00e4ufigkeit in der sie ausgef\u00fchrt werden, tunlichst immer unter den exakt gleichen Bedingungen und mit m\u00f6glichst geringem Aufwand durchgef\u00fchrt werden k\u00f6nnen. Dar\u00fcber hinaus sollten sie nach M\u00f6glichkeit zeitnahe zur Umsetzung der zu testenden Funktionalit\u00e4t bereit stehen. Denn nur so kann gew\u00e4hrleistet werden, dass sie mit dem steten Wandel schritthalten.<\/p>\n\n\n\nAbbildung 1: Das V-Modell und die testgetriebene Entwicklung<\/em><\/figcaption><\/figure>\n\n\n\n
<\/div>\n\n\n\n
Test Driven Development<\/strong><\/h2>\n\n\n\n
Das gr\u00f6\u00dfte Problem des klassischen Testens ist in diesem Zusammenhang also, dass es in aller Regel nachgelagert geschieht. Es wird erst dann ausgef\u00fchrt, wenn es auch etwas zu testen gibt. Dies scheint auf den ersten Blick trivial, denn soll etwas getestet werden ist vermeintlich auch ein entsprechender Testgegenstand von N\u00f6ten.<\/p>\n\n\n\n
Zwar k\u00f6nnen die Testf\u00e4lle und ihre Daten aus der Spezifikation abgeleitet werden, ohne eigentlichen Testgegenstand gibt es bei der Ausf\u00fchrung aber scheinbar kein auswertbares Ergebnis. Genau dieses Dogma gilt f\u00fcr automatisierte Tests nicht. W\u00e4hrend die st\u00e4ndige manuelle Ausf\u00fchrung auf Dauer unbezahlbar w\u00fcrde, k\u00f6nnen automatisierte Tests getrost auch kurz vor der eigentlichen Implementierung verfasst, sowie ausgef\u00fchrt werden und pr\u00fcfen dann vorr\u00fcbergehend nur eine H\u00fclle des sp\u00e4teren Testgegenstandes. Eine H\u00fclle wie sie beispielsweise von einer Schnittstellenbeschreibung vorgegeben ist.<\/p>\n\n\n\n
In diesem Fall stellt der Test eine Art automatisierter Spezifikation dar, der Anforderungen zun\u00e4chst nicht erf\u00fcllt werden (roter Beriech in Abbildung 2). Der Entwickler kann w\u00e4hrend der Implementierungsphase seinen Code gegen diese pr\u00fcfen und erh\u00e4lt damit sofort ein Feedback ob seine Arbeit den Anforderungen entspricht. Ist dieser Status erreicht (gr\u00fcner Bereich), hat er einen gesicherten Zustand des Quellcodes und kann jenen umstrukturieren (gelber Bereich). Bei neuen Anforderungen oder tiefgreifenden \u00c4nderungen schlagen die Tests erneut fehl (erneut roter Bereich) und m\u00fcssen zun\u00e4chst wieder korrekt erf\u00fcllt werden (erneut gr\u00fcner Bereich).<\/p>\n\n\n\n
Aus dieser einfachen Handlungsreihenfolge ergeben sich feingranulare Strukturen. Diese f\u00fchren zu einer sehr hohen Testabdeckung, mit welcher Fehler fr\u00fchzeitig gefunden und deren Behebung vereinfacht wird. Dar\u00fcber hinaus werden Schnittstellen und deren Implementierung robuster als bei klassischen Verfahren definiert. Dies erlaubt erst die hohe Anpassungsf\u00e4higkeit des Quellcodes, welche f\u00fcr agile Softwareprojekte so essentiell wichtig ist.<\/p>\n\n\n\nAbbildung 2: Der Ablauf der testgetriebenen Arbeitsweise<\/em><\/figcaption><\/figure>\n\n\n\n
<\/div>\n\n\n\n
Als eine der wichtigsten Eigenschaften von automatisierten Tests gilt dar\u00fcber hinaus deren Lesbarkeit. Denn sie k\u00f6nnen im Grunde nicht nur als Pr\u00fcfung der Funktionalit\u00e4t, sondern auch als eine Art Dokumentation der selbigen verstanden werden. Durch ihre N\u00e4he zur Funktionalit\u00e4t die sie pr\u00fcfen und ihrem klar strukturierten Aufbau, schildern sie das Verhalten des zu testenden Codes auf eine Weise wie es normal geschriebener Text nicht k\u00f6nnte. Da ihr eigenes Ergebnis \u00fcberdies vollkommen abh\u00e4ngig vom Testgegenstand ist, teilen sie dem Betrachter automatisch mit wenn sie nicht mehr aktuell sind.<\/p>\n\n\n\n
Diese Lesbarkeit erstreckt sich bei Komponententests jedoch einzig auf den Personenkreis der auch die entsprechende Programmiersprache versteht und das verwendete Testframework kennt. Dom\u00e4nenfremde Personen wie zum Beispiel Testmanager, Projektleiter oder sogar Endanwender k\u00f6nnen der feinen Granularit\u00e4t und Detailgenauigkeit nur wenig abgewinnen.<\/p>\n\n\n\n
Eine zweite Unzul\u00e4nglichkeit wird bei der Betrachtung des gesamten Entwicklungsprozesses offenbar. Mit TDD verfasste Tests sind hervorragend geeignet um Teile der Software anhand ihrer Spezifikation zu verifizieren, nicht aber um sie gegen die Akzeptanzkriterien zu validieren. Gerade diese sind es aber die befriedigt werden wollen und somit bei einer \u00dcberpr\u00fcfung noch vor der Implementierung kommen sollten.<\/p>\n\n\n\n
Aus diesen Gr\u00fcnden ist aus dem bekannten Test Driven Development das sogenannte Behavior Driven Development oder auch Acceptance Test Driven hervor gegangen. Bei diesem verschmelzen Tests und Spezifikation dank der Nutzung bestimmter Werkzeuge und Schl\u00fcsselworte so miteinander, dass die Testergebnisse in klarsprachlicher Weise ausgewertet werden k\u00f6nnen. Dazu wird insgesamt von der Beschreibung einzelner Funktionalit\u00e4ten weg und zur Schilderung eines erwarteten Verhaltens (Behavior) hin gegangen. Auf diese Weise bedarf die Definition der einzelnen Testf\u00e4lle keines Hintergrundwissens mehr zur Architektur des Programms, wodurch sie auch von Nichtentwicklern nachvollzogen werden kann und f\u00fchrt sogar soweit, dass h\u00e4ufig nicht einmal mehr von Testf\u00e4llen sondern von Spezifikationen gesprochen wird.<\/p>\n\n\n\n
Behaviour Driven Develoment kann nicht als eine Konkurrenz zum Test Driven Development verstanden werden. Denn ersteres dient vor allem der Validierung der Software sowie der Pr\u00fcfung der Systemintegration, w\u00e4hrend letzteres der Verifikation und damit der Sicherung von funktionaler Korrektheit dient. Demnach ist es durchaus sinnvoll beides in Kombination zu verwenden.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Aufwand<\/strong><\/h2>\n\n\n\n
Durch die Besonderheit, dass neben der eigentlichen Produktentwicklung von Entwicklern auch das Schreiben der Tests erwartet wird, f\u00fchrt die testgetriebene Entwicklung zun\u00e4chst zu einem h\u00f6heren Aufwand, als dies bei klassischen Verfahren \u00fcblich ist. So muss eine entsprechende Infrastruktur geschaffen, weitere Werkzeuge erlernt und zus\u00e4tzlicher Code geschrieben werden, der nicht sofort in nutzbaren Features m\u00fcndet. Dies mag zun\u00e4chst abschrecken, zeigt aber im Grunde nur den Aufwand, der andernfalls viel sp\u00e4ter im Projekt anf\u00e4llt. Statt der Aufw\u00e4nde f\u00fcr lange Test- und Bugfixingphasen gegen Ende des Projekts, wird ein Gro\u00dfteil der Qualit\u00e4tssicherung bereits zu einem Zeitpunkt vorbereitet, indem ein Projektteam durchaus noch komfortabel handeln kann. Dieser Aufwand wiederum sinkt mit zunehmendem Projektverlauf, da die Infrastruktur h\u00e4ufig nur einmal grundlegen erstellt und anschlie\u00dfend nur noch punktuell angepasst werden muss.<\/p>\n\n\n\nAbbildung 3: Ab wann lohnt sich TDD?<\/em><\/figcaption><\/figure>\n\n\n\n
<\/div>\n\n\n\n
Fazit<\/strong><\/h2>\n\n\n\n
Der Einsatz der in diesem Artikel vorgestellten Methoden stellt teilweise einen erheblichen Bruch mit den klassischen Vorgehensweisen in der Softwareentwicklung dar, erm\u00f6glicht jedoch eine Qualit\u00e4tssicherung und Dokumentation wie sie sonst nur schwer m\u00f6glich ist. So verr\u00e4t die Software im Grunde selbst ihren aktuellen Ist-Stand ohne dass externe Ressourcen gepflegt werden m\u00fcssen, die unter Umst\u00e4nden schnell veralten. Durch die Kombination der unterschiedlichen Ans\u00e4tze kann dabei die Qualit\u00e4t und ein umfassendes Projektverst\u00e4ndnis \u00fcber alle Abstraktionsebenen hinweg sichergestellt werden.<\/p>\n","protected":false},"excerpt":{"rendered":"
Klassisches Testen wird oft erst dann ausgef\u00fchrt, wenn es etwas zu testen gibt. Welchen Nutzen bringt dabei der Ansatz der TDD f\u00fcr agile Projekte?<\/p>\n","protected":false},"author":12,"featured_media":1683,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"advgb_blocks_editor_width":"","advgb_blocks_columns_visual_guide":"","footnotes":""},"categories":[16,10,15],"tags":[26,30,165,166,444,445,23,24],"topics":[],"class_list":["post-1039","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dot-net","category-qualitaetssicherung","category-java","tag-agile","tag-qualitaetssicherung","tag-tdd","tag-test-driven-development","tag-behaviour-driven-development","tag-agile-methoden","tag-quality-assurance","tag-testservices"],"acf":[],"yoast_head":"\n
Test Driven Development - ZEISS Digital Innovation Blog<\/title>\n<meta name=\"description\" content=\"Klassisches Testen wird oft erst dann ausgef\u00fchrt, wenn es etwas zu testen gibt. Welchen Nutzen bringt hier der TDD-Ansatz f\u00fcr agile Projekte?\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/test-driven-development\/\" \/>\n<meta property=\"og:locale\" content=\"de_DE\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Test Driven Development - ZEISS Digital Innovation Blog\" \/>\n<meta property=\"og:description\" content=\"Klassisches Testen wird oft erst dann ausgef\u00fchrt, wenn es etwas zu testen gibt. Welchen Nutzen bringt hier der TDD-Ansatz f\u00fcr agile Projekte?\" \/>\n<meta property=\"og:url\" content=\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/test-driven-development\/\" \/>\n<meta property=\"og:site_name\" content=\"Digital Innovation Blog\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/ZEISSDigitalInnovation\/\" \/>\n<meta property=\"article:published_time\" content=\"2015-04-16T11:50:05+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2020-09-21T13:40:13+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2015\/04\/201504_Test_Driven_Development_2_neu_fi.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1758\" \/>\n\t<meta property=\"og:image:height\" content=\"1004\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Hendrik L\u00f6sch\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@ZEISS_di\" \/>\n<meta name=\"twitter:site\" content=\"@ZEISS_di\" \/>\n<meta name=\"twitter:label1\" content=\"Verfasst von\" \/>\n\t<meta name=\"twitter:data1\" content=\"Hendrik L\u00f6sch\" \/>\n\t<meta name=\"twitter:label2\" content=\"Gesch\u00e4tzte Lesezeit\" \/>\n\t<meta name=\"twitter:data2\" content=\"5\u00a0Minuten\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/test-driven-development\/\",\"url\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/test-driven-development\/\",\"name\":\"Test Driven Development - ZEISS Digital Innovation Blog\",\"isPartOf\":{\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/test-driven-development\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/test-driven-development\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2015\/04\/201504_Test_Driven_Development_2_neu_fi.png\",\"datePublished\":\"2015-04-16T11:50:05+00:00\",\"dateModified\":\"2020-09-21T13:40:13+00:00\",\"author\":{\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/#\/schema\/person\/6e05d04f9ce6136e393a6ede03660e32\"},\"description\":\"Klassisches Testen wird oft erst dann ausgef\u00fchrt, wenn es etwas zu testen gibt. Welchen Nutzen bringt hier der TDD-Ansatz f\u00fcr agile Projekte?\",\"breadcrumb\":{\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/test-driven-development\/#breadcrumb\"},\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/test-driven-development\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/test-driven-development\/#primaryimage\",\"url\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2015\/04\/201504_Test_Driven_Development_2_neu_fi.png\",\"contentUrl\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2015\/04\/201504_Test_Driven_Development_2_neu_fi.png\",\"width\":1758,\"height\":1004},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/test-driven-development\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Test Driven Development\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/#website\",\"url\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/\",\"name\":\"Digital Innovation Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"de\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/#\/schema\/person\/6e05d04f9ce6136e393a6ede03660e32\",\"name\":\"Hendrik L\u00f6sch\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2024\/06\/Profilbild_Hendrik_Loesch_300x300px-150x150.jpg\",\"contentUrl\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2024\/06\/Profilbild_Hendrik_Loesch_300x300px-150x150.jpg\",\"caption\":\"Hendrik L\u00f6sch\"},\"description\":\"Hendrik L\u00f6sch ist Consultant und Architekt der ZEISS Digital Innovation. Der Schwerpunkt seiner Arbeit liegt auf der Entwicklung und Bewertung von Software auf Basis von Microsofttechnologien. Dar\u00fcber hinaus schreibt und spricht er gern \u00fcber seine Arbeit sowie seine Begeisterung f\u00fcr Clean Code, Softwareevolution und die Testautomatisierung in ihren unterschiedlichen Auspr\u00e4gungen.\",\"url\":\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/author\/hendrikloesch\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Test Driven Development - ZEISS Digital Innovation Blog","description":"Klassisches Testen wird oft erst dann ausgef\u00fchrt, wenn es etwas zu testen gibt. Welchen Nutzen bringt hier der TDD-Ansatz f\u00fcr agile Projekte?","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/test-driven-development\/","og_locale":"de_DE","og_type":"article","og_title":"Test Driven Development - ZEISS Digital Innovation Blog","og_description":"Klassisches Testen wird oft erst dann ausgef\u00fchrt, wenn es etwas zu testen gibt. Welchen Nutzen bringt hier der TDD-Ansatz f\u00fcr agile Projekte?","og_url":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/test-driven-development\/","og_site_name":"Digital Innovation Blog","article_publisher":"https:\/\/www.facebook.com\/ZEISSDigitalInnovation\/","article_published_time":"2015-04-16T11:50:05+00:00","article_modified_time":"2020-09-21T13:40:13+00:00","og_image":[{"width":1758,"height":1004,"url":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2015\/04\/201504_Test_Driven_Development_2_neu_fi.png","type":"image\/png"}],"author":"Hendrik L\u00f6sch","twitter_card":"summary_large_image","twitter_creator":"@ZEISS_di","twitter_site":"@ZEISS_di","twitter_misc":{"Verfasst von":"Hendrik L\u00f6sch","Gesch\u00e4tzte Lesezeit":"5\u00a0Minuten"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/test-driven-development\/","url":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/test-driven-development\/","name":"Test Driven Development - ZEISS Digital Innovation Blog","isPartOf":{"@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/#website"},"primaryImageOfPage":{"@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/test-driven-development\/#primaryimage"},"image":{"@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/test-driven-development\/#primaryimage"},"thumbnailUrl":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2015\/04\/201504_Test_Driven_Development_2_neu_fi.png","datePublished":"2015-04-16T11:50:05+00:00","dateModified":"2020-09-21T13:40:13+00:00","author":{"@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/#\/schema\/person\/6e05d04f9ce6136e393a6ede03660e32"},"description":"Klassisches Testen wird oft erst dann ausgef\u00fchrt, wenn es etwas zu testen gibt. Welchen Nutzen bringt hier der TDD-Ansatz f\u00fcr agile Projekte?","breadcrumb":{"@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/test-driven-development\/#breadcrumb"},"inLanguage":"de","potentialAction":[{"@type":"ReadAction","target":["https:\/\/blogs.zeiss.com\/digital-innovation\/de\/test-driven-development\/"]}]},{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/test-driven-development\/#primaryimage","url":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2015\/04\/201504_Test_Driven_Development_2_neu_fi.png","contentUrl":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2015\/04\/201504_Test_Driven_Development_2_neu_fi.png","width":1758,"height":1004},{"@type":"BreadcrumbList","@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/test-driven-development\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/"},{"@type":"ListItem","position":2,"name":"Test Driven Development"}]},{"@type":"WebSite","@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/#website","url":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/","name":"Digital Innovation Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"de"},{"@type":"Person","@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/#\/schema\/person\/6e05d04f9ce6136e393a6ede03660e32","name":"Hendrik L\u00f6sch","image":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/#\/schema\/person\/image\/","url":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2024\/06\/Profilbild_Hendrik_Loesch_300x300px-150x150.jpg","contentUrl":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2024\/06\/Profilbild_Hendrik_Loesch_300x300px-150x150.jpg","caption":"Hendrik L\u00f6sch"},"description":"Hendrik L\u00f6sch ist Consultant und Architekt der ZEISS Digital Innovation. Der Schwerpunkt seiner Arbeit liegt auf der Entwicklung und Bewertung von Software auf Basis von Microsofttechnologien. Dar\u00fcber hinaus schreibt und spricht er gern \u00fcber seine Arbeit sowie seine Begeisterung f\u00fcr Clean Code, Softwareevolution und die Testautomatisierung in ihren unterschiedlichen Auspr\u00e4gungen.","url":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/author\/hendrikloesch\/"}]}},"author_meta":{"display_name":"Hendrik L\u00f6sch","author_link":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/author\/hendrikloesch\/"},"featured_img":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2015\/04\/201504_Test_Driven_Development_2_neu_fi-600x343.png","coauthors":[],"tax_additional":{"categories":{"linked":["<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/category\/dot-net\/\" class=\"advgb-post-tax-term\">.NET<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/category\/qualitaetssicherung\/\" class=\"advgb-post-tax-term\">Qualit\u00e4tssicherung<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/category\/java\/\" class=\"advgb-post-tax-term\">Java<\/a>"],"unlinked":["<span class=\"advgb-post-tax-term\">.NET<\/span>","<span class=\"advgb-post-tax-term\">Qualit\u00e4tssicherung<\/span>","<span class=\"advgb-post-tax-term\">Java<\/span>"]},"tags":{"linked":["<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/category\/java\/\" class=\"advgb-post-tax-term\">agile<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/category\/java\/\" class=\"advgb-post-tax-term\">Qualit\u00e4tssicherung<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/category\/java\/\" class=\"advgb-post-tax-term\">TDD<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/category\/java\/\" class=\"advgb-post-tax-term\">Test Driven Development<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/category\/java\/\" class=\"advgb-post-tax-term\">Behaviour Driven Development<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/category\/java\/\" class=\"advgb-post-tax-term\">agile Methoden<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/category\/java\/\" class=\"advgb-post-tax-term\">quality assurance<\/a>","<a href=\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/category\/java\/\" class=\"advgb-post-tax-term\">testservices<\/a>"],"unlinked":["<span class=\"advgb-post-tax-term\">agile<\/span>","<span class=\"advgb-post-tax-term\">Qualit\u00e4tssicherung<\/span>","<span class=\"advgb-post-tax-term\">TDD<\/span>","<span class=\"advgb-post-tax-term\">Test Driven Development<\/span>","<span class=\"advgb-post-tax-term\">Behaviour Driven Development<\/span>","<span class=\"advgb-post-tax-term\">agile Methoden<\/span>","<span class=\"advgb-post-tax-term\">quality assurance<\/span>","<span class=\"advgb-post-tax-term\">testservices<\/span>"]}},"comment_count":"0","relative_dates":{"created":"Posted 11\u00a0Jahren ago","modified":"Updated 6\u00a0Jahren ago"},"absolute_dates":{"created":"Posted on April 16, 2015","modified":"Updated on September 21, 2020"},"absolute_dates_time":{"created":"Posted on April 16, 2015 11:50 a.m.","modified":"Updated on September 21, 2020 1:40 p.m."},"featured_img_caption":"","series_order":"","_links":{"self":[{"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-json\/wp\/v2\/posts\/1039","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-json\/wp\/v2\/users\/12"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-json\/wp\/v2\/comments?post=1039"}],"version-history":[{"count":13,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-json\/wp\/v2\/posts\/1039\/revisions"}],"predecessor-version":[{"id":1688,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-json\/wp\/v2\/posts\/1039\/revisions\/1688"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-json\/wp\/v2\/media\/1683"}],"wp:attachment":[{"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-json\/wp\/v2\/media?parent=1039"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-json\/wp\/v2\/categories?post=1039"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-json\/wp\/v2\/tags?post=1039"},{"taxonomy":"topics","embeddable":true,"href":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-json\/wp\/v2\/topics?post=1039"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"Das](\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2020\/08\/201504_Test_Driven_Development_1_neu-600x323.png\")
![\"Der](\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2020\/08\/201504_Test_Driven_Development_2_neu-600x412.png\")
![\"Ab](\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2020\/08\/201504_Test_Driven_Development_3_neu-600x406.png\")