Hallo und herzlich willkommen zu einer neuen Folge von Podcast Software Testing. Heute wieder mit einer Folge von der OOP 2024 aus München. Bei mir zu Gast war gerade Katrin Pottser, die einen spannenden Begriff geprägt hat, nämlich Minimum Viable Teststrategie, also angelegt an das bekannte MVP. Wie kann ich eine Teststrategie leichtgewichtig aufbauen,
dass sie schnell Nutzen bringt? Sie erzählt uns von ihren Erfahrungen mit Eventstorming und Teststrategie Storming und wie man so etwas in Workshop-Charakter einfach starten kann. Viel Spaß bei der Folge. Hallo Katrin, schön, dass du da bist. Danke, hallo Richi. Freut mich, dass wir hier zusammenkommen auf der OOP. Hier meine erste große OOP. War noch nie da, also im Sommer letztes Jahr war das ja schon. Das war nur so eine kleine, habe ich gehört,
das erste Mal in dem Rahmen. Ich habe also die Speakerliste vorher durchgesehen und dann ist mir dann abstrakt aufgefallen, so das Thema Teststrategie und da mal so ein bisschen einen anderen Ansatz da ran zu gehen. Ich kenne ja Teststrategie so aus, ja das ist immer so, da setzt man sich dann zusammen und dann wird da so ein bisschen was zusammengeschrieben und so. Und nachher liest es keiner.
Und dann liest es keiner, genau. Aber was hast denn du da für einen Ansatz oder was hast du da für Erfahrungen? Ja, tatsächlich, also ich kenne natürlich aus der Erfahrung kenne ich auch genau das, was du kennst, also eher aus klassischen Projekten, wo sich ein, zwei Leute lange hinsetzen und Teststrategien schreiben. Aber da ist meine Erfahrung immer, da haben sich ganz
tolle Ideen gemacht und nachher liest es dann keiner. Und das, was ich hier erzählt habe, ist tatsächlich ein Erfahrungsbericht aus einem Projekt, wo ich selbst gar nicht drin war, sondern eher als Beraterin und ich sollte eigentlich Schulungen da machen. Also ein Kollege hatte mich angesprochen, sagte ja, wir haben hier ein Riesenprogramm, die neue Entwicklung soll moderner, agil, Microservice, Cloud-Technologien sein. Du
machst da auch Schulungen in der Richtung, kann man da nicht was übernehmen? Und da habe ich gesagt, klar, können wir machen, lass uns mal einen Termin machen. Ich frage mal dann so ein bisschen, wie ihr testen wollt und dann gucken wir mal, was wir übernehmen können. Und es hat sich halt herausgestellt, für die neue Welt wussten sie noch gar nicht, wie sie testen wollten. Also die alte Welt kannten sie, hatten auch schon ganz viele Applikationen, hatten auch eine klassische
Teststrategie, die irgendwie Jahre gebraucht hat, um sie abzustimmen. Sondern jetzt stand man da, sagt ja, Pilotprojekte sollen starten und wir wissen auch gar nicht, was wir machen sollen. Also wie kommen wir denn jetzt zu einer Teststrategie? Und mein Ansatz war erstmal,
wir brauchen ja gar nicht diese klassische Teststrategie. Was wir brauchen, ist ein gemeinsames Verständnis, was wir machen wollen, vor allem womit die Team starten können und dann ein Backlog, was wir abarbeiten können, in welche Richtung wir uns dann weiterentwickeln wollen.
Und ich habe mal gelesen, dass das Eventstorming so erfunden wurde, dass der Alberto Brandolini eigentlich zu einem Zeitpunkt keine Zeit hatte, das standardmäßige UML-Diagramm zu machen und deswegen gesagt hat, ja, dann lasst uns doch so einen kollaborativen Workshop machen, mit ein bisschen Post-its kleben. Und genau das haben wir dann da auch gemacht. Natürlich nicht genau wie Eventstorming, aber die Idee war schon zu sagen, komm, wir treffen uns, wir machen das
kollaborativ und sehr leichtgewichtig und legen uns da mal so eine Testlangenkarte fest. Und das war so der Bestandteil. Das kannte ich so ein bisschen aus Erfahrung, was ich häufiger schon mit Projekten gemacht hatte. Einfach so eine Tabelle aus Teststufen und Testarten und dann als Zettel sowas wie Rollen, also verantwortliche Rollen, Tools, Umgebung, Metriken. So und das heißt, darüber haben wir dann in drei Workshops hintereinander so eine Landkarte fürs Testen gehabt.
Ganz wichtiger Punkt fehlte natürlich noch offene Punkte, weil du kannst natürlich nicht an einem Tag oder in mehreren Stunden kannst du nicht eine komplette Teststrategie aufstellen, aber du kannst zumindest feststellen, wo hapert es denn. Also was müssen wir denn dringend noch klären. Genau,
das war so das, was ich da präsentiert habe. Und was ich auch, wenn ich es wieder machen würde, also wenn ich wieder eine Teststrategie erstellen würde und es wäre ein Kontext, der einigermaßen agil, offen ist, würde ich es auch immer wieder so machen. Ja, ja. Gehen wir da vielleicht noch ein bisschen rein in dieses Workshop-Format oder auch in die Vorbereitung dessen. Also du hast ja quasi die Elemente rausgenommen und auf Post-its
gepackt und wie habt ihr dann damit gearbeitet? Nee, wir haben tatsächlich, also ich kannte es ja zum Glück gar nicht. Ich war ja gar nicht in diesem Programm drin. Ich habe zwar Erfahrungen aus anderen Projekten, die mit ähnlichen, wie soll man sagen, ähnlichen Architekturansätzen und so testen wollen, aber ich kannte das ja gar nicht. Das heißt, ich habe keine Post-its vorbereitet. Ich hatte also nur eine leere Tabelle. Und wir haben erst mal angefangen zu sagen,
komm, welche Teststufen brauchen wir? Und das war okay. Der erste No-Brainer ist Unit-Testing. So, und dann fing es aber auch schon an, spannender zu werden, weil es war ja jetzt Microservices. Also nächste Teststufe muss Microservice sein, weil es sind Deployment-Units und die müssen getestet werden. Die Leute, die so ein bisschen aus der alten Denkweise kamen, kamen ja aber im Moment eher Applikationen sein. Und dann ging es halt weiter und sozusagen,
ja, nee, wir brauchen natürlich auch diese Produktsicht. Also ein Produkt kann ja auch aus mehreren Microservices zusammengesetzt sein. Also haben wir als nächste Ebene dann auch so einen Produkttest, wo auch dann wieder viele Diskussionen kamen. Was ist denn jetzt überhaupt ein Service? Was ist denn jetzt ein Produkt? Aber wertvolle Diskussionen darüber, weil es wirklich
sehr wichtig ist, dass da ein gemeinsames Verständnis für da ist. Es geht gar nicht so um Definitionen oder so, wo du dann die Grenze von einem Produkt zum anderen machst, ist gar nicht das Relevante oder so dabei. Aber zu sehen, also ganz klar, Microservice ist eine Deployment-Einheit, muss deswegen natürlich abgesichert sein als solches. Und so eher fachliche Sachen macht man dann vielleicht auf Produktebene. Dann hat man natürlich noch Integration mit Umsystemen. Und
dann hatte man in der Welt auch noch die ganze Legacy-Welt. Also die Umsysteme, die zu den Programmen gehören, die irgendwie zweimal im Jahr deployed werden. Und das hat auch, also dieses Workshop-Format hat das halt sehr sichtbar gemacht, dass man die neue Welt hatte und dahinter noch die alte Welt obendrauf. Und wir konnten das natürlich auch nicht auflösen in so einem kleinen Workshop. Aber es hat sehr viel dazu beigetragen, dass erstmal auf beiden Seiten so neue Welt und alte Welt
dieses Verständnis da ist. Und man sagt, nee, das passt nicht so gut zusammen. Wir können so starten, dass wir erstmal so bleiben mit diesen alten Welt-Teststufen noch dahinter. Aber es war auch allen klar, das muss angepasst werden auf die Dauer. Und das war eben ganz gut daran, dass man es so visualisiert hat. Also das ist, finde ich, ein total wichtiger Punkt. Also die Teststufen, das ist ja, die kommen ja auch, die gibt es schon so lange. Und das ist ein guter Richtwert. Dann
gab es irgendwann mal diese Testpyramide, da fehlte dann irgendwie was. Dann war da auf einmal Gummi und Schnittstellen. Und ich glaube, die Idee dahinter, und das habt ihr dann ja ganz toll gemacht, sich zu überlegen, was brauche ich denn eigentlich und was heißt das eigentlich jetzt im Kontext Microservices? Was heißt das im Kontext von meinem Produkt? Wo ist denn diese Ebene? Wo findet sich's wieder und wie benenne ich die dann auch? Also das ist, glaube ich, ein total wichtiger
Schritt, dass man das ja auch anpassen darf. Das muss jetzt nicht nur, weil es im Eis die Gummi oder sonst wo steht, so immer so sein. Also man kann das, muss das ja sogar irgendwo anpassen. Wir hatten da auch so eine Szene, dann ging es um Consumer-Driven-Contract-Tests, total super beim Microservices. Hatten die auch schon gehört. Und dann waren wir bei den Teststufen, dann wurde das auch genannt. Dann war ich mit meinem, ja doch auch geprägten Test, ist das nicht eher eine
Testart? Also ich würde es immer noch als Testart sehen. Das ist eigentlich so für Interoperabilität, insofern eine bestimmte Testart. Aber wenn die Kollegen alle glücklich damit sind, das als Teststufe zu haben, deswegen haben wir es dann auch als Teststufe gelassen. Also es geht ja gar nicht um diese formalen Sachen, sondern wirklich so ein gemeinsames Bild davon zu haben, was gemacht
werden muss. Ja, genau. Ja, und dann einfach auch so eine Entscheidung zu treffen für sich. Also ich habe, wir hatten ja eine der ersten Folge vom Podcast, da ging es auch um Contract-Based-Testing. Und da haben wir gesagt, Mario, das ist eher so bei Unitests eigentlich. Das ist eigentlich ein Unitest für die Schnittstelle. Ja, kann ich auch mitgehen. Also es ist, wo man es einsortiert,
man muss halt aber ein Bild drauf schaffen. Und das habt ihr dann da ja geschafft. Das Witzige ist, man kann diese Contract-Tests, man kann sie Unitest-mäßig machen, man kann sie theoretisch ja auch Systemtest-mäßig machen. Also man kann ja diese Voraussetzungen auch tatsächlich über die Datenbank herstellen. Macht man meistens nicht, das ist glaube ich auch nicht der beste Ansatz. Aber es sind so alles Überlegungen, die man tatsächlich auch haben kann und die man dadurch
ganz gut visualisieren kann. Jetzt habt ihr so die Teststufen, also allen Block bei den Testarten, habt ihr das quasi genauso gemacht? Genau, also Testarten war in dem Kontext so ein bisschen einfacher, weil das hat sich jetzt nicht so geändert. Also da gab es halt funktionale Tests, Last und Performance, Security, Usability und Betreibbarkeit. Das ist, würde ich sagen, so ein eher so ein klassischer Standardkanon. Man muss es halt immer so ein bisschen challengen
auch. Also noch so eine Frage, ist für euch Robustheit, ist das eine eigene Testart oder geht das bei Funktionalität mit auf? Das ist zum Beispiel mal so ein Punkt, den man mal diskutieren kann. Dann kann man diese ganzen Sachen über Wartbarkeit, Wartbarkeit der Software kann man auch noch mal als extra Testart machen oder man sagt halt hier, wir haben unsere SonaCube-Sachen, das fassen wir unter einem Unit-Test oder so zusammen. Das ist aber glaube ich auch wichtig,
dass man dann einen Moderator hat. In dem Fall habe ich das halt gemacht, der sich mit Testen auskennt. Also man braucht schon dieses Challengen auch, weil ich glaube, es ist viel gefährlicher, dass sich die Leute schnell einigen, als dass sie sich nicht einigen. Das heißt, man muss auch manchmal so ein bisschen piksen und mal hinterfragen, fehlt euch nicht noch was? Ist es wirklich so? Oder kommt das zum Beispiel aus der alten Welt, dass wir so und so machen?
Ja, es ist spannend. Ich habe jetzt gerade auch gedacht, echt tough als Moderator in so einer Situation zu sein, weil du sagst, dass man sich zu schnell einigt. Also ich hatte zuerst das Bild, dass man sich unendlich verzettelt an irgendwelchen Kleinigkeiten, weil dann sagt einer, ja aber hier in dem Modul, da haben wir das anders gemacht. Und das ist jetzt so, also dass man dann so irgendwo in irgendwelchen Sonderfällen da drinnen herum und dann eigentlich aus dem Unit-Test
gar nicht rauskommt und der Workshop rum ist. Kann wahrscheinlich auch passieren, aber tatsächlich hatten wir in dem Fall, weil es ja nicht für ein spezielles Produkt war, sondern so ein bisschen übergreifend und die Leute, die dabei waren, auch eher so diesen übergreifenden Blick hatten.
Deswegen war die Gefahr, glaube ich, gar nicht so groß. Und ich glaube, wenn Leute anfangen, sich so in Kleinigkeiten zu vertun, das typisches Moderator-Wissen, da muss man schon irgendwie sagen, komm, lass uns mal hier abschließen, machen wir noch einen Zettel, offener Punkt dran und dann ist auch gut, dann könnt ihr da später mal abends beim Kaffee oder so trinken. Wie waren denn diese Workshops denn besetzt von der Menge an Teilnehmern und welche Rollen hast du denn da dabei gehabt?
In meinem Vortrag habe ich gesagt, es gibt, also das ist natürlich, es ist wirklich eine schwierige Frage. Das ist halt wie beim Event-Storming, das funktioniert nur, wenn man die richtigen Leute dabei hat, aber es kann dir keiner von außen sagen, wer die richtigen Leute sind. Denn agile Projekte kennen ja irgendwie nur Entwicklers, Grandmaster, Product Owner, aber in gerade so großen Programmen gibt es ja noch ganz andere Leute, die ja noch beteiligt sein können. Also ich würde sagen,
man sollte immer, also man muss immer Leute haben, die die Teams repräsentieren. Die ganzen Teams kann man bei so großen Programmen nicht da reinnehmen, sonst landet man in einem Workshop mit 100 Leuten. Also man braucht Leute, die die Teams repräsentieren, die letztendlich sehr viel von dieser Testarbeit später machen müssen. Und man braucht aus meiner Sicht immer jemand, der so eine Product Owner,
der eine Produktbrille aufhat, den hatten wir tatsächlich nicht dabei. War in dem Kontext aber auch nicht so schlimm, das hatte so ein bisschen damit zu tun, die kamen halt vom Klassischen, sind erst langsam ins Agile gegangen, die hatten diese Rollen noch gar nicht so gut besetzt, dass man sie da hätte unterbringen müssen. So und dann hatten wir aber, wir hatten Architekten dabei, so diese Testabteilung, also Testmanager, Betrieb hatten wir dabei und so Sicherheitsexperten.
Das war auch, glaube ich, ein ganz gutes Setup, aber es ist halt in Projekten sehr, sehr unterschiedlich. Also es gibt sicherlich auch viele, wo man sagt, da muss ein Projektleiter oder ein Programmmanager oder so noch dazu. Wenn man Leute hat, die die Bildinfrastruktur betreuen, ist das wahrscheinlich auch noch jemand, den man dazu nehmen sollte, wenn man in so einem Safe Kontext ist, muss man wahrscheinlich so ein Systems Team auch irgendwo repräsentieren.
Also ich glaube, das gibt nicht so das Kernrezept, aber also auf jeden Fall, die Teams müssen beteiligt sein. Ja, ja, ja, also klingt ja auch sehr interdisziplinär und das ist ja wichtig, diese Sichten da zu haben, weil das ganze Thema Qualität, wenn ich es mal größer fasse, oder auch einfach Teststrategie, betrifft halt einfach sehr viele. Das ist ja nicht mehr nur so, da gibt es ja die Testabteilung, die dann so ein bisschen
so einen Zauber macht und dann läuft alles. Das betrifft ja eigentlich alle im Prozess. Ich finde auch gerade, also meine Erfahrung ist, dass bei agilen Projekten leider die nicht-funktionalen Anforderungen häufig gar nicht so beachtet werden. Und zwar nicht, weil die Leute es nicht wissen oder so, sondern weil sie es gerne nach hinten schieben.
Sie konzentrieren sich sehr auf Feature und das ist auch okay, wenn man es bewusst macht, aber dadurch rutschen die Sachen häufig so immer weiter nach hinten und das ist halt doch sehr gefährlich. Also man sollte schon wissen, sind sicherheitsrelevante Anforderungen da? Und dann kann man ja sagen, naja, vielleicht jetzt zum MVP noch nicht, weil das ein bestrengter Userkreis ist, vielleicht noch nicht so wichtig, aber dann irgendwann muss man halt da ran.
Und deswegen fand ich das ganz hilfreich, wirklich so eine Landkarte zu haben, wo man eben auch diese nicht-funktionalen Eigenschaften sieht, auch wenn sie manchmal in den Teststufen halt doch eher dann auch später kommen. Ja, ja. Jetzt ist ja in dem ganzen Kontext auch wichtig, warum mache ich denn das eigentlich, diese Testereihe, so irgendwie so Testziele oder sich irgendwas so vornehmen? Habt ihr das auch quasi mit betrachtet und wenn ja, wie?
Tatsächlich, also nicht explizit. Ich glaube, in dem Kreis, der da war, war irgendwie auch, also erstmal war es ja ein bisschen allgemeiner. Das heißt, wir haben ja nicht für ein Produkt ganz speziell gesagt, hier und ihr müsst nun besonders viel Usability, weil ihr macht das Frontend für irgendwie einen großen Teil nicht geschulter Nutzer. Das muss man dann, glaube ich, wirklich in den Projekten machen. Also das heißt, dass man wirklich
diese risikobasierten Ansätze, also das ist eher in den Projekten. Also und warum testen? Also ich glaube, das war den Leuten schon klar. Also man muss ja niemanden überzeugen, dass man testen muss. Und wie gesagt, diese Spezifika, warum in einem Projekt halt mehr das eine und weniger das andere gemacht wurden, das muss man dann sowieso einen Level tiefer machen.
Was habt ihr euch denn noch angesehen? Also Testarten, Teststufen, was für Komponenten so aus der Strategie habt ihr denn noch bearbeitet in dem Team? Genau, also Testarten, Teststufen, das war sozusagen die Landkarte. Also da hat man so eine Tabelle praktisch und die Zellen waren dann ganz wichtig, Rollen und Verantwortlichkeiten.
Also gerade wenn ich so einen abstrakten Mechanismus schaffe, wo ich sage, ja, das ist noch nicht die Teststrategie, da muss noch Arbeit reingesteckt werden, muss ja irgendwie klar sein, wer an dieser Arbeit noch einstecken muss. Also da steht dann dran, Entwicklungsteam, PO, Testabteilung, Last- und Performance-Experte oder sowas. Also das war ein ganz wichtiger
Bestandteil. Dann Tools. Tatsächlich kann man jetzt sagen, ist vielleicht ein bisschen früh, wenn ihr noch gar nicht wisst, so was ihr machen wollt, aber es war schon ein ganz klares Ziel in dem Programm, eine Vereinheitlichung der Tools über die Teams zu haben. Also nicht unbedingt, es gibt nur ein Tool, ihr dürft kein anderes nehmen, aber schon zu sagen, also wenn es das gleiche Setup ist von dem Tooling, dann sollte auch das gleiche Test-Tooling
genommen werden. Und da war auch schon einiges so an Vorhanden und einiges an Analysearbeit gemacht. Deswegen fühlten wir uns gut dabei, auch schon Tools, wenn sie denn bekannt waren, vielleicht auch mal ein oder zwei Optionen dazu aufzuschreiben. Eben gerade deshalb, weil eben nicht jedes Team es selbst suchen sollte. Also es gibt sicherlich auch Konstellationen, wo man sagt, die Teams haben die völlige Freiheit, dann braucht man das wahrscheinlich
nicht machen. In dem Kontext war es anders gewünscht. Macht ja wahrscheinlich auch Sinn. Also dann ist es ja doch ein bisschen effizienter, wenn nicht jeder das gleiche Problem mit einem anderen Tool lösen muss. Nächste Komponente, Umgebung. Also auf welchen Umgebungen wird das ausgeführt? Halte ich eben auch für wichtig, da früh drüber zu diskutieren, weil
man auch da häufig externe Abhängigkeiten hat. Also ein paar Sachen gehen natürlich irgendwie über so eine Pipeline, aber man hat gerade dann, wenn noch andere Systeme involviert sind, hat man ja auch immer bestimmte Umgebungen. Das kann man meistens ja als Team gar nicht selbst aufbauen, wenn andere Systeme beteiligt sind. Deswegen war das noch ein Punkt. Und als letztes Metriken. Sofern man schon wusste, also uns hat es völlig gereicht
zu sagen, wir wollen Code Coverage Metrik haben. Da musst du jetzt nicht stehen 80 Prozent, 50 Prozent oder so. Und genauso, also Ziel wäre natürlich eigentlich auch gewesen, sowas für Last und Performance, vielleicht ein paar generelle Sachen, also vielleicht generelle Regeln. Aber da ist halt auch rausgekommen, dass die Anforderungen
noch nicht klar genug waren. Und dann ist es auch okay zu sagen, okay, offener Punkt, wir klären erst mal die Anforderungen und danach kommen wir zurück und machen irgendwie Metriken daraus. Ja, es erspannet sich auch mal so zu nähern, finde ich gut, dass man die generelle Sicht mal darauf hat, was will ich denn eigentlich messen. Und dann kann man ja später noch immer schauen, wie spezifiziert sich das dann eigentlich aus. Wie messe ich
dann auch. Genau, deswegen spreche ich auch immer von einer Minimum-Weibel-Teststrategie, die da rauskommt. Da kommt halt keine Teststrategie raus, sondern man ist ja im Agilen auch immer offen für Veränderungen. Das heißt, man startet mit was, wenn wir wissen, wir wollen Code Coverage, dann starten wir vielleicht mit 80 Prozent und dann gucken wir mal, ob wir damit Probleme haben. Und dann können wir immer noch sagen, okay, 75 oder 90 sind
besser oder vielleicht sogar noch besser. In dem und dem Fall sind 90 besser und in dem und dem Fall sind vielleicht 75 besser. Aber dass man erst mal was hat, um loszulegen und überhaupt so einen kontinuierlichen Lernprozess überhaupt in Gang zu setzen. Das ist halt immer schwierig, wenn nichts da ist, dann kann ich nicht kontinuierlich verbessern. Aber so hatten wir erst mal was, womit die Teams dann auch loslegen konnten.
Ja, das wäre jetzt auch meine nächste Frage. Wie ging es denn dann weiter? Also ich meine, dann sitzt man in so einem Workshop, dann hat man da so irgendein Arbeitsergebnis, aber es geht ja vielleicht auch in Richtung Dokumentation oder wie entstehen die nächsten Handlungsschritte daraus? Tatsächlich kam ja nur von außen da rein.
Also ich kann es im Detail nicht sagen, aber was das Schöne war, wir hatten halt diese sehr große Tabelle mit den ganzen Post-its, wer ist verantwortlich, wo wissen wir schon was, wo sind offene Punkte. Ein ganz wichtiger Schritt war es dann, den Teams zu zeigen. Also es war gut visualisiert, dass man da wirklich schön durchgehen konnte. Also es ist nicht Hochglanz, aber es ist sehr gut nachvollziehbar für die Teams, wo sind Leute
von euch auch beteiligt, was erwarten wir von euch. Die konnten auch noch, also es waren zwar vorher auch schon Repräsentanten der Teams dabei, aber natürlich kamen dann auch noch da Wünsche oder ja, wir machen das aber so oder wollten das so machen. Da konnte man natürlich auch noch Änderungen machen. Und das heißt, die Teams wussten dann auch schon, also hatten nach diesem Meeting schon verstanden, was ihre Aufgaben sind. Und dann sind halt
aus vielen von den offenen Punkten halt wirklich Backlog-Items geworden. Und die Architekten hatten das sehr stark getrieben, haben das sozusagen als ihre Aufgabe dann genommen, das dann auch wirklich in die Teams dann weiter zu tragen und zu implementieren. Also die hatten so eine Architektengilde, die dann auch sozusagen auch dieses Testthema dann mit betreut hat und das halt auch weitergetrieben haben in den Pilotprojekten.
Ah ja, ok. Und gab es dann auch irgendwie eine gesonderte Dokumentation dazu, dass jemand das kanalisiert oder hat man das dann quasi einfach gelebt so über die Backlog-Items und dann in den Prozess sickern lassen? Also ich bin mir ganz sicher, es wird, weil das ein eher formaleres Umfeld ist, es wird irgendwann auch eine aufgeschriebene Teststrategie dazu geben. Wie weit die da schon sind, weiß
ich nicht, aber das wird auf jeden Fall kommen. Ja, hoffentlich, ich hoffe nur, dass Sie wirklich sehen, es wird aufgeschrieben und hoffentlich auch immer wieder angepasst und nicht so, also dieses typische, wir haben irgendwie hier unsere 100 Seiten und jetzt, das gilt, aber da hält sich keiner dran, weil keiner es gelesen hat. Ja, also ich finde es total schön, sich so einem manchmal schwergewichtigen Thema so leicht zu nähern, einfach einmal auch zu schauen, dass man da in Fahrt kommt und das
mal zusammenzusammeln und das auch so leichtgewichtig zu starten. Und ich finde den Begriff, den du vorher gesagt hast, der Minimal Revival Teststrategie, das trifft es ja auf den Punkt, weil das wollen wir ja auch. Wir wollen ja nicht jetzt ein Testkonzept mit 35.000 Seiten, das keiner liest, sondern dass man irgendwas Nutzen bringen hat, was dann auch weiterarbeiten
kann. Ich glaube, vor allem ist es halt wichtig, um loszulegen, dass man sich eben auch auf die Punkte konzentriert, die ganz wichtig sind. Und wenn etwas weiter hinten im Prozess ist oder wenn ich eben sage, Security ist, wie ich die, aber muss nicht von Tag 1 unbedingt gemacht werden. Das reicht schon, wenn wir drei Sprints implementiert haben und vielleicht Bibliotheken mit Sicherheitslücken, weil es ist ja vielleicht noch nicht so schlimm, wenn das Minimal Revival Produkt erst nach
20 Sprints oder so live gehen soll. Also einfach, dass man aber bewusst solche Entscheidungen trifft. Ja, sehr gut. Was war denn so dein größtes Learning aus dem Prozess? Wo du sagst, das hast du für dich jetzt so mitgenommen oder das würdest du vielleicht auch nochmal ganz anders machen oder da hättest du noch einen Impuls? Ich weiß gar nicht, ob so ein großes Learning, da gibt es viele kleinere Sachen. Also was ich mitgenommen habe, ist, dass diese Visualisierung
total gut funktioniert. Und ich habe das inzwischen zum Beispiel auch für Projekte, also ohne jetzt ein großes Storming mit mehreren Leuten gemacht, ich habe das inzwischen schon auch gemacht, um aus vorhandenen Projekten, die eben diese langen Teststrategien haben, das einfach mal so zu übertragen. Also ich wurde vor kurzem zum Beispiel gebeten, ein Projekt mir anzugucken. Die hatten zwei Teststrategien, also für Akzeptanztest und für den davor.
Und um das überhaupt mal zusammenzubringen, habe ich zum Beispiel diese Visualisierung gewählt. Und man hat es halt sofort gemerkt. Beim Durchlesen der Seiten merkst du es nicht, aber wenn du es dann mal so aufschreibst, merkst du zum Beispiel, dass unterschiedliche Begrifflichkeiten drin sind, dass Ziele zum Teil auch gegensätzlich waren und so. Also das ist für mich so etwas, was ich mitnehme, außerhalb von dem, dass ich eine Teststrategie
jetzt wirklich neu entwerfe, dass das sehr hilft. Ansonsten, ja, ich würde tatsächlich auch diesen Punkt, also lieber mehr challengen, als schnell durchregieren. Ich bin tatsächlich auch, ich habe das Kollegen auch mal erzählt, diese Erfahrung. Und da kam auch mal als erstes eher das, was du sagtest, ja, aber wie schaffe ich es als Moderator, da möglichst schnell
durchzukommen und so. Und meine Erfahrung aus dem wäre eher zu sagen, das ist nicht euer Problem, sondern versucht wirklich eher auch breit zu denken, wirklich diese Landkarte klar zu kriegen. Kleiner kriegt man es dann später auch noch sozusagen in den Einzeltasts.
Ja, ja, sehr spannend. Ja, super. Das finde ich total, total schön, dass man so einen leicht wirklich pragmatischen Weg da auch, kann ich mir auch gut vorstellen, auch das Visualisieren, das nehme ich jetzt für mich auch noch mal mit, zu schauen, so ein alten, eingestaubten Dokument mal in so eine Visualisierung zu bringen, um mal diese Landkarte sichtbar zu machen. Das finde ich ein schönes Bild, was ich auch mal ausprobieren möchte. Also,
ja, habe ich auch schon was mitgenommen. Ja, freu mich. Ja, Katrin, vielen lieben Dank, dass du hier Rede und Antwort gestanden hast und uns hier so ein bisschen mitgenommen hast. Ich glaube, da ist sicher für den einen oder anderen eine Idee dabei, auch im eigenen Unternehmen mal zu schauen. Und ja, ich wünsche dir noch ganz viel Spaß hier auf der Konferenz und bis bald. Ja, danke. Tschüss. Tschüss. [Musik]