Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Ritschi und hatte jetzt bei mir zu Gast Ronald Brill. Mit ihm habe ich mal auf das Thema der Testpyramide geschaut. Wir kennen sie doch alle aus diverser Literatur, ich verwende sie auch immer wieder. Dieses hübsche Bildchen, unten viele Unitests, oben wenige GUI-Tests und dann ist die Welt ganz heile. Aber ist sie das auch? Passt sie denn
immer? Ronald hat einen sehr kritischen Blick drauf, den er mit uns in dieser Folge teilt. Also viel Spaß beim Reinhören. Hallo Ronald, schön, dass du da bist. Ja, hallo, ich freue mich auch. Ja, du warst ja ein heißer Empfehlungskandidat für den Podcast und wurde mir quasi zugespielt
von einer gemeinsamen Bekannten, um es mal so zu sagen. Und dann habe ich mir ein Video von dir, auch angesehen, einen Vortrag und es fand ich mega spannend, nämlich das Thema, das wir immer so beiläufig in jedem Testkonzept irgendwo finden, nämlich so das Thema Testpyramide. Und dass du da so gar nicht so happy bist mit der, wie wir sie so immer nutzen, oder?
Ja, es ist schon, also ich tue mich, je länger ich diesen Job mache und ich mache das jetzt seit über 30 Jahren irgendwie, tue ich mich immer schwerer mit diesen pauschalen Dingen. Und die Testpyramide ist so was, ich war letztens wieder auf einem Vortrag, wo dann am Schluss wieder so der Abspann ist, ja und über allem schwebt aber die Testpyramide, ja. Also alles, was wir uns jetzt hier so überlegt haben, funktioniert nur im Kontext von der Testpyramide.
Und ich glaube, wir machen uns das oft, ja die Testpyramide hat so ein paar ganz lustige Eigenschaften, also sie ist, man sagt Testpyramide, man kann auch das Bild zeigen und alle wissen eigentlich, was gemeint ist. Jeder hat eine Idee, was er machen muss und jeder findet sich da drin wieder, aber so richtig genau, worum es da geht oder so, habe ich so das
Gefühl, ist den meisten überhaupt nicht klar. Und ob die Testpyramide noch zu dem passt, was wir so aktuell machen, also sprich, sagen wir mal, Microservice-Landschaften, sagen wir mal, agile Vorgehensweisen, DevOps und Konsorten, ist zumindest bedenkenswert, denke ich. Ja, da sind wir ja schon mittendrin in dem
Thema. Ja, sorry. Also, ich sag mal, das klassische Bild ist ja diese Pyramide und unten so ein bisschen Unitest, ein bisschen irgendwo Schnittstelle-Integration, oben so ein bisschen GUI-gezeugs, das findet man in einigen Abwandlungen. Du meinst, das passt nicht immer oder das passt vielleicht doch gar nicht mehr. Na ja, ich würde, glaube ich, gerne noch einen Schritt vorher anfangen. Also, wo kommt das eigentlich her? Also, ich bin so jemand,
der sich ein bisschen dafür interessiert, was ist die Motivation von den Dingen? Einfach deshalb, weil ich für das, was ich tue, eigentlich gerne immer einen Grund habe, einen Warum. Und warum ist es sinnvoll, die Testpyramide vielleicht in dem Kontext anzuwenden? Was ist so die Motivation dahinter und so? Und für mich gibt es eigentlich zwei Dinge, die ich an der Testpyramide wichtig finde. Es geht weniger darum, dass es eine Pyramide
ist. Es geht weniger darum, dass es ganz viel Unitest geben muss und möglichst wenig UI-Test, sondern es geht eher darum, und die Pyramide gibt es ja noch gar nicht so lange, überraschenderweise, wie ich fand. Also, die Pyramide. Die anderen gibt es natürlich schon viel länger. Es geht mehr darum, dass man ein ganz konkretes Problem hatte. Das Problem ist einfach, dass man mit dem Testen nicht hinterherkam, also, dass man große Applikationen nicht vernünftig
testen konnte. Und für mich der spannende Ansatz, der gewählt wurde für die Pyramide, ist eigentlich, dass man hingeht und sagt, Testen ist nicht was Separates, Testen ist nicht etwas, was ich am Schluss auf das Ganze drauf setze, Testen ist nichts, was auch von einem separaten Team gemacht wird, was sich das dann anguckt, sondern wir kommen nur dann zu effizienteren Tests, wenn wir vielleicht die Dinge, die die Entwickler schon entworfen
haben, ein Stück weit mitnutzen. Und das ist für mich einer der Kerne der Testpyramide. Die Unitests sind Tests, die Artefakte benutzen, die die Entwickler schon benutzen. Und weil sie das tun und weil sie das auf einem anderen Level tun als ein Blackbox-Test, werden diese Tests effizienter. Das heißt, ich kann mit weniger Aufwand vielleicht ein ähnlich gutes
Ergebnis erzielen. Ja, das ist so, glaube ich, die eine Idee, die dahinter steckt. Und die zweite Idee, und das vergisst man, glaube ich, auch ziemlich oft, ist, dass diese Tests aufeinander aufbauen. Das ist eigentlich das, was die Pyramide sagen möchte. Ich habe mehrere Schichten und diese Schichten bauen aufeinander auf, so wie die Schichten von der echten Pyramide. Es geht also weniger um die Form, sondern es geht darum, dass die Sachen aufeinander
aufbauen und sich gegenseitig ergänzen. Es hilft mir überhaupt nichts, wenn ich auf der oberen Ebene Tests durchführe, die ich unten schon mal gemacht habe. Und umgekehrt. Es ist natürlich auch völliger Quatsch, Sachen unten wegzulassen und dann oben an der Spitze diese Tests durchzuführen. Das wissen wir. Das wusste man schon vor der Pyramide. Das ist sehr effizient in vielen Fällen. Und das hat wenig für mich mit der Pyramide an
sich zu tun, sondern das ist eher so, wie die Idee dahinter steckt. Und wenn man dann hingeht und diese Ideen auf sein Projekt transformiert, dann kommt man dahin, wo inzwischen eine ganze Reihe von Leuten unterwegs sind, wenn man sich ein bisschen umguckt, wo dann plötzlich die Formen ganz anders aussehen, wo es eigentlich nicht mehr eine Pyramide ist, sondern wo die Schichten aus guten Gründen projektspezifisch angepasst wurden. Wo man sich überlegt, ob
man vielleicht mehr Integrationstests machen muss. Vielleicht ist man sogar wieder dabei, dass man sagt, okay, ich mache einfach nur Blackbox-Tests. Das könnte sinnvoll sein. Das ist so das, was für mich hinter dieser Pyramide steckt. Eigentlich ist es eine Testidee. Ja, genau. Also Pyramide sind ja dann auch nicht Männer, wenn sie das Ding verändern. Genau. Die tun sich auch ganz schwer lustige Namen für die Sachen. Also gar nicht so schwer
lustige Namen. Also es gibt dann irgendwie Testpokale, Test-Honeypots, weiß der Kuckuck. So einen Tannenbaum habe ich mal gesehen. Das waren zwei Pyramiden übereinander. Ja, das kann man vielleicht auch machen. Da muss man mal überlegen, was das dann für ein Ansatz ist. Es gibt auch so ein Hauerglas, also so ein Stundenglas als Antipattern zum Teil, wo man dann sagt, man hat oben ganz viele Tests, man hat unten ganz viele Tests,
aber dazwischen ist nichts. Könnte, ja, vielleicht gibt es auch einen guten Grund dafür, das so zu machen. Ja. Kannst du uns da mal noch vielleicht ein paar konkrete Beispiele nehmen, wo du sagst, genau da wäre jetzt eigentlich die Pyramide nicht angebracht, vielleicht architektonisch gesehen oder hast du irgendein Beispiel? Na ja, also man kann es ja ganz simpel anfangen. Also es gibt mehrere Dimensionen in meiner
Sicht auf die Welt. Also ich glaube, das, was wir alles im Moment machen in Richtung von Services und sowas, das hat ganz viel, was zumindest in diese Richtung zeigt. Dass es vielleicht nicht so sinnvoll ist, unglaublich viele Unitests zu haben oder vielmehr, dass man ein klares Verständnis braucht, wer welche Unitests macht. Und viele von den Tests, die wir gerade beim Entwickeln von Services machen, sind, glaube ich, weniger Unitests als tatsächlich
schon Integrationstests. Also wenn du so über so einen typischen Rest-Service nachdenkst oder sowas und die Tests gegen die Rest-API schreibst oder von mir aus noch auf einem Mock-Layer, aber gegen den eigentlichen Controller oder gegen die Service-Schichten darunter, dann sind das ja eigentlich nicht Unitests, sondern wir verwenden eigentlich nur ein Unitest-Framework, um diese Integrationstests zu schreiben. Der entscheidende Punkt für mich ist eigentlich
genau dieser Übergang. Also wenn ich einen Integrationstest schreibe, also wann schreibe ich einen Integrationstest, wann schreibe ich einen Unitest? Und dann einfach zu gucken, dass ich mich nicht doppele. Also dass ich nicht dasselbe, dieselbe Anforderung zweimal
abteste. Und je, sage ich mal, leichtgewichtiger unsere Services werden, umso weniger und je mächtiger die Frameworks sind, die ich unter den Unitests verwende, die dann wieder Unit getestet sind, ich glaube, umso weniger Dinge gibt es, die man eigentlich noch Unitesten
kann, wo sinnvoll was passiert. Man kann natürlich immer Unitests schreiben. Die Frage ist, irgendwann – da sind, glaube ich, inzwischen eine ganze Reihe von Leuten vorbeigekommen, wo man sich fragt, welchen – also ich habe ganz viele Unitests, vielleicht ist sogar meine Testabdeckung gut und trotzdem sind Fehler in der Software. Und wenn man sich's anguckt, eigentlich habe ich mit dem Unitest den Fehler auch gar nicht finden können, weil der ja nicht in der konkreten
Unit ist, sondern in dem Zusammenspiel der einzelnen Teile. Und wenn man dann überlegt, dass sich in so einer Microservice-Landschaft das Zusammenspiel jetzt nicht mal mehr innerhalb meines Services, meines Moduls oder so abspielt, sondern zwischen den Services, dann wird das noch mal kniffliger, um sich da Gedanken zu machen. Also insofern denke ich, dass gerade diese Dinge dazu führen, dass es nicht so fürchterlich sinnvoll ist, so viele Unitests
zu haben, wenn man denn nicht so viele Units hat. Es kommt halt immer darauf an. Klar kann ich mir für einige Sachen Dinge überlegen, die da einiges bewegen, aber am Schluss des Tages sollte, glaube ich, der Anspruch sein, dass man die Software aus der Außensicht entsprechend testet. Und der Unitest muss dazu einen Beitrag leisten. Es gibt andere
Stellen, wo man, glaube ich, auch recht gut drauf gestoßen wird. Also ich hatte selber vor, das ist schon ziemlich lange her, so in dieser Anfangszeit, wo man so euphorisch denkt, boah, jetzt noch ein Unitest. Die jungen Leute haben das ja häufiger. Ja, ich muss noch mehr Unitests schreiben und Testabdeckung hoch und so was. Und dann kommt eine Anforderung
und dann muss man das System refactoren. Und dann ist man plötzlich an der Stelle, wo man denkt, das dauert jetzt als Refactoring deutlich länger, weil ich die ganzen Unitests mitziehen muss. Das heißt, ich habe eigentlich für meine Software eine falsche Abstraktion, also übertrieben. Deshalb muss ich refactoren. Irgendwas stimmt da nicht. Und da ich jetzt auch noch Unitests habe, stimmt es natürlich für diese Unitests, weil die auf derselben
Abstraktion sind, auch nicht. Gerade das, was wir als Vorteil hatten eben, dass ich jetzt auf derselben Abstraktionsebene, auf der niedrigen Abstraktionsebene arbeiten kann beim Testen, fällt mir jetzt auf die Füße. Ich muss jetzt die Unitests mit refactoren.
Und das ist natürlich sicherlich auch eine Gratwanderung. Aber da merkt man schon, dass es vielleicht nicht immer sinnvoll ist oder sinnvoll im Sinne von effizient, kostengünstig, zielführend, wie auch immer du es nennen möchtest, zu viel in die Unitests zu schreiben. Und der zweite Aspekt ist, gerade bei den Microservices und bei, sagen wir mal, den
Schnittstellen, die wir im Moment haben, ist es auch deutlich einfacher. Also die Testpyramide kommt aus einer Zeit, wo wir, und ist eher für große UI-Applikationen gedacht, wo es echt ein Pain war, auch das UI-Blackbox zu testen. Alle großen UI-Frameworks, gerade die kleinen Frameworks, sind totaler Horror. Also ich selber arbeite im Moment in einem WPF-Projekt, das Blackbox zu testen, ist eine Katastrophe. Und da muss man sich auch fragen,
ob das wirklich Sinn macht am Schluss. Aber wenn ich einen Restservice habe, ist das natürlich viel einfacher, viel effizienter, auch sehr, sehr kostengünstig. Und wenn man sich Spring anguckt und so, die haben auch schon einiges vorgesehen, damit das Ding testbar ist. Und damit fällt dieses Argument, mach doch Unitests, weil sie günstiger sind. Eigentlich kehrt sich das um. Mach lieber einen Integrationstest, weil er ist vielleicht nicht ganz so günstig
wie ein Unitest, aber der Effekt ist viel größer. Du testest ein viel größeres Spektrum ab. Oder du testest nicht Dinge, die du gar nicht benutzt. Das ist ja das andere, was bei einem Unitest passiert. Diese ganzen Nullchecks, die du machst und Border Cases und so was. Wenn du eine relativ komplexe Software hast, dann werden Teile davon überhaupt nicht benutzt, weil die Nullchecks schon zwei Ebenen drüber passiert sind.
Ja, das finde ich super spannend, weil gerade in neueren Projekten, da ist ja immer die Frage, wo setze ich denn da an? Was ist denn da in Unitests und was ist ein Integrationstest? Also auch diese Begrifflichkeit mal auseinander zu definieren, auch im Projekt, was heißt das eigentlich für uns? Ich habe häufig auch so Kundenprojekte, da komme ich hin und sage, wir haben ganz viele Unitests. Das ist aber so ein klassisches Projekt mit schöner Oberfläche
und diesen Frameworks. Da sage ich, wir haben ganz viele Unitests, aber da ist da eigentlich alles da drinnen. Das ist halt nur alles irgendwie in JUnit umgesetzt, aber da sind Integrationstests vermischt mit Dings und da ist überhaupt nicht klar, was eigentlich das eine oder das andere machen soll. Ja, das ist leider auch ein bisschen schade, dass JUnit halt auch JUnit oder was auch immer NUnit heißt, weil wir ja ganz schnell gelernt
haben, dass sie auch andere testen. Also eigentlich ist es ja eine Testautomatisierung, eine ganz simple. Und da es jetzt Unitests heißt, hat man so eine Begriffsverwirrung und führt leider so ähnlich wie die Pyramide dazu, dass die Leute nicht darüber nachdenken, was sie da eigentlich tun. Ja, das ist halt ein bisschen schwierig. Andersrum ist es so, dass Unitests, finde ich, die haben auch so einen gewissen Suchtfaktor.
Gerade so, wenn man noch nicht so richtig sicher ist, was man so tut. Man kann sich so selber absichern. Man kann recht gut sagen, es gibt Metriken. Man kann gucken, habe ich alles gemacht? Man hat so das Gefühl, man hat Qualität gebaut. Man kann sich selbst versichern und man kann sich auch mal noch einen Test ausdenken und sich selber zeigen,
wie gut man ist, dass man auch da dran gedacht hat. Also die haben so ein bisschen auch etwas, das die Leute dazu bringt, dann zu sagen, okay, dann schreibe ich mal lieber noch einen Unitest oder ich gebe beim Kollegen an im nächsten Code Review. Ich habe ganz viele Unitests, die Testabdeckung ist schön, führt aber dazu, dass man sich eigentlich weniger mit der wirklichen
Aufgabe beschäftigt. Habe ich wirklich das Business verstanden? Habe ich wirklich den Prozess verstanden, den ich jetzt mit meiner Software, mit meinem Service, mit meinem UI unterstützen soll? Sondern ich beschäftige mich eher damit. Auch recht einfach.
Genau. Und das ist ja, wie du sagst, auch eine große Sucht. Ich glaube, das ist auch zum Teil getrieben von, sagen wir mal, Reporting-Möglichkeiten, weil, sagen wir mal, der Code Coverage, da kann man super leicht rausbringen und viele Projektleiter und Testmanager stehen dann halt einfach auch total drauf. Wir müssen jetzt 80 Prozent haben und dann habe ich lieber 80 Prozent Testabdeckung, aber die Unitests sind ja gar nicht Käse und Testen gar nichts Sinnvolles.
Ja, das böse Erwachen kommt dann irgendwo. Also es gibt ja dann zwei Möglichkeiten. Also eigentlich gibt es drei. Die eine ist selten, dass die Software einfach komplett funktioniert. Wenn dann was passiert, dann sind wir an der Stelle, wo kann man ja nur zwei Dinge sagen. Die eine ist, ich nehme sie als Entschuldigung. Ich sage, ich habe 80 Prozent Unitest. Dann sollte man schon noch mal nachdenken, ob diese 80 Prozent wirklich was aussagen. Das andere ist, man fragt sich halt,
warum habe ich dann den Bug trotzdem nicht gefunden? Und das ist so eine Stelle, wo ich ja eben schon war, wo ich mich dann gefragt habe, hätte ich den überhaupt mit einem Unitest, also eben im Echten nicht mit dem J-Unit, sondern im Unitest finden können. Und bei der Komplexität, die wir aktuell bauen, ist das glaube ich immer seltener der Fall. Und das ist für mich dann halt ein Grund, warum auch und das gerade im Microservice-Umfeld sind inzwischen viele der
Meinung, dass man eher mit diesen Integrationstests arbeitet. Ja, da sagst du auch noch was ganz Spannendes, weil diese Analyse, wenn das dann bricht, wenn die Software nicht läuft, wenn die Fehler auftreten, diese Analyse hätte, warum habe ich denn das nicht gefunden oder sowas? Das findet meiner Beobachtung nach immer viel zu wenig statt einfach. Das wird dann einfach so, ja, ist halt so und weiter geht's. Also dieses auch mal zu reflektieren und zu sagen, warum haben wir
eigentlich Fehler, wenn wir schon so viele tolle Testabdeckungen haben? Ja, das ist aber tatsächlich in einer gewissen Hinsicht noch eine dritte Dimension, die eigentlich auch in der Testpyramide drinsteckt. Ja, also diese, wenn du dir überlegst, diese Idee, dass man sagt, okay, ich verlasse mich
da drauf, dass in der Schicht darunter diese Tests günstiger gemacht werden. Ja, das heißt, als derjenige, der auf der Schicht darüber arbeitet, muss ich ja entweder diesen Anspruch formulieren und mit der Ebene darunter abstimmen, wenn es nicht eine Personalunion ist, sondern und das ist ja in größeren Teams der Fall, ja und ich muss also Regeln aufstellen, ich muss eine gewisse Kommunikation
haben, ich muss mich darum kümmern und ich muss ein gewisses Vertrauen entwickeln. Und wenn du das auf der Testpyramide durchgehst, hast du, ist das im Prinzip genau dasselbe Spiel, was du hast, wenn du jetzt zum Beispiel eine Schnittstelle testest. Ja, du testest Service und dieser Service selber
ruft wieder einen anderen Service auf. Ja, dieser, wenn du jetzt den Service testest, kannst du dich natürlich genauso fragen, wie muss ich jetzt diesen Fall, also diesen Sonderfall testen oder ist das durch einen Unit-Test abgedeckt, kannst du dich natürlich auch fragen, muss ich alle diese Fälle, die quasi Cases für den Service dahinter sind, muss ich die jetzt auch Blackbox testen oder schaffe ich es, diese Kette quasi aufzubauen und die aber auf der Basis von Regeln, Vertrauen
entsprechend zu behalten. Und das ist, glaube ich, da wir da dann meistens über verschiedene Teams, vielleicht sogar verschiedene Technologien, sicherlich verschiedene, sage ich mal, Hintergründe, ja, die Leute sind anders sozialisiert, wie auch immer man das nennen mag, ja, dann muss man sich da sicherlich eine ganze Menge an Zeit, vielleicht auch Arbeit geben, um da ein gemeinsames Verständnis zu entwickeln. Und je weiter du hinten bist in dieser Kette, umso mehr ist es, glaube ich,
schwierig zu erkennen, dass man eine gewisse Verantwortung hat. Also du hast das in der Testpyramide, nehmen wir an, du änderst einen Unit-Test, würde das ja prinzipiell bedeuten, dass derjenige, der die Integrationstests über dir schreibt, sich ja bisher darauf verlassen hat, dass du diesen Unit-Test hast. Ja, wenn du diesen Unit-Test änderst, wegnimmst, müsstest du dich
eigentlich mit ihm abstimmen, damit die Test-Suite aus seiner Sicht wieder vollständig ist. Dasselbe hast du in dieser Kette zwischen den Services, ja, wenn du da was änderst, dann änderst du im Prinzip den Vertrag, ja, diesen Vertrauensvertrag, dass du für diesen Teil der Qualitätsanforderungen zuständig bist, der andere für die anderen Teil und dass die Summe die Qualität gibt, die du dann ausliefern willst. Ja, und je mehr wir in diesen technischen Dingen unterwegs
sind, umso mehr wird das, glaube ich, ein bisschen verdrängt. Ja, also ich kann Metriken machen, die sagen aber darüber nichts aus. Die sagen nichts darüber aus, dass das Gesamtsystem genau auf diesen Dingen passiert. Oder ich falle halt wieder zurück, wenn das Vertrauen fehlt, ja, und teste wieder alles. Dann ist aber das, was sich die Leute bei der Pyramide überlegt haben, dann sind wir wieder genau am Anfang, wo wir irgendwie im Jahr 2000 waren. Wir haben wieder
eine Testeistüte. Wir gucken uns das Ganze an und, ja, testen Dinge mehrfach. Wir verschwenden vielleicht Zeit oder die Testsuite wird so groß oder so unhandlich, läuft so lange, dass man sie eigentlich nicht gebrauchen kann. Ja, sehr spannend. Was würdest du denn jetzt jemandem raten, der jetzt sagt, ja, pfuh, bei uns, pfuh, da müsste man mal drauf schauen. Wie kann man sich denn dem am ehesten nähern? Also ich glaube, es gibt keine Universalrezepte, aber das ist so eine persönliche
Einstellung von mir. Ich versuche, das Ganze eigentlich immer so ähnlich anzugehen, wie du das vorhin schon mal gesagt hast. Ja, also so ein bisschen einen Fehler machen ist menschlich, denselben Fehler noch mal machen ist dumm. Ja, also ich gehe immer ein Stück ins Risiko und würde sagen, das kann man auch machen. Man wird immer Fehler drin haben, man wird immer nicht vollständig ab Testabdeckung haben können. Aber ich denke, dass gerade sich so im Nachhinein Gedanken
zu machen, warum ist das jetzt eigentlich passiert? Man kann sich natürlich auch Gedanken machen, was müssen wir machen, um unsere Testsuite effizienter zu machen. Ja, aber vieles kann man an einem konkreten Beispiel besser machen, indem man sich das einfach anguckt, sagt, was haben wir hier falsch gemacht? Lasst uns mal zusammensetzen. Was können wir hier machen? Auch an einem konkreten Beispiel werden oft diese impliziten Annahmen, wo ich eben so über Sozialisation gesprochen habe
und sowas, deutlicher. Wo man plötzlich sagen muss, das ist doch völlig klar. Für mich ist die Erwartung, dass ihr das testet. Und einer sagt, wie? Auf die Idee wäre ich ja überhaupt nie gekommen. Und das funktioniert nicht im theoretischen Raum, das funktioniert nur an einem konkreten Beispiel. Also so kann man da rangehen. Ja, man muss sich austauschen. Ich glaube, man sollte die klassischen Rollenbilder ein bisschen auflösen. Ja, also die Tester und
die Entwickler. Sehr gerne hätte ich auch noch die Architekten dabei und Designer und Requirements vielleicht. Ja, also ich hatte vorhin schon gesagt, Springen zum Beispiel ist an ein paar Stellen gar nicht so schlecht, dass das auch an Testen gedacht wird. Ja, gerade was so dieses Service angeht. Aber wir haben ganz viele, also in meiner Wahn, ganz viele technische,
architektonische Entscheidungen, die völlig im testfreien Raum getroffen werden. Also wo man, also für mich gehört zu einer Architekturbegründung auch dazu, dass man sagt, wie man das testen kann. Habe ich aber noch nie erlebt. Also dass jemand zu mir kam, wir haben hier was ganz tolles designt irgendwie, weiß ich nicht, es ist die Hyper-Cloud, irgendwas. Ja, und das kann man auch prima testen. Das ist nicht nur super, um das Business-Problem zu lösen, sondern ich kann
damit auch die Qualität vernünftig sicherstellen. Und wenn man sich Frameworks anguckt, testen, die Testmöglichkeiten kommen immer so hinterher, wenn man Glück hat. Das gehört für mich dazu. Das ist aber sicherlich noch ein weiter Weg. Also ich glaube im Wesentlichen, oder ich würde immer versuchen, so ein bisschen diesen Weg, diese Fehler nicht beliebig oft machen, sondern aus jedem Fehler ein Stück lernen, ein bisschen besser werden. Passt vielleicht auch zu den
iterativen Ansätzen, die wir so an anderen Stellen haben. Das ist so das, was ich so versuche, umzusetzen. Also ich fand da war ein Dank noch. Dann vielleicht auch mutig mal was wegschmeißen. Also das gehört auch dazu. Mutig zu sagen, okay, diese ganze Testsuite hier, wir machen da einen Riesenaufwand. Es funktioniert einfach nicht. Wir müssen das anders machen. Also so ein bisschen Mut gehört dann auch dazu. Ja, das finde ich auch richtig, dass man mal sagt, okay, was brauche
ich denn eigentlich überhaupt? Und diese Kommunikation, du hast es gerade auch so schön gesagt, das ist ja nicht nur etwas, was jetzt die Entwickler für sich ausmachen, sondern es ist auch gut, wenn man noch Tester hat oder sowas, dass die dann auch quasi ihren Blick dazu geben, dass ein Architekt seine Sicht dazu gibt, dass man auch eine Sicht hat, was heißt eigentlich
Testen jetzt hier in diesen Ebenen für uns? Ja, das und es gibt ja also gerade was diese Idee von der Testpyramide sagt, dass bestimmte Tests die Entwickler einfacher machen können, als die Tester. Bestimmte Tests können die Tester auch einfacher machen, als die Entwickler, nämlich gerade je näher will der dem Blackbox-Testing kommen. Und ich glaube, dass es viel zu wenig gegenseitiges Verständnis gibt. Also es gibt ganz oft die Situation,
wo dann jemand sagt, ja, aber das kann ich doch ganz einfach erledigen. Ja, das geht hier viel schneller und genau umgekehrt. Ja, die Entwickler möchten natürlich auch das Gefühl, dass sie sich darauf verlassen können, dass bestimmte Sachen auf der Ebene darüber getestet wird. Dafür ist es aber wichtig, dass man das mal artikuliert und dass dann auch mal ein Tester sagt, ja, habe ich verstanden und ich zeige dir das mal. Ja, hier ist unsere Test-Suite, hier machen wir genau das. Und dass
man auch zeitlich zusammenarbeitet. Also, dass wenn so ein Fehler auftritt, dass man sich das gemeinsam anguckt, dass man auf beiden Seiten lernt, die Testfälle zu lesen. Ja, wenn ich es lesen kann, dann weiß ich, was da passiert und schon ist das Vertrauen wieder ein Stück weiter da. Und das Wissen, was mein Teil des Spiels ist. Ja, also was ist mein Beitrag? Welche Annahme steckt in dem anderen Testfall drin, das ich zu leisten habe? Ja, und dann kommt man in eine Kommunikation und
dann kann man auch so ein System gemeinsam verantwortlich bauen. Das wäre so mein Credo. Ja, super. Also, perfekt. Das ist doch ein super Schlussstatement, finde ich. Das hat man vielleicht jetzt die Testpyramide herumgewirbelt bei dem einen oder anderen, finde ich ganz super. Ronald, ich danke dir sehr, dass du hier im Podcast warst und hier mal das Thema Testpyramide die Fahne geschwenkt hast oder mal auf den Kopf gestellt hast sozusagen.
Ja, du hast es gemacht. Ich würde mich auch über Feedback freuen, wenn Leute anderer Meinung sind, kann man gerne diskutieren. Ich glaube, auch das bringt uns alle ein Stück weiter. Das denke ich auch. Das teile ich mir gerne auf. Es kommen auch deine Kontaktdaten in die Show Notes und die Social Media. Da ist ja dann auch die Tür und Tor offen für eine rege Diskussion. Super. Vielen lieben Dank, dass du da warst. Ich wünsche dir alles Gute und vielleicht bis bald.
Ja, danke. Vielleicht gucken wir uns ja mal das nächste eiserne Gesetz der… So ist es. Könnten wir die Testpyramide anschauen. Ja, genau. Also, alles Gute. Ja, danke. Danke. [Musik]