Das Testen von Software im DevOps Kontext ist das Thema dieser Folge. Ich habe Luca Ingianni zu Gast, Er ist Ingenieur und neben seiner Tätigkeit als Trainer sehr vielseitig in der Praxis aktiv. Wir sprechen über das Testen im DevOps allgemein und die notwendigen Änderungen in Organisation, Selbstverständnis und Umfeld. Daneben klären wir, ob es in Zukunft überhaupt noch Tester geben wird, wie man in der Produktionsumgebung testen kann (oder nicht?) und was Testen in der Zukunft in Zeiten von DevOps ausmacht.
Inhalt
- Einführung in DevOps und Agile Entwicklung
- Die Evolution des Testens in DevOps
- Die Rolle der DASA in der DevOps-Ausbildung und -Zertifizierung
- Hintergrund und Expertise von Luca Ingianni
- DevOps definiert durch Luca Ingianni
- Das Konzept von ‚links und rechts‘ in DevOps
- Qualitätssicherung und kundenorientierte Entwicklung
- Der Übergang von manuellem zu automatisiertem Testen
- Die Bedeutung der Überwachung nach der Bereitstellung
- Die sich wandelnde Rolle von Testern in einer DevOps-Umgebung
- Testgetriebene Entwicklung und ihre Implikationen
- Die Bedeutung von Soft Skills und Kommunikation beim Testen
- Die Auswirkungen von DevOps auf traditionelle Testrollen
- Kosten-Nutzen-Analyse effektiven Testens in DevOps
- Abschließende Gedanken zu Qualitätssicherung und DevOps
Shownotes
Transkript (automatisiert erstellt, daher keine Gewähr 🙂 )
Hallo und herzlich willkommen zum DevOps-Podcast auf die Ohren und ins Hirn.
Ich habe heute zu Gast Luca Ingianni und wir reden über das Thema Testen im agilen Umfeld,
im DevOps-Umfeld. Freut mich sehr, dass ich jetzt wieder jemanden habe, der so ein bisschen
mehr auf der Technik-Ebene vielleicht unterwegs ist. Das wird sich zeigen. Beim letzten Mal hatten
wir ja Martin Andenmatten dabei zum Thema ITIL 4 und DevOps. Das waren also eher so Übersichten,
was Frameworks und Ansätze angeht. Also heute wird es ein bisschen technischer und Luca Ingianni ist
mit mir gemeinsam im DevOps-Trainer-Team unterwegs. Das heißt, wir sind ja beide als DevOps-Trainer
unterwegs und Luca bietet darüber hinaus auch noch andere Dinge an. Ich denke, das kann er jetzt
am besten selber erzählen. Luca, stell dich doch mal ganz kurz vor. Ja, gerne. Also vielen Dank,
Dirk, für die Einladung. Ich bin tatsächlich mit dem Dirk gemeinsam viel als DevOps-Trainer
unterwegs, aber das ist nicht das Einzige, was ich mache. Ich mache auch Beratung. Ich sage immer,
ich verdiene mein Geld auch manchmal mit ehrlicher Arbeit. Ich mache auch Engineering.
Wichtig ist, Teams dabei zu helfen, ihre Arbeit besser zu machen. Auf technischer Ebene, auf kultureller
Ebene. Ich bin derjenige, der dabei helfen kann, dass die Umsetzung sauber gelingt. Ehrliche Arbeit,
gutes Stichwort. Wenn wir auf die ehrliche Arbeit nachher nochmal eingehen. Wir haben es schon gesagt,
wir sind beide als Trainer in einem Team unterwegs und beziehen uns dabei auf das, was die DASA
bereitstellt an Trainingsunternehmen.
Trainingsunterlagen oder an Syllabus. Kannst du vielleicht da nochmal ein bisschen was zu sagen
zu DASA und wie du bei der DASA arbeitest gerade?
Ja, also die DASA ist die DevOps Agile Skills Association. Das ist eine Gruppierung von Leuten,
die versuchen, DevOps vielleicht zu definieren, die auch versuchen, das über eine Zertifizierung
so ein bisschen zu systematisieren, welche Bereiche es da gibt, welche Fähigkeiten vielleicht jemand
haben könnte.
Und mit denen zusammen, also zum einen bediene ich mich natürlich ihrer Zertifizierungen, auch im Rahmen der
Kurse, die ich gebe. Und zum anderen mache ich gerade in deren Auftrag einen neuen Lehrplan für einen
neuen Kurs, einen neuen Kurs im DevOps-Umfeld über das Thema Spezifikation und Verifikation. Zusammen mit
noch einem dritten aus unserem Trainerteam, dem Falko Werner.
Jetzt haben wir über die DASA gesprochen, über DevOps gesprochen und in meinem Podcast kommt es zu einem
Thema, in dem es sich um die Frage an jeden neuen Teilnehmer handelt. Wie würdest du DevOps definieren?
Naja, du weißt ja, wie es ist. Wenn du zwei Leute fragst, kriegst du fünf Antworten. Nicht mal interessanterweise die deutsche und die englische Wikipedia sind sich einer Meinung, was DevOps wirklich bedeutet.
Aber für mich persönlich bedeutet DevOps eigentlich das konsequente Zu-Ende-Denken von agiler Entwicklung.
Agil, sagen wir mal, in seinem ursprünglichen Ansatz hat sich rein auf die Softwareentwicklung gelegt.
Und das ist aber vielleicht ein bisschen zu kurz gesprungen. Man muss einfach noch weiter nach links schauen und muss weiter nach rechts schauen.
Man muss den Kunden im Fokus haben, man muss aber auch den Betrieb im Fokus haben.
Nur wenn diese gesamte Kette vernünftig greift, dann wird man in der Lage sein, ein wirklich gutes Produkt im Sinne des Kunden rauszubringen.
Das ist für mich DevOps. Agil, konsequent zu Ende gedacht.
Und konsequent zu Ende gedacht, finde ich interessant, nach links und nach rechts, also den Kunden mit dazunehmen.
Den Betrieb mit dazunehmen. Und schlussendlich kommt ja nach dem Betrieb dann auch wieder der Kunde, der ja das auch dann, das Produkt erhält, was wir nicht nur entwickeln, sondern auch betreiben.
Genau, der Kunde ist links und rechts.
Richtig, ja. Am Anfang und am Ende.
Genau.
Jawohl. Gut, okay. Du hast ja eben gesagt, ihr schreibt dieses White Paper für die DASA und das werde ich in den Shownotes auch verlinken, den Hinweis oder die Quelle an der Stelle.
Also insofern, wir werden uns jetzt bei dem Podcast ein bisschen auf dieses White Paper, auf das beziehen, was du dort geschrieben hast mit Falco zusammen.
Vielleicht mal so eine grundsätzliche Einschätzung. Was findet man denn in diesem White Paper?
In dem White Paper oder in diesem Lehrplan, den wir daran angelehnt aufbauen, geht es um genau die Sachen, die links und rechts von der Entwicklung stattfinden.
Das heißt, es geht einerseits um Spezifikation.
Ja, die Wünsche des Kunden entdecken, sprichwörtlich, aufnehmen, systematisieren, dann den Entwicklern zur Verfügung stellen und dann machen die halt ihr Ding und dann hinterher aber auch wieder nachzuprüfen,
habe ich das, was der Kunde gewünscht hat, korrekt umgesetzt? Wünscht der Kunde überhaupt das immer noch oder hat er mittlerweile selber auch dazugelernt?
Das heißt, das ist eben auch ein Bestandteil davon.
Weiter nach links und weiter nach rechts zu schauen, als in Anführungszeichen nur die Entwicklung.
Okay. Insofern ist ja so, wenn ich das so, auch meine Sicht auf das Thema Testen nehme, geht es ja bei Testen eigentlich hauptsächlich um Qualitätssicherung, oder?
Ja, das kann man so sehen. Dann stellt sich natürlich die spannende Frage, was ist denn eigentlich Qualität?
Ja, dann erklär mal.
Ja, ich würde den Spieß gerne umdrehen. Was verstehst du?
Ui, das ist natürlich eine gute Frage. Das ist auch eine gemeine Frage, weil ich wollte von dir die Antwort hören.
Was verstehe ich unter Qualität? Ich muss erst mal nachdenken, wenn ich mir das so durch den Kopf gehen lasse.
Also wichtig ist, glaube ich, erst mal, dass nur der Kunde die Qualität bestimmen kann oder den Anspruch bestimmen kann.
Das heißt, ob ein Produkt oder Dienstleistung qualitätsmäßig gut ist, kann nur der Kunde entscheiden, würde ich jetzt so ad hoc mal sagen.
Und dann gibt es eben Dinge, die ich unterscheiden würde. Qualität im Sinne von, die Anforderungen sind erfüllt.
Also das, was ich damit tun will, funktioniert, kann ich damit machen.
Und technische Qualität, also das, was wir auch mit nicht-funktionalen Anforderungen kennen, sprich Antwortzeitverhalten, Stabilität und so weiter.
Also das wären so meine ersten Antworten in dem Umfeld.
Ja, genau. Also eigentlich ganz stumpf kann man sagen, nützt es mir was?
Dann habe ich ausgerechnet Qualität.
Also stabil ist oder nicht, ist ja wurscht. Hauptsache, vielleicht ist das ja gar nicht schlimm, dass die abstürzt.
Vielleicht stört mich das gar nicht oder vielleicht ist das total blöd.
Insofern, Absturzfreiheit jetzt als Beispiel genommen, ist jetzt nicht zwingend ein Zeichen für schlechte Qualität oder gute Qualität.
Es kommt wirklich darauf an, das, was der Kunde wünscht, kann er das bekommen von dieser Software.
Okay. Wobei ich muss sagen, mit dem Abstürzen, da hätte ich schon einen anderen Anspruch an die Qualität.
Also eine Software, die ich habe, die ich nutze.
Auf die muss ich mich auch verlassen können.
Das gilt bei vielen anderen Produkten auch.
Ich muss sicher gehen, dass das Auto weiterfährt und so weiter.
Also da habe ich vielleicht auch noch eine andere Einschätzung.
Ja, aber da hast du genau den Kern gesagt.
Du musst dich auf sie verlassen können.
Und wenn zu Zuverlässigkeit Absturzfreiheit eigentlich gar nicht gehört, in dem speziellen Fall,
dann ist das ja voll okay, wenn es die ab und zu mal zusammenhaut.
Das mag natürlich in vielen Fällen nicht so sein, das ist schon klar.
Aber zum Beispiel…
Zum Beispiel, das ist ein Ansatz, der häufig in der Telekommunikation verwendet wird.
Die haben da häufig den Ansatz, let it crash.
Wenn die Software Schwierigkeiten macht, dann lass sie in Gottes Namen umfallen.
Mir egal, weil diese Software steuert ein Gespräch von einer Million.
Dann geht halt ein Gespräch den Bach runter, das ist zwar sehr traurig,
dann soll der andere halt nochmal anrufen.
Ärgerlich ist es, wenn ich gerade bei einer Buchung bin, nicht bei dem Kontieren.
Da würde ich sagen, lass es mal runterfallen.
Das ist ja nur eine von tausenden von Buchungen, weiß ich nicht.
Ja, trotzdem…
Machen die das so und machen die das schon seit Jahrzehnten so
und ich unterstelle mal, du bist mit der Qualität des Telefonsystems durchaus zufrieden.
Also Telefonsystem ja, aber Buchung eben nicht.
Also ich bin dabei, eine Rechnung zu schreiben und dann stürzt eben das System mal ab,
dann schreibe ich die Rechnung neu.
Da wäre ich ein bisschen not amused.
Ja, aber angenommen, das Ding würde zum Beispiel deine Rechnung speichern
und du könntest einfach dann sofort an derselben Stelle wieder weitermachen
und du hättest eigentlich nur so mal kurz so ein paar Sekunden flackern.
Das, ja.
Ja, das soll es, ne?
Also jedenfalls Kern ist eben wirklich der,
das, was der Kunde sich davon wünscht, zum Beispiel störungsfreie Rechnungen schreiben,
das muss erfüllt sein.
Wie es erfüllt ist, das steht auf einem völlig anderen Blatt.
Insofern, das ist, glaube ich, der Kern bei Qualitätssicherung,
dass man sich wirklich erst mal vor Augen führen muss, worin besteht denn Qualität?
Und deswegen fand ich das so toll, dass du vorhin so ein bisschen rumgestammelt hast.
Das macht man sich nämlich häufig gar nicht so richtig bewusst.
Was brauche ich denn eigentlich?
Was erwarte ich denn eigentlich von meinem Produkt?
Und genau das muss ich dann auch nachweisen.
Und das ist ja dann die spannende zweite Frage.
Wie gut muss es denn sein?
Ja gut, wie gut muss Software sein?
Das, was ich zu Anfang ja schon sagte, das ist etwas, was der Kunde formuliert,
wo ich als IT-Team, als Team, die das, also die Qualitätsanforderungen aufnehme
und beschreibe und dann auch eben entsprechend umsetze.
Aber das Wichtige ist doch, wie gut muss es denn wirklich sein?
Wie gut muss Software denn sein?
Es ist ja ganz klar, zum Beispiel,
es gibt verschiedene Qualitätsansprüche zwischen einem Tamagotchi und einem Herzschrittmacher.
An das eine würde ich wahrscheinlich höhere Ansprüche stellen als an das andere.
Wobei, ob jetzt der Qualitätsanspruch an einem Tamagotchi niedriger sein muss,
das hängt glaube ich davon ab, ob man vierjährige Kinder hat oder nicht.
Sehr schön, ja.
Wir haben es über das Testen jetzt gesprochen.
Gibt es noch irgendwas anderes Wichtiges, was für dich in dem Kontext Testen denn von Bedeutung ist?
Ja, es gibt etwas, was ich für ganz zentral halte
und was wiederum sich viele Menschen interessiert.
Und was viele Leute nicht so ganz bewusst machen.
Nämlich, es ist ja so ein bisschen dumm beim Testen.
Man würde ja ganz gerne nachweisen, dass eine Software fehlerfrei ist.
Das Blöde ist bloß, durch Tests kannst du Fehlerfreiheit nicht feststellen.
Du kannst nur Fehler feststellen.
Das bedeutet, die einzige Möglichkeit, die dir das Testen bietet, ist, Vertrauen aufzubauen.
Und ich finde, es ist ganz wichtig, sich das bewusst zu machen.
Insbesondere auch, wenn man im DevOps-Kontext darüber nachdenkt.
Im Kontext einer erhöhten Geschwindigkeit, Automatisierung und so weiter.
Alles, was ich tue mit Testen oder anderen Formen von Qualitätssicherung,
ist ausreichendes Vertrauen in mein Produkt herzustellen.
Mehr kann ich nicht schaffen, als dass ich sagen kann,
ja, ich glaube, das können wir auf unsere Kunden loslassen.
Wir haben es gründlich geprüft.
Wir finden nichts mehr.
Wir wissen mit unserer Erfahrung, irgendwo wird schon noch ein Hund drin sein.
Aber wenn, dann ist das hoffentlich nichts Schlimmes mehr.
Weil, so genau wir auch schauen, wir finden es nicht.
Okay, das muss jetzt passen.
Darum, das ist ganz zentral.
Testen kann nichts anderes tun, oder Qualitätssicherung kann nichts anderes tun,
als Vertrauen aufzubauen.
Okay, ja, na gut.
Also, was ich interessant finde, war die Aussage,
dass ich ja mit dem Testen nur Fehler finde.
Aber Fehlerfreiheit ja nicht quasi nachweisen kann oder erzeugen kann.
Genau.
Okay, jetzt haben wir das Thema DevOps als Überschrift für den Podcast
und auch für uns.
Und für unsere gemeinsame Arbeit.
Testen gibt es ja jetzt nicht erst, seit es DevOps gibt.
Also, Testen gab es ja schon zu meiner Zeit, als ich angefangen habe mit IT.
Also, es ist schon ein paar Tage her.
Gibt es irgendetwas, was sich in dem Thema Testen verändert hat durch DevOps
oder auch vielleicht einfach nur durch die Jahre,
durch die Jahre, in denen wir mit Test arbeiten?
Ja, sicherlich.
Also, man begann ja damit, dass man einfach manuell getestet hat
und vielleicht auch nur stichwörtlich.
Und mittlerweile ist das Pendel sehr weit in die Richtung geschwungen,
dass man sehr viel automatisieren möchte,
was natürlich gut zu DevOps passt,
das ja auch sehr stark den Fokus auf Automatisierung setzt.
Nicht zuletzt, weil man sich davon verspricht,
eine höhere Geschwindigkeit zu erreichen.
Aber die Frage ist natürlich,
tut man sich damit wirklich einen Gefallen
oder produziert man Produkte, die zwar schnell rauskommen,
aber die vielleicht gar nicht so stabil sind,
weil man gar nicht mehr die Zeit hatte, so gründlich zu untersuchen.
Das ist eine Frage, die ich sehr häufig höre in meinen Trainings,
dass die Leute dann etwas skeptisch werden und sagen,
ja, jetzt mal so bei aller Liebe,
wenn ich bis hin zu Continuous Deployment gehe und sage,
sobald jemand seinen Code fertig geschrieben hat,
dann knistert es mal kurz in der Maschine
und fünf Minuten später ist das Ding live.
Sag mal, bist du noch ganz bei Trost, Luca?
Insofern, wie kann man sicherstellen,
dass dieses Vertrauen, von dem wir vorher sprachen,
weiterhin bestehen bleibt und auch gerechtfertigt ist?
Und was würdest du in dem Umfeld empfehlen
oder was antwortest du auf diese skeptischen Fragen?
Naja, die Antwort ist die,
man macht die Dinge jetzt halt anders als vorher.
Also das ist jetzt nicht mehr wie zu Opis Zeiten.
Aber trotzdem wird man natürlich den Fokus
vielleicht sogar noch mehr auf Qualität legen,
als man es früher getan hat.
Man verschiebt nur den Zeitpunkt, an dem man verifiziert
und dann wird man nicht mehr so weit.
Die Methoden, mit denen man verifiziert, woanders hin.
Der eine Punkt ist, ich verlege sehr viel nach vorne
in Richtung der Spezifikation.
Also ich sage, ich schreibe jetzt nicht
mein 500-seitiges Anforderungsdokument,
knall das den Entwicklern auf den Tisch
und höre zwei Jahre nichts mehr von denen,
sondern ich spreche sehr häufig mit denen.
Ich stelle sicher, dass das, was ich mir überlegt habe,
wirklich Hand und Fuß hat.
Ich reagiere auf neue Erkenntnisse.
Das hat jetzt also nichts mit Testen zu tun,
sondern ich stelle schon im Voraus sicher,
dass das, was ich baue, überhaupt das ist,
was ich bauen sollte und so, wie ich es bauen sollte.
Das Zweite ist, natürlich, ich automatisiere sehr stark.
Ich habe eine aufwendige Testsuite.
Aber jeder, der sich ein bisschen intensiver
mit Testen beschäftigt hat, weiß,
es gibt gewisse Dinge, die sind einfach,
die findet eine Maschine nicht.
Ein Mensch findet die eine Maschine,
wird die nicht sinnvoll finden.
Was mache ich jetzt mit denen?
Da ist die Antwort.
Das schiebt man weiter nach hinten.
Das schiebt man nicht nach hinten.
Das schiebt man nämlich sogar
bis hinter die Auslieferung im Zweifelsfalle.
Indem man sagt, ich finde solche Arten von Defekten
nicht mehr im Test vor der Auslieferung,
sondern ich überwache während und nach der Auslieferung
mein Produkt sehr akribisch, sehr engmaschig.
Und sobald ich merke,
irgendwas ist da nicht ganz so, wie ich mir das vorstelle,
dann reagiere ich an dieser Stelle.
Das ist das, was wir früher Bananensoftware genannt haben?
Ah, danke schön.
Reif beim Kunden.
Ja, danke schön.
Das ist das Argument, das an der Stelle kommt.
Ja.
Das stimmt in einem Sinne schon,
aber im anderen natürlich nicht,
weil wenn ich dann in der Lage bin,
mir diese Geschwindigkeit zunutze zu machen,
um auf der Stelle zu reagieren,
auf der Stelle erkannte Probleme abzustellen,
bevor es der Kunde überhaupt richtig geschnallt hat,
dann habe ich ihm ja nichts Böses getan.
Okay.
Das bedeutet eben, wenn ich gutes Monitoring habe,
wenn meine ganze Organisation
technisch, kulturell, personell
so aufgestellt ist,
dass ich in der Lage bin,
mit dem Kunden in einem Dialog zu sein,
ob er es merkt oder nicht,
das kann ja auch einfach nur in einer passiven Beobachtung bestehen,
und unmittelbar zu reagieren,
wenn da irgendwas nicht ganz so läuft,
wie man es sich vorgestellt hatte,
dann habe ich ja trotzdem noch eine ausreichend hohe Qualität,
dann habe ich weiterhin das Vertrauen in mein Produkt,
so wie ich es ausliefere.
Vertrauen in dem Falle nicht,
weil ich mich vielleicht schon vorher vergewissert habe,
dass das fehlerfrei ist.
Na gut, kann ich eh nicht.
Sondern, dass ich weiß,
wenn irgendwas schiefläuft,
dann kann ich eingreifen und schnell eingreifen
und so gut eingreifen,
dass die Wünsche des Kunden weiterhin erfüllt bleiben.
Wenn ich das jetzt für mich nochmal mit meinen Worten formuliere,
dann sehe ich das ja,
also ich habe ja auch dann die Leute vor Augen jetzt gerade,
die in den Schulungen sitzen,
die eher so aus der klassischen,
alles genau beschreiben,
alles genau durchtesten,
jeden Fehler finden wir vorher, keine Frage.
Was du jetzt sagst,
geht ja eben dann genau auch quasi konsequent in die andere Richtung.
Natürlich einen hohen Qualitätsanspruch,
aber wir können eben vielleicht nicht vorher alle Fehler finden.
Was heißt vielleicht?
Du sagst ja, man kann vorher nicht alle Fehler finden,
dann lieber möglichst genau,
also Aufgaben nach links verschieben,
also shift left nach vorne,
respektive dann auch hintendran eben verbessern.
Sprich, dass das Testen sich eigentlich nicht nur auf das Testen
vor der Auslieferung bezieht,
sondern eigentlich auch Monitoring mit reinfällt,
um in der Live-Umgebung,
eben auch quasi zu testen in einem moderneren Sinne.
Genau, das ist der Kern der Sache,
dass man Testen nicht mehr als eine punktuelle Aktivität hat
während des Entwicklungsprozesses,
sondern genauso wie die gesamte Perspektive von DevOps
sich weiter nach links und nach rechts verschiebt,
muss auch Testen oder Qualitätssicherung
sich weiter nach links und weiter nach rechts verschieben.
Ich muss sicherstellen,
dass zu Anfang meine Anforderungen noch sauberer sind als bisher
und dass zweitens auch,
nachdem ich der Automatisierung
der Test beispielsweise gemacht habe,
nach hinten raus,
ich immer noch ein viel schärferes Augenmerk
auf die Qualitätssicherung mache nicht.
Das Ding wird irgendwie jetzt über den Zaun geschmissen,
ausgeliefert, nicht mehr unser Problem.
Interessant, also ich habe mich ja mit dem Testen
noch nicht so detailliert beschäftigt,
was du jetzt ja mir doch schon sehr gut erklärst an der Stelle.
Wenn ich mir das jetzt so vor Augen führe,
dann hätte ich jetzt gesagt,
es gibt ein paar Rollen,
die auch sagen, das machen wir so nicht.
Das verstößt gegen meine aktuelle Berufsethik
oder im schlimmsten Falle,
es gibt meinen Job gar nicht mehr oder mein Job ist anders.
Also wie reagieren denn Tester zum Beispiel auf solche Konzepte,
auf solche Aussagen?
Ja, das ist ganz unterschiedlich.
Also es gibt ohnehin eine gewisse Erwartung,
dass automatisches Testen Tester überflüssig machen würde,
was natürlich überhaupt nicht stimmt.
Irgendjemand muss ja diese automatischen Tests
nicht nur ursprünglich mal erstellen,
sondern vor allen Dingen auch weiter pflegen.
Die machen ja auch weiterhin Mühe.
Die müssen gewartet werden.
Die Testergebnisse müssen analysiert werden.
Es muss Leute geben,
die diese Testergebnisse überhaupt verstehen können.
Aber die andere Frage ist,
gibt es eigentlich den Tester noch,
wie man ihn kennt?
Also einen Typ, der irgendwo sitzt
und der dann versucht, Löcher in die Software zu hauen.
Ich stelle mir das gerade vor.
Löcher in die Software hauen.
Das ist eine schöne Umschreibung für einen Tester.
Ja, ich habe ja auch viel mit Embedded Software gearbeitet.
Da muss man manchmal auch wirklich physisch
irgendwo was kaputt machen.
Okay.
Ja, also was passiert denn mit den Testern?
Ja, der Tester, der testet,
den gibt es dann wirklich nicht mehr.
Der wäre ja ein Fremdkörper
in einer schnellen DevOps-Organisation.
Jetzt habe ich irgendwie rasend schnell
mein Produkt entwickelt
und habe eine wahnsinns Deployment-Pipeline
und solche Sachen.
Aber nee, jetzt braucht erstmal die Testabteilung noch drei Wochen,
um das Ding auf Herz und Nieren zu testen.
Das ist ja ein bisschen widersprüchlich.
Sondern Tests sind dann eben Dinge,
die automatisch schnell laufen während der Entwicklung
oder die sich durch Monitoring nach der Entwicklung
in der Produktion wiederfinden.
Und die Aufgabe des Test-Experten,
so nenne ich ihn mal,
ist es dann sicherzustellen, dass das sauber läuft.
Das heißt, er hat eine beratende Funktion.
Er muss den Leuten, die links und rechts von ihm sitzen,
dabei helfen, Qualitätsansprüche umzusetzen.
Er hat Architekturverantwortung.
Er muss mitreden und sagen,
passt mal auf, wie wollen wir diese Funktion,
die ihr euch vorstellt, denn eigentlich mal testen?
Wie können wir das überhaupt technisch gewährleisten?
Er muss allen beteiligten Softwareentwicklern,
Spezifikateuren, vielleicht sogar dem Kunden,
dabei helfen, zu verstehen,
wie Qualität überhaupt aussieht für das bestehende Produkt,
welches Vertrauensniveau notwendig ist,
wie wir dieses Vertrauensniveau herstellen können.
Das heißt, er hat eine viel stärker konzeptionelle,
beratende, sprechende Funktion.
Okay. Das heißt, in dem Umfeld würde er dann auch
bei dem Thema Test-Driven Development mithelfen.
Also er würde helfen, die Entwicklung entsprechend so auszurichten.
Ja, genau.
Und Test-Driven Development impliziert natürlich auch,
dass es automatisiert ist, ist die Frage,
wer schreibt denn diese Tests? Schreibt die der Tester?
Schreibt die der Softwareentwickler? Schreibt die noch wer anders?
Keine Ahnung. Was ja auch eine spannende Frage ist,
denn das ist genau der Punkt.
Die Aufgabe des Testers ist es im Einzelfall jetzt vielleicht
gar nicht mehr, Tests zu verfassen,
sondern die richtigen Fragen zu stellen, zu sagen,
wie wirst du das hier testen?
Und hast du schon ausreichend getestet,
der vielleicht einem Entwickler dabei hilft,
die Testautomatisierung gut zu nutzen?
Okay. Oder Menschen quasi, die in diesem Umfeld wichtig sind.
Ich habe ja eben jetzt nur von dem Tester gesprochen.
Du hast gesagt, das ist für dich der Testexperte.
Gibt es noch andere Rollen, die sich in dem Testumfeld
ja eben verändern werden?
Ja, klar. Nenne mich alle.
Okay.
Der Tester ist jetzt eben nicht mehr derjenige,
der quasi als einziger den Hut auf hat,
sich um Qualität kümmern zu müssen,
sondern das ist eine Verantwortung,
die jetzt in viel stärkerem Maße alle trifft,
die irgendwie an der Produktentstehung beteiligt sind.
Der Kunde, in dem er wirklich mitteilen muss,
was braucht er denn für eine Qualität?
Wie definiert sich für ihn Qualität?
Ein Product Owner, ein Spezifikateur, was weiß ich,
der dafür sorgen muss, dass die Anforderungen Qualität bereits im Blick haben.
Der Softwareentwickler, der automatische Tests schreiben muss,
der in eine Konversation tritt mit den Testexperten, mit den Kunden.
Ein Infrastrukturingenieur, der das Monitoring zur Verfügung stellen muss,
der eine automatische Testinfrastruktur einerseits nutzt,
andererseits vielleicht betreibt.
Weil, das ist ja übrigens auch ein spannendes Thema.
Ich kann ja in einer Everything-as-Code-Umgebung
plötzlich auch meine Infrastruktur testgetrieben entwickeln.
Das heißt, auch der Gegenstand der Tests könnte sich jetzt ändern.
Es ist nicht mehr nur allein das Produkt,
sondern es kann auch wirklich die Basis, die Infrastruktur sein,
das Netzwerk, sagen wir mal, in dem das alles läuft.
Also, sehr, sehr interessante Frage.
Vielen Dank für die Gedanken oder Ausführungen.
Ich habe jetzt gerade vor Augen,
ich war gerade vor zwei Tagen beim Training, Scrum-Training,
und da hingen noch alte Unterlagen von einem anderen Kurs,
der wohl vorher stattgefunden hatte,
der genau um das Thema Anforderungsspezifikation geht.
Und da habe ich mich jetzt gerade so ein bisschen daran erinnert,
denn mein Ansatz bei den Scrum-Trainings ist ja zu erklären auch,
wie ich denn Anforderungen beschreibe und dass ich eben Wert lege auf die Anforderungen,
Quatsch, auf die Akzeptanzkriterien.
Das heißt, dass letzten Endes, bevor der Entwickler loslegt,
er eigentlich wissen muss, auf was entwickelt er denn hin.
Also, dass der Kunde eben nicht sagt, die Software muss schnell sein
oder diese Funktion muss mir das und das ermöglichen,
sondern dass man wirklich klar ausarbeitet vorher, was heißt denn das?
Also, die Anforderungen besser zu beschreiben,
insbesondere auf das, was eben der Entwickler produzieren soll.
Und wenn du jetzt sagst, das Testen hat damit einen ganz großen Vorteil,
hat damit einen ganz, ganz anderen Stellenwert, eben von Anfang bis Ende.
Also, den Tester gibt es nicht mehr oder nicht mehr in der Form, wie wir ihn jetzt kennen,
weil er einfach jetzt quasi alle Testen im Blut haben müssen.
Genau. Insbesondere, wenn man so Techniken macht wie Behavior-Driven Development, BDD
oder auch genannt Specification by Example,
da gibt es in der Literatur gerne genannt die sogenannten Three Amigos.
Das sind dann die drei Freunde des Business, der Entwicklung und die Tester,
die sich wirklich zusammensetzen müssen und gemeinsam eine Specifikation entwickeln müssen,
die natürlich nicht nur funktionale Wünsche enthält, sondern auch Abnahmekriterien,
auch nicht funktionale Anforderungen, auch konkrete Beispiele, anhand derer man nachweisen kann,
ja, wir haben das gesteckte Ziel tatsächlich erreicht.
Gibt es noch Punkte von dir, die du jetzt in diesem Umfeld Tester, also Rollen und Menschen anführen würdest,
die wir noch ergänzen sollten?
Nein, ich glaube, das war es. Das Wichtige ist wirklich der Tester,
den gibt es nicht mehr. Es gibt jemanden, der ein Testexperte ist oder ein Qualitätsexperte ist,
der dem ganzen Team dabei helfen muss, Qualität sicherzustellen und dabei die gesamte Kette im Blick hat.
Also so wie du das jetzt darstellst, passt das für mich auch in das gesamte Bild.
Wir versuchen ja mit dem Thema DevOps hochperformante IT-Organisationen zu schaffen
und letzten Endes weg von den Silos und genau das ist ja der Punkt.
Das heißt, dass die Qualitätssicherung letzten Endes durchgängig ist.
Von Anfang bis Ende und dass ich eben jetzt nicht einen Experten habe, der alle Testszenarien kennt und so,
sondern dass ich einfach den Anspruch habe, nicht nur Qualität zu produzieren, sondern auch Qualität zu sichern
und das eben durch Testen, ich sag mal Testen in Anführungsstrichen, weil sich ja Testen dann auch verändert,
dass ich das umsetze und sicherstelle, eben durch den gesamten Prozess der Erstellung bis hin zur Auslieferung.
Genau und Geschwindigkeit, wir sprechen ja auch immer darüber,
DevOps solle nachhaltige Geschwindigkeit herstellen.
Geschwindigkeit ist ja auch kein Selbstzweck, denn ein Produkt, das nicht ausgeliefert werden kann,
weil wir es nicht fertig kriegen, weil jetzt wir noch, keine Ahnung, zum Beispiel aufwändige manuelle Qualitätssicherung machen müssen,
das ist quasi per Definition die schlechteste Qualität, die wir haben können, das Produkt ist gar nicht da.
Ja stimmt, da stimme ich dir zu, was das Thema Qualität angeht.
Genau.
Ja okay, gut, ich habe eben gesagt, bis zur Produktion,
bis zu dem Betrieb, wie sieht es denn aus mit dem Thema Testen in der Produktion, in der Live-Umgebung,
weil du hast ja gesagt, da monitore ich, also mache da im Prinzip auch Qualitätssicherung.
Ja genau und das muss ja auch die Konsequenz daraus sein, dass ich sage, ganz bewusst überspringe ich gewisse,
sagen wir mal traditionelle Teile der Qualitätssicherung, dass ich mir eine Analysephase mache,
die sehr lange dauert, nachdem das Produkt fertiggestellt wurde, sondern sobald ein Produkt oder Produktabschnitt fertig wurde,
ist der potenziell deploybar.
Wird vielleicht im Rahmen von Continuous Deployment sogar schon auf der Stelle deployed,
dann muss ich natürlich sicherstellen, dass ich trotzdem auf Überraschungen reagieren kann.
Und das kann ich nur machen durch ein wirklich ausführliches Monitoring und vor allen Dingen das, was dann auf das Monitoring folgt.
Monitoring alleine hilft mir noch gar nichts, sondern das Feedback muss dann auch wirklich seinen Weg wieder zurückfinden
zu den jeweiligen Entwicklern, schnell, präzise und auch die Entwickler müssen in der Lage sein, darauf zu reagieren,
wenn die jetzt merken, aha, ich habe da was entwickelt.
Ich habe die Produktion geschafft und jetzt erfüllt es aus irgendeinem Grund nicht meine Vorstellungen.
Das muss ja gar nicht heißen, es funktioniert nicht, es stürzt ab oder sowas, sondern es kann ja auch einfach nur sein,
die Benutzer finden es jetzt irgendwie doch nicht so toll.
Dann muss ich in der Lage sein, darauf schnell zu reagieren und gleich eine verbesserte Iteration nachzuschieben.
Dann, wenn mir das gelingt, dann habe ich wirklich die Macht von DevOps realisiert,
ganz unmittelbar, ganz schnell und auch trotzdem solide auf neue Erkenntnisse reagieren zu können.
Und das ist dann das, was wahrscheinlich Gene Kim mit seinem dritten Weg dann beschreibt.
Ja, genau.
Schnell Feedback sicherstellen und wir reden dann ja hier nicht nur über Feedback im Sinne von oder also regelmäßiges Feedback.
Wir reden nicht davon, dieses Feedback quasi in irgendwelchen Gesprächen zu haben, täglich sich irgendwo zusammenzustellen,
sondern dann vielleicht sogar noch kurzfristiger zu reagieren und das dann gar nicht mehr mit irgendwelchen Abstimmungsrunden,
sondern die Entwickler kriegen das quasi direkt auf den Rechner gespielt.
Sie müssen was tun, weil sie eben erkennen, da laufen Dinge nicht so wie geplant.
Na klar. So, angenommen, ich deploye jetzt eine neue Funktion von meiner Software,
dann muss ich da schon entsprechendes Monitoring installiert haben, sodass ich sehen kann, wird diese Funktion überhaupt genutzt?
Jetzt angenommen, ich habe eine gewisse Benutzerbasis und ich erwarte, dass jeden Tag 100 Leute diese Funktion in Anspruch nehmen werden.
Und jetzt stelle ich aber fest, das sind gar nicht so viele, das sind irgendwie bloß drei oder vier.
Diese Information, die kann ich ja automatisch sammeln. Keine Ahnung, wenn das eine Website ist, kann ich ja sehen, wie oft wird diese Seite abgerufen.
Und dann versetzt mich das in die Lage, sofort die Frage zu stellen, was ist denn da passiert?
Funktioniert diese Funktion nicht? Ist sie an den Wünschen der Kunden vorbei entwickelt oder wird sie einfach nur nicht gefunden?
Vielleicht ist das Problem ja total stumpf und die haben das doch gar nicht entdeckt, dass die da ist. Aber diese Mechanismen muss ich haben.
Und das würde dann ja auch auf den Kritikpunkt, sage ich mal, auch kommen.
Wir haben ja in unseren Trainings ja nicht nur Web-Entwickler und App-Entwickler, die wirklich schnell Dinge rausbringen wollen.
Wir haben ja auch an vielen Stellen Entwickler.
Und Mitglieder aus Teams, die eine, ich sag mal, eher stabile Software haben, die gar nicht auf diese Schnelligkeit an sich auch aus ist.
Und die fragen natürlich immer, was ist denn, wenn ich jetzt, ich muss ja nicht in der Buchhaltung jeden Tag eine neue Funktion bringen.
Oder nicht jeden Tag eine neue Funktion im wahren Wirtschaftssystem. Ich muss ja andere und neue schulen.
Das geht ja auch in die Richtung, quasi dieses Monitoring auch auf die Nutzung der bereitgestellten Funktionalitäten auszudehnen.
Abgesehen davon, das kann ja auch ein Qualitätskriterium sein, dass ich sage,
hey, die Software soll zumindest nach außen hin sich stabil verhalten.
Natürlich will ich nicht jeden Tag meine Benutzer umschulen. Die werden mir was husten.
Aber das Mächtige ist, dass ich in der Lage bin, so schnell zu reagieren, wenn ich es denn muss.
Wenn ich jetzt plötzlich feststelle, ich habe in meiner Buchhaltung irgendwie einen Fehler drin.
Da kann ich doch nicht bis zum nächsten Auslieferungsfenster in drei Monaten warten.
Sondern wenn ich dann technologisch, personell, kulturell in der Lage bin, auf der Stelle zu reagieren und diesen Fehler zu beheben,
dann bin ich doch in einer wahnsinnig starken Position.
Wirklich hohes Vertrauen in mein Produkt.
Das bedeutet, selbst wenn ich nur alle drei Monate neue Features rausbringe, die für meinen Kunden eine Veränderung sichtbar machen,
allein der Umstand, dass ich auf erkannte Fehler blitzartig reagieren kann, das ist für mich die große Stärke und das, was DevOps wirklich ausmacht.
Richtig. Ja, eben hoch performant. Also nicht nur schnell entwickeln und auch schnell reagieren und schnell,
also nicht nur schnell entwickeln, schnell ausliefern, aber eben auch schnell sicherstellen, bei Fehlern schnell zu reagieren.
Ja, genau. Also das ist auch eine Frage, die ich häufig entdecke.
Wenn ich in Kursen habe so, ja, aber ich will doch gar nicht so schnell. Ja, musst du ja auch nicht. Aber du kannst.
Und eben, das ist ja der Unterschied, wenn ich sage, ich will nicht, dann richte ich meine Organisation nicht darauf aus.
Wenn ich aber sage, ich möchte im Fall der Fälle schnell reagieren, dann habe ich ja die, also kann das erstmal mein Business,
denke ich, sehr viel besser verkaufen und schaffe damit quasi eine immanente Qualität in meiner Organisation und kann dann im Fall der Fälle eben entsprechend schnell reagieren.
Genau.
Jetzt sind wir wieder bei dem Punkt Vertrauen, weil ich ein höheres Vertrauen gewährleisten kann in mein Produkt.
Ja, richtig.
Selbst wenn die Organisation jetzt irgendwie Mist gemacht hat, die IT-Organisation, dann kann sie auf der Stelle diese Scharte wieder auswetzen.
Ja, richtig. Ja, so schließt sich der Kreis. Aber wir sind ja noch nicht am Ende. Wir haben ja noch ein paar Themen, die wir besprechen können.
Und was ich noch interessant finde, ist, dass du gesagt hast, dass nach wie vor auch Testen noch menschliche Arbeit ist.
Wenn man das Thema Automation sozusagen vielleicht falsch zu Ende denkt, dann würde das ja heißen, ich muss alle Tests automatisieren.
Dann hätte ich keine Menschen mehr. Du hast ja gesagt, ich brauche natürlich auf der einen Seite immer Menschen, die die Testautomation betreuen und betreiben.
Gibt es noch andere Fälle, wo wir sozusagen auch weiterhin menschliches Know-how brauchen im Testumfeld?
Wie gesagt, zum einen brauchen wir immer Leute, die die tatsächlichen Tests erzeugen, warten, umsetzen und so weiter.
Also für die eigentliche Testaktivität. Aber mehr als das, ein Testexperte oder ein Qualitätsexperte, der muss, wie gesagt, auch beratend zur Verfügung stehen.
Der spielt auf einmal in die Architektur mit hinein. Und er muss auch in die gesamte Organisation der Produktentwicklung mit hinein sprechen.
Denn der ist derjenige, der ein zentrales Interesse oder ein zentrales Verständnis hat von all diesen Rückkopplungsprozessen, die da stattfinden müssen.
Ganz kurzzyklische im Sinne von automatischen Unit-Tests oder sowas.
Die müssen mir im besten Fall bereits Sekunden, nachdem ich das fertiggestellt habe, eine Rückmeldung liefern.
Bis hin zu langzyklischeren Maßnahmen, die dann zum Beispiel mir Monitoring-Daten aus der Produktion zurückspielen.
Und das bedeutet, dass das nicht nur eine technische Arbeit ist, sondern es ist auch sehr stark eine Kommunikationsarbeit unter Menschen.
Und es ist sogar auch etwas Kulturelles. Es muss ja die gesamte Organisation sich überhaupt menschlich dazu in der Lage sehen,
mit so radikalem, so schnellem, so detailliertem Feedback umzugehen.
Ja, das ist richtig. Das ist vielleicht auch eine schöne Überleitung zu dem anderen Punkt, zu einer anderen Quelle.
Ich werde in den Shownotes auch nochmal einen Link posten. Es gibt, wie ich finde, eine ganz schöne Übersicht,
wo sieben Tipps dargestellt sind zum Thema Testen im DevOps-Umfeld oder sieben Hinweise.
Und einer dieser Hinweise ist nämlich genau, dass die Bedeutung der Soft-Skills zunimmt, auch für Tester oder in diesem Testumfeld.
Das ist ja genau das, was du auch sagst.
Ja, genau so ist es. Also zum Ersten brauchen Tester, glaube ich, schon immer gute Soft-Skills, weil jemandem mitteilen zu müssen,
dass seine Arbeit in irgendeiner Weise nicht gut genug war oder sowas, das ist halt nicht schön.
Dafür braucht man ein gewisses Feingefühl, kann man nicht dem anderen irgendwie feixen ins Gesicht sagen, was er da schon wieder für ein Mist verbockt hat.
Also kann man schon, aber das wird halt nicht gut gehen.
Aber es geht eben auch wirklich darum, Verständnis für all die Kommunikationsprozesse zu entwickeln, die da innerhalb eines Teams ablaufen und ablaufen müssen.
Bei diesen sieben Tipps, Soft-Skills, denke ich, das haben wir jetzt auch durchgängig behandelt.
Der erste Tipp ist auch Veränderung der Sichtweise, der Rolle des Testers, da haben wir auch, denke ich, ausführlich darüber gesprochen.
Der dritte Punkt ist, dass dort steht, dass Tester quasi, also wenn es die überhaupt noch gibt, logischerweise, aber in der Form, wie wir es jetzt in der modernen Form sehen,
dass Tester auch einfache Kenntnisse haben sollten über Entwicklung, also über Codieren. Wie stehst du dazu?
Ja, auf jeden Fall. Ich meine, ohnehin fordert DevOps ja, genauso wie das Agile auch, sogenannte T-Shaped Team Members,
also die sind dann T-förmig, nicht im körperlichen Sinne, aber im Sinne ihres Fähigkeitsprofils.
Sie haben eine tiefgehende Fähigkeit in einer bestimmten Sache und aber auch ein breites Verständnis links und rechts von dem, was sie so machen.
Und auf Tester trifft das in zweierlei Hinsicht zu, nämlich einerseits im Sinne von Testautomatisierung, die natürlich Programmierung darstellt.
Ein Testexperte muss verstehen, wie man automatische Tests schreibt, wie man sie klug schreibt, wie man sie richtig schreibt.
Da gibt es ja auch eine Menge Sachen, die man unklug angehen könnte.
Und zum anderen muss er aber auch Verständnis für Softwareentwickler und Softwareentwicklungsprozesse haben, weil er unmittelbar in sie eingreift mit diesem ganzen Feedback, das er bietet.
Auch eine vernünftige Forderung oder eine sinnvolle Forderung. Vielleicht so noch den letzten Punkt, den ich da rausgreifen würde, weil von diesen sieben Tipps haben wir eigentlich ziemlich viele schon im Vorbeiflug.
Behandelt und besprochen. Ein Punkt, den ich noch sehr interessant finde, ist, dass dort der Tipp gegeben wird, letzten Endes das Thema Berichtswesen oder Reporting nicht so sehr auf das Thema Testergebnisse auszurichten.
Das ist ja auch das, was du sagst, das ist falsch und das ist falsch und das ist falsch, sondern mehr auf das Thema, welchen Nutzen stifte ich denn mit meinen Tests, welchen Wert schaffe ich bei meinem Kunden, wenn ich Qualitätssicherung betreibe?
Ja, das stimmt. Das ist natürlich nicht allein.
Auf automatische Tests beschränkt, sondern das selbst in einem ganz klassischen manuellen Testumfeld stünde uns das auch gut zu Gesicht, darzustellen, nicht nur welche Fehler haben wir gefunden, sondern welchen Wert haben unsere ganzen Qualitätssicherungsmaßnahmen überhaupt erschaffen für die Organisation als Ganze?
Gerade in solchen Dingen wie Vertrauen, Verfügbarkeit und so weiter. Wahrscheinlich hat jeder schon mal diese Diagramme gesehen, wo da drin steht, ein Fehler, den ich während der Planung finde, der kostet einen Euro und ein Fehler, den ich während der Entwicklung finde, der kostet zehn Euro und ein Fehler, den ich erst in der Produktion finde, der kostet tausend Euro.
Wenn ich immer mehr von diesen Erkenntnissen immer weiter nach links schieben kann, dann kann ich auch ganz konkret auf Euro und Cent sagen, pass mal auf, liebe Organisation, unser ganzer Testaufwand, der hat dir wirklich eine Menge Asche gespart.
Ich war vergangene Woche auf einer Qualitätssicherungskonferenz, da hat jemand einen Vortrag darüber gehalten und hat uns das auch wirklich mal vorgerechnet und hat gesagt, pass mal auf, angenommen, wir testen gar nicht, dann in seinem Beispiel hat das irgendwie 800.000 Euro oder sowas gekostet an Kosten für Fehlerbehebung.
Mit dem Hut in der Hand beim Kunden auftauchen, was weiß ich was. Und dann hat er so systematisch angefangen, ja, wir könnten manuelle Tests einführen, wir könnten automatische Tests einführen, wir könnten Monitoring einführen und er war in der Lage, uns da einen Return on Investment vorzurechnen für im Extremfall, ich glaube, 700, 800 Prozent.
Also ich glaube, man darf nicht unterschätzen, wie zentral gute Qualitätssicherung ist für Softwareentwicklung im Allgemeinen und ganz besonders, wenn man, so wie DevOps das tut, auf Geschwindigkeit abzieht.
Weil dann kann man es sich einfach nicht leisten. Wenn ich aus vollem Lauf auf die Fresse fliege, dann tut es halt richtig weh.
Ich stelle mir das gerade vor. Ja klar, okay, natürlich. Wenn ich schnell bin, dann tut es wirklich weh. Das ist auch ein schönes Bild.
Ja, weil dann ist auch das Vertrauen weg. Dann ist dieser ganze schöne DevOps-Prozess, hat dann das Vertrauen verloren innerhalb der Firma, hat das Vertrauen verloren außerhalb der Firma.
Qualität muss man absolut ernst nehmen.
Man muss ein First-Class-Citizen sein, der die gesamte Softwareentwicklungskette von Anfang bis Ende, aber wenn man das hinkriegt, dann ist man halt wirklich rasend schnell.
Das war irgendwie ein ganz tolles Schlusswort. Ich stoppe jetzt mit all meinen Fragen, weil das war wirklich ein schönes Schlusswort. Wir sind ja auch schon bei der Zeit soweit fortgeschritten, das war eine vernünftige Länge.
Luca, ich danke dir. Das war wirklich für mich, also auch für mich nochmal, waren so ein paar Gedankengänge dabei, die neu waren für mich, die mich auch weitergebracht haben.
Und ich hoffe und denke, dass es auch dann den Hörern des Podcasts so geht. Also vielen Dank für deine lustigen und vor allen Dingen auch sinnvollen und gut begründeten Einschätzung zum Thema Testen im DevOps-Umfeld.
Ja, nochmal vielen Dank für die Anleitung, Dirk. Ich hoffe, euch Hörern hat es auch Spaß gemacht und euch auch ein paar neue Denkanstöße gegeben. Das ist einfach ein Thema, das mir wahnsinnig wichtig ist und ich freue mich immer, wenn ich Leuten dabei weiterhelfen kann.
Besser zu verstehen und klüger anzugehen.