Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Ritschi und habe wieder eine Folge vom German Testing Day 2024 mit dabei. Bei mir zu Gast Andreas Neumeister. Mit ihm spreche ich über das Thema Quality and Testing im Umfeld von SAFE. Wer mich kennt, weiß, dass ich nicht zu den allergrößten SAFE-Fans gehöre, aber es ist nun mal in vielen
Unternehmen im Einsatz und daher ist das Thema Qualität da auch sehr wichtig. Mit Andreas spreche ich darüber, wie er diverse Gaps bezüglich Qualität übergreifend in SAFE adressiert hat und welche Erfahrungen er in diesen Projekten gemacht hat. Viel Spaß bei der Folge. Hallo Andreas, schön, dass du da bist. Hallo Ritschi, ich freue mich dabei zu sein. Ja, ganz großartig. German Testing Day 2024 hier in Frankfurt. So der erste Tag gleitet langsam in den ersten Abend rein.
Hast du deinen Vortrag schon gehabt? Genau, meinen Vortrag durfte ich eben schon präsentieren und ich war natürlich, habe mich schon direkt geehrt gefühlt, als der German Testing Day eröffnet wurde mit der Aussage, wir haben ein bisschen Qualität in den Dienstagabend gebracht, damit das mit den Teilnehmern gut funktioniert. Ja, super, das ist ja schön. Dann hast du es auch schon, hast du auch schon warm gequatscht jetzt quasi, dann kannst du jetzt direkt in den Podcast mit rein.
Sehr fein. Ich habe, wie ich dein Abstract gelesen habe, bin ich so hängen geblieben bei dem Titel Quality Coaching, weil das auch etwas ist, was ich bei meinen Kunden mache und glaube ich total essentiell ist und finde ich hier auch mal den Raum haben darf, in dem Podcast auch noch mal präsenter zu sein. Und ja, da würde ich einfach mit rein starten. Was ist denn das Quality Coaching und warum
brauchen wir es und woher, was hast du da für einen Berührungspunkt damit? Ja, also steige ich gerne mit ein und zwar kommt es bei mir direkt aus einem Kundenumfeld, wo wir praktisch im Rahmen einer agilen Transformation hin auf SAFE entdeckt haben, dass es da einfach Qualitätssicherungslücken gibt
aufgrund der Fluglevel. Das heißt, grundsätzlich im agilen Arbeiten sagt man ja, die Qualität ist die Verantwortung des Entwicklungsteams und jeder im Entwicklungsteam ist für die Qualität verantwortlich und das funktioniert im Scrum einzeln ganz gut, solange man in seiner eigenen
Blase lebt. Jetzt sagt nun SAFE in dem Fall, dass es neben dem Entwicklungsteam praktisch als übergeordnete Ebene den agilen Release Training gibt und der verbindet die Arbeit unterschiedlicher Teams auf einen Release, auf ein System hin und das heißt, diese Entwicklungsprodukte der einzelnen Teams müssen zueinander passen und das muss getestet werden und genau dafür gibt es praktisch niemanden,
der das koordiniert, niemand, der das regelt. Und wenn man in eine Transformation geht, wo man aus Wasserfall kommt, also aus einem wasserfallartigen Entwicklungsvorgehen und dann sagt, ab jetzt arbeiten wir alle agil, dann ist man es absolut nicht gewöhnt, so zu arbeiten. Das heißt, man versteht vielleicht noch, dass ich sage, im Rahmen meiner Arbeit an einer Story teste ich diese und
sage dann im Review, die ist jetzt fertig. Aber dann geht es ja nur auf die nächste Höre, eben auf das Feature, was dann gemeinsam mit den Stories anderer Teams auf das System released werden muss und
funktionieren muss. Und hier diese Absprache der Teams untereinander auf dasselbe Feature, die funktionierte einfach nicht, die war nicht etabliert, die war nicht da, es war nicht mehr bekannt, dass das getan werden musste und das führte dazu, dass auf Entwicklungsebene Varianten unterschiedlich vergeben wurden oder dann eben in der Fachlichkeit Validierung unterschiedlich funktionierten, dann aber auf dasselbe System gehen sollten, halt einfach zu Widersprüchen führten und so wurde erkannt,
dass eben auf unterschiedlichen Flugebenen genau eine Rolle fehlt, die die Qualität koordiniert.
Und das wurde jetzt vom Unternehmen bezeichnet als Quality Coaching und das heißt, hier ist es tatsächlich auch ein recht konkreter Use Case auf genau dieses Gap in den unterschiedlichen Flugleveln und das heißt, diese Koordination von Entwicklungs- und Testaktivitäten, die eigentlich auf Entwicklungsteamebene stattfinden, über das Storylevel hinaus, also sprich selbst, wenn eine bestimmte Entwicklung, eine Story fertig ist, ist der Tester verantwortlich dafür, dann auch zu
sagen, ich mache das bis in Produktion, diese Qualitätsverantwortung. Ich tue also meine Teilstrecke des Tests dann auch auf Feature-Ebene, auf Epic-Ebene bis in Produktion und dieses Verständnis, da muss man einfach wirklich hart für arbeiten, weil die Menschen sind, Menschen sind Gewohnheitstiere. Wenn ich jahrelang im Wasserfall gearbeitet habe,
dann bin ich gewohnt, einfach meins zu machen. In einem netten Testteam habe ich immer meine Testfälle abgearbeitet und das war schön, das war bequem, da habe ich mich so reingegroovt und plötzlich muss ich mit der Entwicklung reden, da ist was agil, ich weiß gar nicht, was jetzt als nächstes kommt, ich muss einen neuen Testfall schreiben, auf den ich gar nicht vorbereitet bin, da muss ich den auch noch testen und da muss ich im Review am besten auch noch
irgendwas zeigen, damit das dann Ganze dann abgenommen wird und dann ist man froh, dass man das irgendwie geschafft hat und plötzlich kommt dann das Produkt und sagt, also auf meiner Ebene funktioniert nicht, was du da unten für dich gemacht hast und die Leute verstehen das dann auch nicht, die sind dann auch in einem gewissen Maße überfordert, weil sie einfach nicht wissen, was muss ich jetzt tun, damit das funktioniert und das geht schon damit los, dass man sich fragen
muss, wenn man jetzt zehn Entwicklungsteams in einem Agile Release Train hat, wer stellt die Testumgebung, auf der alle zehn Teams testen, weil grundsätzlich sagt jedes Team erst mal, also ich bin dafür nicht verantwortlich, nur für meine Tests, wer macht das und solche Fragen wurden einfach nicht berücksichtigt und genau so haben wir das vom Prinzip her etabliert und sind dann so ein bisschen in diese Rolle des Quality Coachings eben in genau diesem Use Case reingewachsen.
Ja und wie habt ihr das dann gemacht, genau diese Fragen zu beantworten, also der Entwickler sitzt da und sagt, bei mir läuft es in unserem Team, wir sind fine, so no hands und dann, also wie habt ihr die jetzt auf die Reise mitgenommen und was habt ihr da eingezogen für
Aktivitäten? Also grundsätzlich geht erst mal alles mit einer Form der Analyse los, das heißt, ich muss verstehen, wie arbeiten die eigentlich und wieso kommt es auf Produktlevel dann zu Fehlern zu bestimmten und das muss ich nachvollziehen können und dann muss ich gucken, sind das Fehler, die zum Beispiel am methodischen liegen oder sind das Fehler, die einfach am kommunikativen liegen, das A nicht mit B spricht, sind das vielleicht auch architektonische Fehler, dass eben schon
vorher einfach Dinge falsch geplant wurden, weil eben der ganze Umfang nicht bekannt war und das heißt, hier sind wir erst mal mehr oder weniger ein bisschen im Freiflug umhergelaufen und haben
geguckt. Wir haben aber auch einen Fragebogen entwickelt, einfach um ein strukturiertes Interview zu führen und haben das dann wirklich mit den ganzen unterschiedlichen Rollen auf allen Ebenen geführt, das heißt mit den Testern in den Entwicklungsteams, aber auch mit Scrum Mastern, Product Ownern, damit Product Manager, Re-Strain Engineers auf den höheren Leveln, um einfach rauszukriegen, wie verstehen sie ihre Verantwortung, wie verstehen sie ihren Einfluss, ihre Tätigkeit
im Hinblick auf das Gesamtprodukt und das war letztendlich ein bisschen augenöffnend, weil das auch gezeigt hat, dass auf der Entwicklungsteam-Ebene teilweise das Produkt völlig unbekannt war, das heißt, die wussten, ich habe hier eine Story und die habe ich vom Product Owner so gekriegt und da heißt, ich passe meine Schnittstelle um ein bestimmtes Attribut an und dann mache ich das halt, aber was eigentlich über die Schnittstelle übertragen wird und wie das im Gesamtkontext
eines Geschäftsprozesses involviert ist, war überhaupt nicht bekannt und das teilweise sogar auf Agile Release Train-Ebene, was eben dazu führt, dass es auch nicht besser vorgegeben werden kann und das heißt, wir haben dann mit diesem Wissen, was wir hatten, haben wir unterschiedliche Workshops, Coachings und so weiter durchgeführt und das beginnend von der obersten Ebene, also wirklich nach Safe auf der Solution-Ebene, haben wir gecoacht, wie muss eigentlich eine Anforderung
formuliert sein, damit sie verstanden wird, wie geht das auf den Release Train runter, das heißt, wie kann dann der Produktmanager abnehmen, was einem der Solution Manager gibt, kann das auch splitten in Features, wie weiß ich, welche Teams für welches Feature verantwortlich sind, wie bringe ich die zusammen und wie schaffe ich es, dass der Entwickler auf Arbeitsebene und der Tester versteht, was die Story sagt und das ist was, da haben wir ganze Workshops zugeführt und haben
auch so ein Prinzip, sage ich mal, versucht, was heißt, wenn zum Beispiel ein Epic, ein Feature oder eine Story innerhalb von zehn Minuten nicht so erklärt werden kann, dass man in fünf Minuten danach alle kritischen Fragen klärt, dann geht das Ganze zurück, weil es einfach noch nicht so weit ist, dass überhaupt jemand was damit anfangen kann und wir hatten andere Workshops, wo es darum ging, zu sagen, wir nehmen das gesamte Produkt mit allen Geschäftsprozessen und lassen jetzt die Tester
aus jedem Entwicklungsteam, die da mitmachen, diese ganzen Geschäftsprozesse mal durchlaufen und zwar in einer Simulation, in einem Raum mit Papier an der Wand, wo es dann wirklich heißt, ich bin ein ID-Generator, ich erstelle jetzt eine ID und dann kommt der Nächste und sagt, ist ja super, ich brauche eine ID, ich suche jetzt mal Daten, die zu der ID gehören, geh mal in meine Datenbank und dann kommt die Datenbank von denen und sagt, hier sind die Daten,
die du gefragt hast und so haben wir die ganzen Prozesse durchlaufen, was dazu führte, dass auch auf der Entwicklungsteam-Ebene die Leute einfach wussten, mit wem arbeite ich zusammen, was tue ich, was tut der vor mir, was tut der hinter mir, was genau braucht er, damit er arbeiten kann und was ist eigentlich der gesamte Prozess, an dem wir arbeiten und
was ist der Mehrwert für das Unternehmen. Also sowas ist dann augenöffnend, weil das dann einfach wirklich ein eigenes Verständnis, eine Identität im Gesamtkonstrukt schafft und dann auch dazu führt, dass man dann eben in der Entwicklung und im Test auch mal nach rechts und links guckt und zum Beispiel auch mal einen gemeinsamen Test über mehrere Entwicklungsteams macht und sagt, ich möchte jetzt hier tasten, dass das mit der ID und den Daten funktioniert, dafür brauche ich
euch drei, wir machen jetzt hier einen Termin und dann schicke ich euch die ID und ihr macht den Rest. Das ist total spannend, weil das trifft ja nicht nur das Safe-Umfeld, das klassische Konzernwesen, wenn man noch traditionell arbeitet, jedes Projekt arbeitet so vor sich hin, dann schmeißt man das auf irgendeine Integrationsumgebung und dann wundern sich alle, warum nichts geht und da nehme ich das ja auch immer wieder wahr, dass Teams zum Teil gar nicht wissen, wofür sie die
Dinge eigentlich tun. Also das ist zwar schön, dass man da für sich auch fein ist und das dann vielleicht auch getestet hat, aber einfach gar nicht weiß, in welchem großen Bild sich das alles einbettet. Also ich glaube, die Idee kann man auch noch schön transferieren. Das ist ja eigentlich, das finde ich ganz spannend, weil du nennst das Quality Coaching, aber das ist ja einfach nur die Leute zusammenzubringen und ein Verstehen zu geben, was eigentlich passiert.
Das ist definitiv ein Komplex davon. Auch das Quality ist, manchmal ist es auch Kommunikationscoaching und alles. Also man hat alle Aspekte dabei, die dazu führen, dass in Summe eine gute Qualität rauskommt. Es ist auch Coaching, was jetzt Anforderungen angeht, wie müssen Anforderungen formuliert sein, wie könnte eine Definition of Done, eine Definition
of Ready aussehen. Also all diese Dinge, die im Agilen vorausgesetzt sind und eigentlich steuern können, wie die Qualität ist, die sind halt in einem Unternehmen, was sich spontan mehr oder weniger dazu entscheidet, safe zu machen, ohne das wirklich in dem Maße sauber zu durchdenken,
essenziell wichtig, dass die überhaupt etabliert werden, weil die sind ja nicht da einfach. Man kann auch ein Entwicklungsteam, was nur bedingt überhaupt weiß, wie safe funktioniert, nicht da hinsetzen und sagen, schreib du das mal, du weißt das schon, weil da kommen dann Dinge raus, die im Endeffekt die Qualität nicht steigern würden, sondern dann hat man Arbeitsergebnisse
um der Ergebnisse willen, nicht um der Qualität der Ergebnisse willen. Du hast vorher noch eine schöne Sache gesagt, nämlich die mir auch immer wieder begegnet in Unternehmen und du hast gesagt, auch wenn man das dann so nach oben gespielt ist, wer ist denn dafür überhaupt für die Testumgebung verantwortlich? Und das ist ja auch etwas, was man häufig auch bei Systemintegrationstests sieht, meins ist fertig, deins ist fertig, wer kümmert sich denn jetzt, ob das überhaupt
zusammen funktioniert? Da fehlt eine Verantwortlichkeit oder so was. Wie habt ihr denn das gelöst? Wie seid ihr denn das rangegangen? Grundsätzlich war, wie gesagt, das Wichtigste erstmal überhaupt, das Erkennen, dass irgendwo was fehlt und dann sind wir einfach recht nett die agilen Verantwortlichkeiten durchgegangen und haben dann den Systemarchitekten identifiziert und dem dazu verholfen, dass das sein Thema wurde. Und natürlich... Das ist halt diplomatisch
ausgedrückt. Wie die Reaktion von Menschen ist, ist erstmal dieses Klassische, nee, das möchte ich nicht. Und dann hat sich ganz schnell so eine Verselbstständigung etabliert, wo man einfach mal geguckt hat, wer ist denn auf Team-Ebene für die Testumgebung verantwortlich, wer hat die bisher
umfangreichste Testumgebung mit Anbindung an die möglichst meisten anderen Services und Teams. Und dann wurde einfach gesagt, naja, ihr habt doch eh schon so viel, dann seid ihr jetzt federführend dafür verantwortlich auf Entwicklungsteam-Ebene, wo die Verantwortung ja am Ende auch liegen muss. Und die anderen sind eben für eine Zulieferung verantwortlich. Und dann wurde definiert, was eben, ich sag mal, der eigentliche Owner der Umgebung machen muss, was für Zulieferungen
notwendig sind. Und daraus hat sich dann ein Konstrukt ergeben, was anfangs nicht so gut funktionierte, weil natürlich jeder bei den Grenzen seiner Verantwortlichkeit noch auch alles fallen gelassen hat. Und wenn das nicht ganz durchdefiniert war, hat nicht direkt alles zueinander gepasst. Aber da sind wir dann wieder dem agilen Modell folgend auf dem Systemarchitekt zugegangen, haben gesagt, naja, aber jetzt hier, du bist doch für das Gesamtsystem. Du musst doch sehen,
wo da was nicht passt. Mach mal. Und auch da hat er wieder probiert, loszuwerden, es aber nicht geschafft. Das heißt, da musste er sich dann wirklich hinsetzen mit allen
Schlittstellenpartnern, gucken, dass das angepasst wird, zusammenpasst. Und das ist immer nicht so einfach, sag ich mal, in dem Umfeld, wo ich jetzt unterwegs bin, weil die Umgebung eben aus, ich sag mal, sehr neumodischen Microservices gebaut ist, aber eben auch Legacy-Monolithen angebunden hat, die praktisch schon vor der Menschheit existierten. Und dann hat man natürlich auch unterschiedliche Release-Zyklen von Legacy und der neumodischen
agilen Welt und so weiter. Also es ist nicht immer so, als ist alles ganz unkompliziert, aber wir haben zumindest geschafft, eine Umgebung zu bekommen, auf der alle gemeinsam testen können. Und das alleine ist ja schon von man hat nichts zu einer Umgebung, wo das erstmal läuft, ein großer Schritt. Es geht mit Sicherheit besser. Also ich glaube, das ist ein Arbeitsstand, den wir jetzt haben. Und das Zielbild ist natürlich, dass, ich sag mal, auch die Leute
proaktiv erkennen, wenn sich an der Umgebung was ändert. Das heißt, wenn Service jetzt eine neue Version releast, dass das automatisch auf die Umgebung gespielt wird, dass da auch der Service selber proaktiv sagt, hier, ich habe da was Neues, das muss da hin. Und nicht immer alles in der Hohle
schuld ist und man gucken muss, was passt wie wohl zusammen. Also manchmal ist es wirklich so, dass die Release-Notes durchgegangen werden, dann gesagt wird, du hast doch hier was Neues, das muss doch auf die Testumgebung, das muss doch hier drauf gespielt werden, damit das da ist. Und dann sagen sie, ja stimmt, da hast du recht. Ja, noch sehr, ich würde sagen, sehr aufwendig aktuell, aber immerhin funktional. Ja, ja, ja, ist im Endeffekt dann immer wieder auch das Thema
Kommunikation. Wenn du, wenn da jetzt in diesen, ich weiß nicht, auf diesen abstrakteren Ebenen oder auf den höheren Ebenen, auf diesen gemeinsamen dort Fehler gefunden sind, wie habt ihr denn da diese Fehleranalyse adressiert? Weil das ist ja, also irgendwer muss sich das ja zum einen anschauen. Jetzt sagen vielleicht die Teams, könnte ich mir vorstellen, ich habe jetzt damit keine Zeit, ich muss hier gerade meinen Sprint fertig machen oder was weiß
ich. Irgendwer, wie habt ihr das gelöst? Und zum anderen auch quasi, das dauert ja dann ein bisschen und dann kommt irgendwie ein Fehler raus, der muss ja dann auch wieder irgendwo in diesen Prozess mit rein. Ja, also Fehlermanagement ist auch sehr schön, weil grundsätzlich ja immer erst mal sich keiner dafür verantwortlich fühlt. Wenn es in so einem übergreifenden Raum passiert,
dann war keines und keiner möchte es auch gewesen sein. Das heißt, hier funktioniert es auch nicht von selbst, also als Selbstverständnis, dass geguckt wurde, wo kommt es vielleicht her gemeinsam, sondern da haben wir einen Fehlerkoordinator definiert, in dem Fall dann eben für Natural Least Training oder eine Solution, der einfach erst mal sagt, ich nehme die alle. Und dann fängt er an und sagt, ich gucke jetzt mal, in welchen dieser Bereiche fällt dieser Fehler überhaupt
rein, dann rede ich mit dem Verantwortlichen davon. Und wenn das richtig ist, dann nimmt der Verantwortliche davon den Fehler mit und guckt dann das richtige Entwicklungsteam raus. Das heißt, innerhalb einer Solution werden praktisch die Fehler erst mal gesammelt und dann koordiniert wieder auf Arbeitsebene verteilt. Und wenn es dann eben mehrere Teams betrifft, dann haben wir bisher auch noch ein bisschen Wildwuchs drin. Das heißt, da gibt es einmal
die Möglichkeit, dass der Defekt nacheinander weiter assigned wird. Es gibt aber auch die Möglichkeit, dass ein Defekt dann entweder Tasks bekommt zum Bug, wo dann einfach jeder einen eigenen Task hat, an dem er arbeitet, oder wo der Defekt geklont wird und dann dahinter das Team geschrieben wird. Hier endet so ein bisschen die Verantwortung des Quality Coaches, weil wir ja sagen, wir möchten nicht in die agile Arbeitsweise eingreifen. Weil das ist einfach schädlich für die agile
Arbeitsweise und das die Teams selbst selber koordinieren. Wir haben ihnen gesagt, dass es sinnvoll wäre, einen einheitlichen Prozess zu definieren, bei dem es ein einheitliches Vorgehen gibt, weil ansonsten rutscht einem vielleicht mal was durch. Und das wurde auch in Retros mitgenommen, wurde aber letztendlich von den Teams erst mal gesagt, ihnen rutscht
nichts durch. Also das war nah dran an Entwickler, die sagen, wir machen keine Fehler. Und solange wir aber auch nichts finden, was durchgerutscht ist, können wir jetzt nur sagen, na gut, dann ist das super. Und so läuft es halt.
Ja, das finde ich total interessant, weil es ist, ich meine, immer wenn ich safe höre oder sowas, dann denke ich mir immer, das hat eigentlich eh nichts mit Agilität mehr zu tun, weil man einfach schon in so einem Wildwuchs da so groß ist in dem Ganzen, wo man sagt, okay, aber sich trotzdem diese Gedanken zu machen, wie kriegt man diese Dinge, trotzdem
müssen die Sachen ja gemacht werden irgendwo. Ich kann ja nicht alles zerschlagen und sagen, okay, ich habe jetzt hier nur nette kleine Startups, die alle miteinander, ich muss ja dieses Ding Wumms da irgendwie zusammenbringen und sich da Gedanken zu machen, wie kann ich denn das zusammenführen mit einer guten Qualität. Das ist, finde ich, ein wichtiger Ansatz,
also da auch über diese Rolle reinzugehen. Wenn du jetzt heute so drauf schaust, was sind denn noch so aktuelle Herausforderungen, wo du sagst, da eckt es gerade, da können wir noch besser werden? Es geht mit den Anforderungen los, wo man einfach sagen muss, diese Anforderungen sind, selbst wenn sie auf höherem Level passieren, also Epic oder Features zum Beispiel, sind nicht mit allen Teams abgestimmt, das heißt, da fehlen dann manchmal Details und da geht
die Problemkette los, die man hat. Also zu zusammenfassen, die größeren Fehler sehe ich erstmal auf übergreifender Ebene, sowohl beim Test, wie auch bei Anforderungen, wie auch bei Entwicklung, weil das ist nicht nur die Kommunikation, das ist auch einfach eben bei den Anforderungen zum Beispiel, dass sie einfach in zu kurzer Zeit zu viele Anforderungen erstellen müssen, dadurch nicht die Zeit haben, mit denen ins Gespräch zu gehen, beziehungsweise
auch einfach möglicherweise zu große Epics oder Features schneiden, dass sie nicht mehr überblickbar sind. Und das zieht sich dann letztendlich über jede Stufe einzeln durch. Wenn ich dann im Test zum Beispiel gucke, dann funktioniert es auf Team-Ebene super. Komponententest, Integrationstest, alles eigentlich kein Thema. Aber wenn ich sage, ich gehe dann so auf eine Ende-zu-Ende-Testkette, dann habe ich häufig noch ein technisches Verständnis
dessen, was die Anwendung tut, aber fachlich eigentlich gar nicht mehr. Und das führt dann in Summe dazu, dass ich zwar technisch in der Lage bin, alle möglichen Kombinationen einer Schnittstelle durchzutesten, aber möglicherweise für meine Validierung gar nicht weiß, darf das überhaupt so durchgehen oder nicht, weil ich die Fachlichkeit nicht mehr so im Blick habe beziehungsweise kenne. Und das heißt, der Fokus liegt sehr auf dem, was ich greifen
kann für alle Personen. Und ich glaube, jeder versucht hier nur sein Bestes zu machen, aber die Leute sehen eben nur, was in der Story steht. Und wenn da nicht vom Gesamtgeschäftsprozess drinsteht, dass bestimmte Dinge nicht funktionieren dürfen, dann wissen die das nicht und dann testen die das und dann ist das okay. Und zu dem, was sie testen, was okay sein sollte oder auch ist, also auch der Positivtestfall, so ein Happy Path ist ja auch super, wenn
der getestet wird. Negativtestfälle und Edge Cases, da sind wir noch gar nicht angekommen, weil wenn die Fachlichkeit nur bedingt bekannt ist, weiß ich ja gar nicht, was ich da testen müsste. Und das heißt, was Error Messages angeht, also wirklich im Stile von einem 404
zum Beispiel mit dem Text, da braucht man glaube ich noch nicht so viele anfangen. Wir sind jetzt erst mal dabei, dass wir es schaffen, überhaupt übergreifend die Funktionalität so gut zu testen, bis wir dann dahin kommen, dass die Fachlichkeit wirklich auch mit dabei
ist. Da fehlt glaube ich noch sehr viel, also auch Wissen auf jeder Ebene, selbst auf Solution-Ebene fehlt da teilweise fachliches Wissen, aber es fehlt auch absolut ein effizienter Kanal, wie ich es schaffe, fachliches Wissen von der Solution-Ebene über eine Artual Release
Train in ein Entwicklungsteam reinzubringen. Und zwar so, dass es für alle interessant ist, weil letztendlich muss man sagen, wenn ich als Solution-Manager, also der verantwortliche Anforderungsmanager auf Solution-Ebene zu von mir aus 20, 25 Entwicklungsteams spreche, dann wird auch nur je nachdem, was ich gerade berede, dass für eine Teilmenge der Teams
interessant sein. Und dann auch hinzukriegen, dass die Teams nicht abschalten. Das ist schwierig und gleichzeitig nur zielgerichtet zu den einzelnen Teams zu sprechen, ist schwierig, weil die Prozesse ja übergreifend sind und gleichzeitig der Solution-Manager einfach keine Zeit hat, 25 Mal das Gleiche zu erzählen im Zweifel. Das sind große Probleme, sage ich mal, die noch vor der Brust liegen. Es ist genauso, aber auch das Thema Effizienz
einfach. Man plant ja Dinge und gerade nach so einer Transformation werden Releases geplant auf Zieltermine. Und das im Wasserfall, was recht, ich will jetzt nicht sagen, einfach ist, aber da hat man besser auf Zieltermine geplant als im Agile. Die Zieltermine wurden ins Agile einfach übernommen und damit wurde gesagt, mit unklarem Scope, weil es ja agil,
sind wir trotzdem dann fertig. Und das ist natürlich auch eine völlig absurde Nummer, weil dann letztendlich auch wirklich an der Funktionalität so viel rumgeschraubt wird und verändert wird, bis das dann eben zum Zieltermin passt. Man hat dann zwar nicht
mehr die Anwendung, die man wollte, aber man erreicht seinen Zieltermin. Und das ist natürlich Gift für die Qualität einfach, wenn permanent Funktionalität rausgenommen wird, reingenommen wird, gesagt wird, priorisieren wir anders, macht mal mehr Funktionalität und weniger Tests, solche Sachen. Also einfach dieser, noch aus Wasserfall, diese Altlasten, die man mitnimmt, die sind natürlich für die Arbeitsweise in der Qualitätssicherung einfach
wirklich sehr unglücklich. Ja, dass ich das, das ist ein Leid, was quasi auch viele große Häuser auch haben, dass sie einfach dann viel mitnehmen und da diesen radikalen Schnitt auch nicht schaffen und man sich manchmal auch wirklich fragt, wie agil ist das gerade eigentlich, was wir da jetzt hier gerade machen. 2029, German Testing Day, wir werden hier stehen und sagen, ach Mensch Andreas, kannst dich erinnern, vor fünf Jahren hat man hier diese Folge, was war denn dein größtes Highlight
in den letzten fünf Jahren, was ist denn da noch entstanden? Hast du da so eine Vision oder denkst? Jetzt so im Hinblick auf Quality Coaching? Ja. Also ich würde mich freuen, wenn wir hier in fünf Jahren wieder sprechen könnten und sagen könnten, der agile Gedanke, die Qualitätsverantwortung liegt beim Entwicklungsteam und jeder nimmt diese Verantwortung an und setzt diese um
und weiß auch, wie das geht. Also wenn ich da in einem bestimmten Umfeld jetzt nur, also fünf Jahre von mir aus beim gleichen Kunden, in derselben Aufgabe, wenn ich da hinkomme, das wäre aus meiner Sicht ein absoluter Traum. Dann wäre ich zwar nutzlos, was als Berater immer ein bisschen schwierig ist, aber zumindest. Aber ein schönes Ziel für einen Berater, ist es nicht nur, sich obsolet zu machen und zum nächsten Kunden zu gehen, oder?
Damit könnte ich leben. Aber einfach dieses Qualitätsverständnis, was ich so oft vermisse in den unterschiedlichsten Rollen. Mir geht es nicht mal nur um den Software-Tester, also den Tester selber, sondern auch den Requirements-Engineer oder den Entwickler. Einfach, dass man dieses gemeinsame Qualitätsverständnis hat, die gemeinsamen Qualitätsziele und jeder einfach
weiß, wie er darauf einwirkt und das tut. Das wäre, also wenn wir hier stehen könnten und uns darüber unterhalten könnten, dass das hingekriegt wurde, hätte ich gesagt, das wäre ziemlich stark. Ja, gut. Wir werden das überprüfen in fünf Jahren, im Mai wahrscheinlich. Werden wir dann schauen, ob das geklappt hat. Super. Ich bin gespannt. Andreas, vielen lieben Dank hier für deine Einsichten. Die erste Folge mit Safe, schauen wir mal, wie wir da ein bisschen weiter tun.
Das ist für mich auch ein schwieriges Thema, muss ich sagen. Aber ich finde es toll, dass du auch da den Ansatz, die Qualitätsfahne hochhältst, in diesen sehr komplexen organisatorischen Umfeldern auch. Das finde ich eine wichtige Sache. Ja, super, dass du hier warst. Ich wünsche dir noch viel Spaß auf der Konferenz heute und morgen und bis bald. Dann ganz vielen Dank und dir auch weiterhin viel Erfolg, viel Spaß und vor allen Dingen gute Gespräche. Danke schön. Okay. Tschüss. [Musik]