Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Mein Gast heute ist Florian Fieber. Mit ihm spreche ich über das Thema Abnahmetest beziehungsweise Acceptance Testing. Er hat mit Marc-Florian Wendland zusammen das Buch Basiswissen Abnahmetest geschrieben, das auch zur Zertifizierung zum IST-Kopie Acceptance
Tester genutzt werden kann. Wie er den Abnahmetest sieht, was die Unterschiede zwischen Abnahmetests im agilen und traditionellen Umfeld sind und warum es super ist im Abnahmetest keine Fehler mehr zu finden, darüber haben wir beide gesprochen. Viel Spaß bei der Folge. Hallo Florian, schön, dass du da bist. Hallo Richi, vielen Dank für die Einladung. Ich freue mich sehr. Ja, ich mich auch, weil wir haben heute auch ein ganz großes Thema. Also ich meine, du
könntest ja eh, glaube ich, über alles sprechen im Bereich Software Test. Du bist da ja auch ein alter Hase und jetzt ja nicht nur, sag mal, mit Business, sondern auch in deiner Funktion beim German Testing Board auch aktiv an der Community Arbeit, an dem das Thema Testen weiterzubringen und ich glaube, da könnten wir eine Folgen-Serie machen sogar
mit Inhalt. Aber wir haben uns ja für heute ein spezielles Thema rausgesucht und zwar wollten wir uns mal unterhalten über das Thema Abnahmetest, Acceptance Testing, wo du ja auch mit Marc-Florian Wendland ein Buch geschrieben hast, Basiswissen Abnahmetest, das wir dann auch mal kurz uns mit anschauen werden. Ja, sag mal, wie bist du denn zu dem Thema Abnahmetest auch gekommen, da auch ein Buch zu schreiben und dich damit mehr zu beschäftigen?
Ein Stück weit ein bisschen zufällig. Es kam über meine Arbeit im German Testing Board, wo ich 2018 gestartet bin und damals ist gerade der neue Lehrplan Acceptance Testing veröffentlicht worden auf Englisch und wir haben eine entsprechende Arbeitsgruppe im GTB gegründet. Da geht es immer darum, den Lehrplan zu lokalisieren, auf den deutschen Markt zu bringen, eben übersetzen,
Prüfungsfragen übersetzen und so weiter. Und da haben wir uns sehr intensiv mit dem Thema eben auseinandergesetzt und in der Folge dann auch selbst Seminar entwickelt dazu und dann auch das Buch geschrieben. Das war aber jetzt natürlich nicht komplett zufällig, weil das Thema mich natürlich sehr interessiert, weil es sehr spannend ist und im Prinzip so ein bisschen meine Leidenschaften, die ich im Bereich Software Engineering habe, eigentlich schön zusammenbringt.
Welche Leidenschaften sind denn das? Es geht viel um Anforderungen, würde ich sagen. Man ist sehr stark an dem Thema der Anforderungen dran. Man ist sehr stark mit der Business-Seite involviert. Man hat mit dem ganzen Thema Requirements Engineering und Business-Analyse zu tun. Die Perspektive finde ich sehr spannend,
jetzt auch neben dem Testen mich damit auch auseinanderzusetzen. Man hat im Prinzip das ganze Testobjekt vor sich und hat so eine Ende-zu-Ende-Sicht auf das ganze Testobjekt und das macht es inhaltlich, finde ich, sehr interessant und spannend, dass man so ein bisschen diese Welten zusammenbringt. Ich finde den Abnahmetest auch von den Testzielen her sehr spannend. Der ist jetzt im Gegensatz zu den anderen Teststufen weniger darauf ausgerichtet,
Fehler zu finden und vielleicht zu zeigen, dass das Testobjekt nicht funktioniert. Im Gegenteil, es ist eine vertrauensbildende Maßnahme und man möchte eigentlich genau das Gegenteil erreichen,
nämlich keine Fehler finden. Das unterscheidet ihn sehr stark und der dritte Aspekt beim Abnahmetest ist eigentlich der, dass man an dem sehr gut zeigen kann oder illustrieren kann, was man im Testen alles richtig machen kann beziehungsweise was man auch falsch machen kann und das macht ihn für mich so ein bisschen zur spannendsten Teststufe eigentlich,
die wir zur Verfügung haben. Jetzt zum Thema Abnahmetest. Es gibt natürlich die ganzen Definitionen, aber wenn du das kurz und prägnant quasi definieren müsstest, was ein Abnahmetest eigentlich darstellt, du hast ja schon gesagt, ein bisschen vertrauensbildend, wie würdest du es definieren? Ich würde mal von den üblichen Teststufen her kommen, die wir kennen, die wir auch so ganz klassisch an einem V-Modell gelernt haben, vom Komponenten-Unit-Test, Integrations-
des-System-Test bis eben zu einem Abnahmetest. Es geht ja im Prinzip immer darum, ein Testobjekt schrittweise zu integrieren von der kleinen Stufe, vom einzelnen Baustein der einzelnen Komponenten, die eben zu prüfen, hin zu einer Integration, einer schrittweisen Zusammenfügung, das Bild größer machen, an den Schnittstellen zu schauen und so weiter. Dann eben zum Systemtest, wo wir
dann auch tatsächlich das ganze integrierte System eigentlich haben und dann zum Abnahmetest. Und der Unterschied zwischen System- und Abnahmetest ist eigentlich der, dass der Systemtest noch mehr darauf ausgerichtet ist und stärker aus der, ich nenne es mal, aus der Hersteller-, aus der Auftragnehmerperspektive, den Prüfgegenstand des Testobjekts sich anzuschauen, wohingegen jetzt der Abnahmetest typischerweise aus der Perspektive des Auftraggebers, der Fachseite, des Anwenders,
des Nutzers und so weiter ist. Und letztendlich logisch gesehen die letzte Teststufe darstellt. Praktisch muss es nicht notwendigerweise die letzte sein. Es kann ja sowas wie Zwischenabnahmen geben. Es kann sein, dass ich eine Abnahme von einem System mache und danach in einem Systemintegrationstest Systeme noch weiter integriere und dann nochmal ein Abnahmetest
kommt. Aber rein logisch von der Sache her, ich möchte bewerten und schauen, ist mein Test Objekt gut genug für den Einsatz, ist es logisch gesehen quasi die letzte Teststufe. Wie und oder tust du das überhaupt, grenzt du das auch zum Acceptance-Test, den man so im agilen Vorgehen kennt, der ja viel kleinteiliger auch ist? Ist das für dich das
Gleiche in der DENK oder sind das unterschiedliche Themen? Weil ich merke oft, dass die Begriffe auch oft synonym verwendet werden, aber manchmal dann, also in der Praxis dann doch auch was anderes irgendwie auch beschreiben. Von der Logik her ist es für mich das Gleiche. Ich würde auch Acceptance-Test, Akzeptanz-Test, Abnahmetest erstmal als von der Idee und vom Prinzip und
vom Ziel her als das Gleiche ansehen. Der Unterschied ist glaube ich der, dass wir im agilen Kontext ihn viel besser in den Prozess eingewoben haben, eingebaut eigentlich in den Entwicklungsprozess. Das ganze Thema Build-In-Quality, Shift-Left, Kollaboration, Zusammenarbeit von den Rollen ist da viel besser ausgeprägt und deswegen kann er da glaube ich auch viel besser und effizienter stattfinden. Aber von der Sache her ist es in einem ganz
traditionellen Wasserfall-V-Modell basierten Projekt erstmal vergleichbar. Nur mit den Herausforderungen, die wir dort eben häufig haben, dass es sehr spät stattfindet, dass wir vielleicht eine Entkopplung haben von der ganzen Entwicklung, schon von der Anforderungsdefinition
von der Entwicklung, von dem Test, der möglicherweise relativ spät erst reinkommt. Das heißt, da ist es gleich, aber man kann ihn eben sehr unterschiedlich ausspielen und in verschiedene Geschmacksrichtungen, die eben dann immer effizienter werden, würde ich sagen und den richtig gut quasi in den Entwicklungsprozess und den Testprozess einweben. Verstehe. Also das, also inhaltlich schon ähnlich, aber halt eine andere Ausprägung von dem Ganzen. Also das ist
auch das, so wie ich es in der Praxis auch in Projekten auch erlebe. Jetzt hast du ja schon gesagt, das betrifft natürlich ja ein ganz großes, eine große Spannweite im Projekt. Es beginnt ja vorne mit den Anforderungen, mit den Geschäftsobjekten, Prozessen oder was auch immer. Wenn du jetzt ein Projekt bekommst, sagst du, da muss man jetzt einen Abnahmetest machen. Worauf schaust du denn bei diesen ganzen Anforderungen am Anfang, damit das überhaupt nutzbar wird für dich, für
einen Abnahmetest, den du begleitest? Es hängt erst mal schon mal davon ab, wann du dieses Projekt bekommst, beziehungsweise wann du, wenn man jetzt nicht so ein bisschen aus externer Perspektive drauf schaut, aber als Tester einfach mal ganz allgemein, wann du in den Abnahmeprozess eingebunden wirst. Weil damit steht und fällt natürlich schon ganz viel an Möglichkeiten, die du hast,
den Abnahmetest in den Entwicklungsprozess einzuweben und mit dem zu verweben. Der Worst Case, der Bad Case, der vielleicht, wie man es klassisch traditionell gemacht hätte, war eher der, dass man relativ spät erst mit einem Abnahmetest betraut wird. In dem Sinne, als das in Entwicklung schon läuft, Anforderungen sind eh schon lange geschrieben, wird im Moment noch ein bisschen an die Implementierung gefeilt, aber in ein, zwei, drei, vier Wochen steht die Lieferung
an und man fängt dann an sich sozusagen auf die Abnahme vorzubereiten. Das ist sozusagen genau so, wie wir es eigentlich nicht haben wollen, dass ich sehr, sehr spät, zum spätestmöglichen Zeitpunkt mich mit den ganzen Abnahmetestaktivitäten eigentlich beschäftige. Und ich glaube, ein Problem ist tatsächlich diese Sicht, was ich vorhin auch gesagt habe, dass der Abnahmetest
logisch gesehen die letzte Teststufe ist. Das heißt aber im Umkehrschluss nicht, dass ich mich logisch oder tatsächlich auch als letztes mit dem Abnahmetest beschäftigen muss. Ich muss nicht warten, bis ein Systemtest abgeschlossen ist, bis eine Lieferung da ist und mir dann Gedanken darüber machen, okay, was machen wir denn jetzt eigentlich und wie plane ich das Ganze und was muss ich eigentlich testen und was sind eigentlich die Testfälle und so
weiter, sondern ich kann das natürlich viel früher machen. Und dementsprechend, wenn ich als Tester natürlich von Anfang an dabei bin, dann werde ich natürlich versuchen, mich dort in den ganzen Abnahme, in den ganzen Anforderungsprozess einzuklinken und nicht nur reinzusnicken und sagen, hallo, hier bin ich, ich möchte auch ein bisschen mitspielen, sondern idealerweise schaffen wir natürlich ein Umfeld und haben Prozesse, in denen das wirklich gemeinsam und
kollaborativ stattfindet, dass wir von Anfang an gemeinsam auf Anforderungen draufschauen, uns als Tester mit einer Testbarkeit von Anforderungen zum Beispiel beschäftigen. Das ist schon mal der erste Schritt. Erfordert aber eben organisatorische Rahmenbedingungen, die genau das ermöglichen. Und das habe ich im agilen Umfeld natürlich viel besser als in einem traditionellen Silo getrennten, verschiedene Bereiche, Abteilungen, wo man dann eben erst
später drankommt. Aber wenn ich eben von Anfang an dabei bin und das nicht als Sequenz betrachte, dann kann ich da, glaube ich, richtig effizient werden. Was macht denn für dich da aus Abnahmesicht eine gute Anforderung aus, gerade auch im agilen Kontext? Wir haben ja da mal bestimmte Storys und irgendwelche Akzeptanzkriterien oder auch nicht oder irgendwelche Dinge. Wo sagst denn du da für dich, ach, mit dem kann man gut arbeiten?
Erst mal, dass sie testbar ist, dass überhaupt die Testsicht mit reinkommt. Ich glaube, das ist eben genau der wichtige Punkt, dass Tester Fragen stellen, andere Denkweisen haben, um die Ecke vielleicht mal mehr denken, an Edge Cases denken, hinterfragen. Zum einen, zum anderen aber eben sehr genau sind und eben genau wissen wollen, wo jetzt vielleicht eine
Grenze zwischen zwei Dingen verlaufen. Das heißt, diese ganze Testbarkeit zum einen, die eine gewisse Vollständigkeit auch hinsichtlich der Ausprägungen, die wir bei einer User Story beispielsweise haben, in der Funktionalität, eben nicht nur die guten Fälle, sondern auch die Edge Cases, die negativen Fälle und so weiter. Aber eben neben der Funktionalität, und ich glaube, das ist ein ganz wesentlicher Punkt, der mit reinkommen sollte, ist eben auch an das ganze
Thema nicht-funktionale Anforderungen oder Abnahmekriterien zu denken. Wir haben neben der reinen Funktionalität die typischen, das große Feld der nicht-funktionalen Anforderungen von Gebrauchstauglichkeit, Zugänglichkeit, Sicherheit, Performance und so weiter. Und das eben da auch mit reinbringen in Form geeigneter Abnahmekriterien. Ich glaube, das ist ein echter Mehrwert, den ein Tester leisten kann bzw. das Team unterstützen kann, an der Stelle da reinzudenken und die
Dinge eben auch mit zu berücksichtigen, angemessen. Und das ist natürlich eine schöne Sache, wenn man das so früh wie möglich hat, weil dann hat vielleicht der Entwickler ja auch noch was davon, wenn man das nicht erst im Nachhinein dann feststellt, dass da irgendwo Lücken sind. Naja, das ist genau dann eigentlich der Idealfall, dass wir uns, bevor wir die erste Zeile Code
schreiben, ein gemeinsames Verständnis erarbeiten aus den verschiedenen Perspektiven. Und sowohl für einen Business-Analyst, PO, Fachbereichsmitarbeiterin aus der einen Seite, aber eben auch aus der Test- perspektive und aus der Implementierungsperspektive eben genauso das gleiche Verständnis schaffen.
Und mit Hilfe von Abnahmekriterien, aber dann weitergehend vielleicht mit Testfällen, die wir vor der Implementierung auch schon erstellen, dieses Verständnis schärfen und damit vielleicht auch Beispiele liefern, die das ganze Verständnis einfach erleichtern und eben auch die Implementierung wesentlich unterstützen können. Weil ich viel besser verstehe, was
gefordert ist. Ich habe konkrete Beispiele, mit denen ich arbeiten kann und insgesamt damit eine viel, viel höhere Wahrscheinlichkeit habe, dass wir das Richtige bauen. Ja. Wenn jetzt die Anforderungen soweit stehen und das geht ja dann, so wie es schon gesagt,
in die Testfallerstellung auch oder in den Testentwurf. Jetzt ist es ja häufig so, der Abnahmetest wird ja häufig mit unterstützt oder auch vielleicht sogar durchgeführt von Fachleuten, von Sachbearbeitern, von wer auch immer da fachlich funktional dann auch mehr drauf hat und weniger diese Testsicht drauf hat. Wie kriegst du denn das zusammen? Hier eine gute Testfallerstellung auch zu ermöglichen und das zu verknüpfen mit der Fachlichkeit?
Es ist eine Herausforderung und zwar glaube ich von der Warte her, was man tatsächlich mit dem Abnahmetest erreichen möchte. Ich beobachte sehr häufig, dass ein Abnahmetest meiner Meinung nach viel zu umfangreich ist, als er eigentlich sein müsste. Warum? Weil man in das Testobjekt nicht ausreichend Vertrauen hat, nicht wirklich glaubt, dass es das tut, was es tun soll und/oder die Transparenz nicht gegeben ist und man nicht weiß, was eigentlich schon alles getestet wurde und ob
man da noch was machen muss. Das hat man natürlich umso stärker, je stärker man entkoppelt ist, wenn ich einen Lieferanten habe oder wenn ich eine andere Entwicklungsabteilung habe, die mir dann irgendwie was über den Zaun wirft, dann tendieren natürlich die Abnahmetests dazu, sehr umfangreich zu werden. Da wird quasi zum schlechtestmöglichen Zeitpunkt, nämlich ganz
zum Schluss, tatsächlich die Qualität reingetestet und das ist das, was wir nicht haben wollen. Dann wird es natürlich schwierig, wenn ich ausschließlich an der Stelle, sage ich mal, nicht Testexperten habe, die die ganzen Themen mit den Testverfahren, mit unterschiedlichen Ausprägungen von Tests, mit geeigneten Testdaten und so weiter vielleicht nicht so gut kennen,
sondern eher aus der Anwenderperspektive drauf schauen. Das heißt, da brauche ich eine gute Zusammenarbeit und Kombination, zum einen eben aus der Testperspektive, aber eben auch aus der
Anwenderperspektive, um das zusammenzubringen. Wenn der Abnahmetest andersrum einer ist, wo es wirklich nur noch um die vertrauensbildende Maßnahme geht, wo ich den Anwender, die Nutzerin, das Vertrauen geben möchte, dann kann ich das durch einen Beta-Test unterstützen, vielleicht eine andere Form von explorativen Testen, aber wo der Anwender und die Anwenderin dann eben in ihrer Arbeit mit einem Testobjekt umgehen und jetzt gar nicht Testfälle abarbeiten
in dem Sinne, sondern es einfach nutzen. Da brauche ich gar nicht diese starke Testfachlichkeit da drin. Also es hängt sehr stark davon ab, eigentlich wie der Entwicklungsprozess gestaltet ist und ob die Anwender beispielsweise im Abnahmetest das Testobjekt zum ersten Mal überhaupt sehen oder sagen, ja klar, ich kenne das schon, ich habe die ganze Entwicklung eigentlich mit begleitet und jetzt geht es eigentlich nur in Anführungszeichen noch darum, das letzte Mal drauf zu schauen und
zu gucken, dass alles tatsächlich gut ist. Also da sprichst du mir auch aus der Seele, weil ich habe, also das ist die große Hürde, die ich da auch häufig, ganz häufig mitbekomme,
wo ich dann Projekte sehe. Ich war gerade auch in so einem Projekt, wo ein paar Sachen automatisiert getestet wurden und dann auch laufend in der Pipeline und trotzdem manuell das nochmal durchgeführt wurde, weil man hat irgendwie kein Vertrauen da rein, man sieht die Transparenz nicht, was alles wirklich da automatisiert ist und das ist eigentlich das Gap, das dann gelöst werden
muss. Und ich finde immer das Bild so schön, wenn diese ganzen Stufen davor und diese ganzen Qualitätsprüfungen, die man so im Prozess macht, sauber laufen, dann kann der, der die Abnahme macht, im Prinzip im besten Fall mit einem Cocktail in der Hand entspannt ein bisschen rumklicken und sich des Lebens freuen und sagen, ja, da habe ich eine schöne Zeit wieder gehabt hier. Total, also ich würde sagen, der ideale Abnahmetest ist einer, der gar nicht stattfindet
oder nicht stattfinden muss. Wie gesagt, das Ziel des Abnahmetests ist, Vertrauen zu schaffen und Vertrauen schaffe ich nicht durch Fehler finden. Die Fehler sollten vorher gefunden werden und natürlich ist es gut, im Abnahmetest einen Fehler zu finden und zu verhindern, dass ein Fehler in die Produktion kommt. Aber so als Last Line of Defense kann man das machen, dann ist es vielleicht effektiv, was man tut und verhindert, dass Fehler in die Produktion kommen, aber es ist weit davon
entfernt, irgendwie effizient zu sein. Und ich meine ganz einfach, die relativen Fehlerbehebungskosten, wie wir sie kennen, da ist der Abnahmetest einfach ganz schlecht, ganz schlechter Kandidat, um in der Phase viele Fehler zumindest aufzudecken und zu beheben, was im Umkehrschluss nicht heißt, wir sollten nicht testen, weil dann finden wir keine Fehler, sondern wir testen zwar, aber das, was wir testen, funktioniert. Ja, genau. Ja, das ist quasi der gute Aufruf,
hier auch in dem Podcast, sich das genau anzuschauen. Der Abnahmetest ist jetzt nicht die Lösung für alles das, was man vorne quasi nicht gemacht hat. Das kann es gar nicht sein, sondern wird dann eher da zum Problem, als wenn man vorher die Sachen ordentlich macht.
Total. Also in meinen Schulungen, also ich bin auch als Trainer unterwegs, im Certified Tester und wenn wir eben die Teststufen durchgehen, dann ist genau an dem Punkt am Abnahmetest immer meine ganz, ganz dringende Empfehlung, wir gucken immer noch mal auf die relativen Fehlerbehebungskosten und legen das nebeneinander, um wirklich zu zeigen, Abnahmetest ist wichtig, aber es ist nicht dafür da, am Ende irgendwie Qualität in das Produkt
hinein zu testen. Wie gesagt, man kann das machen und dann dauert es halt lange und am Ende hat man
vielleicht ein gutes Produkt, aber es dauert halt lange. Ich meine, das, was wir seit Jahrzehnten kennen, also wir zwei vielleicht nicht seit Jahrzehnten, aber wir haben schon mal davon gehört und auch von den Grundprinzipien des Testens, so früh wie möglich, das ist ja alles nichts Neues und das ist natürlich im Abnahmetest sehr, sehr gut möglich, nach links zu schieben, so früh wie möglich und zu verhindern, dass wir zum späten Zeitpunkt eben diese ganzen Aufwände haben.
Ja, und rechts ist ja auch kein Platz mehr, also es muss ja dann alles nach links gehen. Du hast ja mit Marc-Florian zusammen das Buch "Basiswissen Abnahmetest" geschrieben, das ja auch begleitend für den Lehrplan IST-Copy Certified Tester Acceptance Testing ist. Kannst du uns mal einen Überblick geben, was deckt dir denn da ab oder der Lehrplan auch? Wo fängt der
an und wo hört der auf, wenn man auf den Abnahmetest blickt? Also, ich würde sagen, der erste Teil, der geht wirklich mal um dieses Verständnis und Selbstverständnis, was wir jetzt gerade eigentlich alles schon so ein bisschen andiskutiert haben. Also die Bedeutung des Abnahmetests und dann aber eben, wie wir den Abnahmetest sehr gut und sehr effizient gestalten können durch Kollaboration, durch frühes Testen, durch Integration der Abnahmetestaktivitäten mit den Aktivitäten
der Business-Analyse. Das ist ja so ein bisschen die Synthese, die quasi in dem Lehrplan gemacht wird, dass wir die Business-Analyse und den Abnahmetest zusammenbringen, dass wir zwar Rollen haben, unterschiedliche, die da lauten Business-Analyst und Tester in, aber die idealerweise zusammengehören bzw. zusammenarbeiten sollten. Und das ist sozusagen der erste Teil, um den wir
uns da kümmern. Dann die ganzen Möglichkeiten und Formen der sehr effizienten Zusammenarbeit, was das ganze Thema Test-First und im Abnahmetest natürlich insbesondere Acceptance-Test-Driven Development und auch BDD betrifft, wie wir das nutzen können und das sozusagen durch einen geeigneten Prozess einweben können. Wir gehen tatsächlich auch in ATDD tiefer rein, würde ich sagen. BDD gehen wir tiefer rein. Dann ist ein großer Teil Qualitätskriterien und insbesondere
nicht funktionale Qualitätskriterien, die interessant sind. Wir kennen ja die, was weiß ich, wie so 25.010 beispielsweise mit ihrer Menge an Qualitätskriterien. Da picken wir mal drei raus, die Gebrauchstauglichkeit mit Nutzungsqualität auch, die IT-Sicherheit und die Performance und gehen da mal ein bisschen tiefer rein und schauen, was sind denn da die Herausforderungen im Sinne von Abnahmekriterien zu definieren, Abnahmetestfälle zu erstellen, also auf einer High-Level-Ebene
zumindest und wie das eben durch einen Abnahmetest dann geeignet unterstützt werden kann. Und dann ist ein sehr großer Teil, wo es um Modellierung geht und zwar Geschäftsprozessmodellierung und Geschäftsregelmodellierung, das sozusagen als Unterstützung des Abnahmetests zum einen Richtung Geschäftsprozesse mit BPMN als Beispiel und die Geschäftsregelmodellierung mit DMN, also Decision Modelling and Notation, Entscheidungstabellen beispielsweise ein ganz großes Thema, wo wir da
reingehen und quasi zeigen, wie wir Modelle nutzen können. Zum einen natürlich, um das Testobjekt zu spezifizieren, aber vor allem eben auch aus Testperspektive ein erwartetes Verhalten beispielsweise zu identifizieren, zu modellieren beziehungsweise auch aus den Modellen dann abzuleiten, was müssen wir denn jetzt eigentlich testen, um bestimmte Pfade in einem kritischen Geschäftsprozess
beispielsweise abzudecken. Und der letzte Teil, der dreht sich dann nochmal so ein bisschen um das Thema der Zusammenarbeit, gute Form der Zusammenarbeit eben zwischen den verschiedenen Rollen und kein Certified-Tester-Lehrplan würde natürlich enden ohne ein kurzes Kapitel zum Thema Testwerkzeuge. Insofern ist eben auch nochmal 15 Minuten spendiert worden. Ah ja, also schöner Überblick quasi über den ganzen Prozess hinweg, was ja im Prinzip auch
sehr, sehr essentiell ist. So wie du gesagt hast, dich von vornherein auch mit den Dingen zu beschäftigen. Und ich habe ja selber auch mal ein bisschen reingeblättert und mir ein bisschen quer gelesen die Sachen. Das ist, glaube ich, ein super Einstieg in diese ganze Materie, auch wie kann ich meinen Abnahmetest besser machen. Also das finde ich schon super, dass ihr das auch mit auf den Weg gebracht habt. Genau.
Ja, es hat vor allem auch total Spaß gemacht, muss man sagen. Also A, hatte ich einen sehr, sehr guten Co-Autor mit Marc-Florian. Wir haben uns sehr gut ergänzt. Wir haben uns von der Warte, ich meine, du kennst ihn ja selbst auch aus eigenen Projekten. Auch mein Co-Autor, ja. Wir haben uns sehr gut auch die Bälle zugespielt, würde ich sagen. Es hat sehr gut funktioniert.
Und es war halt inhaltlich mega spannend, weil wir halt in unserer Domäne, in unserem Feld unterwegs sind und da letztendlich in der Hoffnung, dass die Erfahrungen, die man selber macht, ein Stück weit helfen können bzw. repräsentativ sein können, das da mit reinbringen und aber selber eben auch nochmal diesen sehr intensiven Thought-Process zu haben, sich da durchzudenken und so weiter. Also war spannend und würde ich gerne wieder machen.
Ja, ja, na ja, da wird sich Gelegenheit finden. Und unser Podcast wäre ja nicht der Podcast, die langjährigen, fast schon, Hörerinnen und Hörer werden es wissen, wenn wir ein Buch vorstellen, dann gibt es das natürlich auch zur Verlosung. Wir haben fünf Exemplare von Basiswissen Abnahmetest und den Link zur Verlosung findet ihr wie immer in den Show Notes. Und ja, schnappt euch da ein Exemplar, das kann auf jeden Fall helfen. Ja, Florian, vielen lieben Dank, dass du hier Rede
und Antwort gestanden hast. Ich glaube, du hast uns da gut über das Thema mal mit reingebracht, was es eigentlich bedeutet, worauf man achten muss, was eigentlich die Bedeutung von so einem Abnahmetest auch ist und dass es eben nicht nur ist, am Schluss irgendwie ein bisschen noch die Kuh vom Eis zu kriegen, sondern dass das eigentlich eine ganz andere Aufgabe auch hat. Ich glaube,
das ist mir zumindest noch einmal klar geworden und ich hoffe auch den anderen. Also vielen herzlichen Dank, dass du hier warst und ich freue mich, wenn wir wieder mal eine Folge machen, vielleicht zu einem anderen Thema. Ja, auch von meiner Seite vielen Dank für den sehr schnellen Ritt darüber und tatsächlich, du hast ja gesagt, das Thema bietet an allen Stellen, an denen man vorbeikommt, so viel Potenzial, um natürlich in die Tiefe zu gehen. Ich glaube,
es ist dann aber auch eine gute Ergänzung. Gestern erst noch mal eine der letzten BDD-Folgen gehört, die du gemacht hast. Das passt thematisch super rein, also gerade diese Verknüpfung auch mit den anderen Themen, die du da hast, ist, glaube ich, sehr spannend. Insofern von meiner Seite auch noch mal vielen herzlichen Dank und ich würde mich sehr freuen, bei Gelegenheit mal wieder dein Gast sein zu dürfen. So machen wir das. Dann alles Gute, bis bald. Alles Gleiche, danke schön. Ciao.
Ciao. [Musik]