Ho Ho Ho, herzlich willkommen zur Weihnachtsfolge vom Podcast Software Testing. Na und da gibt es natürlich Geschenke, aber erstmal hört ihr euch die Folge an. Diesmal bei mir zu Gast meine Co-Autoren Manfred Baumgarten und Martin Klonk, die zusammen mit Christian Mastnack und mir das Buch Agile Testing geschrieben haben, das jetzt in der dritten Auflage verfügbar ist.
Christian konnte an der Folge leider nicht teilnehmen, aber mit Martin und Manfred habe ich mich über die Entwicklung von Agile Testing, unseren Blick auf die Softwareentwicklung, auf Tools, Methoden und das ASTQB unterhalten. Ich wünsche euch ganz viel Spaß bei der Folge und euch allen frohe Weihnachten und bis bald. Hallo Manfred, hallo Martin, schön, dass ihr hier seid. Hallo Ulzi, freut mich.
Ja, es ist ja eine ganz besondere Folge, auch ein bisschen eine Vorweihnachtsfolge in mehreren Wagen. Es gibt nämlich auch ein kleines mögliches Geschenk in dieser Folge. Wir haben ja zu viert eine dritte Auflage, ist es die dritte? Ja. Ja, Gott sei Dank. Gut, denn alle guten Dinge sind drei. Die dritte Auflage von Agile Testing, der agile Weg zur Qualität, gerade fertig geschrieben, fertig gezaubert und per 8. Dezember, glaube ich, ging es jetzt auch live in den Handel damit.
Und ja, ich habe gesagt zu viert, Nummer vier ist leider krankheitsbedingt heute ausgefallen, Christian Mastnack, der jetzt nicht dabei sein kann. Wir werden das zu dritt jetzt auch schaffen, uns ein bisschen über das Thema zu unterhalten, über das Buch und warum wir eigentlich unsere Freizeit mit Bücherschreiben verbringen. Genau, und ja, Auflage drei, wenn ich mich so richtig erinnere in der ersten Auflage, Manfred, du warst ja so ein bisschen der Initiator dieses Buchprojekts.
Vielleicht magst du uns mal reinholen, warum eigentlich? Warum ein Buch über agiles Testen? Ja, was war eigentlich sozusagen das Initiale, die Initialzündung dazu? Das war zehn Jahre her, also vor zehn Jahren, glaube ich, 2013 oder so, ist die erste Auflage erschienen und das heißt, man beginnt ja natürlich dann schon mit den Gedanken und mit der Arbeit noch ein bisschen früher, vielleicht 2012, 2011.
Und damals kann man sagen, war es so, dass wir in einigen Projekten und bei einigen Kunden auf einmal gehört haben, so, wir brauchen jetzt keine Tester mehr, weil wir arbeiten jetzt agil. Und da habe ich mich gleich geschreckt, als eingefleischter Tester, aber auch agil denkender Mensch. Und ich habe gesagt, so kann es ja nicht sein. Woher kommt das?
Und ich habe dann immer vermutet, es muss ein Übersetzungsfehler vom Englisch ins Deutsche sein, weil in den agilen Büchern wird halt immer vom Development Team geschrieben und in Österreich zumindest versteht man den Developer quasi den klassischen Programmierer. Und nachdem das dann eben nur mehr im agilen ein Programmiererteam ist, braucht man also keine Tester mehr.
Als Gegenreaktion habe ich mir gedacht, na, jetzt muss ich da eine Lanze quasi für den Test auch in agilen Situationen, in agilen Projekten und Projekten und gesagt, müssen wir so ein Buch "Agiles Testen", "Agile Testing" haben wir es dann genannt, schreiben, weil ich einfach davon überzeugt bin, dass man sowohl die Profession Testingenieur in agilen Vorhaben benötigt. Und natürlich hat sich seither in den letzten zehn Jahren vom Mindset her schon wieder vieles geändert.
Also diese damalige Sicht, okay, wir kommen ohne Test eigentlich raus, das passiert alles einfach durch die Entwickler. Ich glaube, davon ist man weg. Und es ist auch weg von den damals noch sehr individuellen Projekten hin zu eher komplexen, skalierenden Vorhaben. Da hat sich schon einiges getan und eigentlich gewandelt.
Daher auch die Notwendigkeit, das Buch ein bisschen zu überarbeiten und vom damaligen Mindset und der initialen Gedanken ein bisschen wegzuentwickeln auf die jetzigen und zukünftigen Herausforderungen in Test in agilen Projekten. Jetzt ist ja, also da sind ja jetzt über zehn Jahre, wie du sagst. Und bevor wir vielleicht dazu kommen, auch was hat sich denn jetzt getan? Warum brauchen wir eine dritte Auflage?
Martin, du bist doch ja auch sehr stark mit dem ISTQB verbandelt als Präsident des Austrian Testing Boards jetzt. Ich bin in den Working Groups auch tätig mit dem ISTQB. Wenn du da auf das Thema agiles Testen schaust und von damals bis heute, wenn wir mal diesen Strang noch aufmachen, was ist denn da so deine Erfahrung? Was hat sich denn da getan?
Ja, das Spannende da ist eigentlich, wenn du so mit so Experten auch aus der ganzen Welt zusammen, kann man wirklich sagen, aus der ganzen Welt, von Sri Lanka bis Kanada rauf, dann ist das ganz witzig, dass man sagt, naja, agil ist ja der Standard. Ich glaube in Japan, Korea, die haben dann gesagt, nö, also agil ist für uns kein Thema. Okay, gut, soll es auch geben.
Aber witzig war, dass wir gesagt haben, Foundation Level, also wenn du sagst, was muss ein Tester wissen, machen wir nicht mehr die Unterscheidung zwischen agil und nicht agil, weil einfach agil inzwischen ein Oberbegriff ist für viele Good Practices, die sich bewährt haben. Und wir haben dann auch festgestellt, uns fällt langsam schwer zu sagen, das ist eindeutig agil und das ist, ich meine, nehmen wir mal DevOps, ist DevOps jetzt agil?
DevOps hat ja einen unheimlichen Einfluss auch aufs Testen. Also wir haben uns ja auch im Buch dann entschieden, nicht zu sehr auf DevOps einzugehen, weil da gibt es ganz tolle Bücher dazu. Ja, aber die Connects von Test zu DevOps haben wir schon gut beschrieben. Einfach ein wichtiger Teil, aber ist das jetzt agil oder nicht agil? Und wir haben uns dann entschieden, nö, wir machen einen Lehrplan für alles, was gutes Testen ausmacht. Es gibt gutes und schlechtes Testen.
Es gibt nicht mehr agil oder nicht agil. Und von daher war es für mich auch spannend, wieder ein Buch zu schreiben, was bewusst sagt, agiles Testen, weil agil eigentlich jetzt im Common Sense angekommen ist und jetzt man so ein bisschen aufpassen muss, wo ist noch das Gute und wo hat es sich einfach nicht bewährt. Manfred, du hast ja angesprochen, dieses "Hey, wir sind alle ganz tolle Tester. Ich bin ein Developer, der von Anfang an agil denkt und nicht nur agil, sondern an Qualität.
Okay, ich kenne zwei, drei Leute, Manfred, du vielleicht auch, die wirklich als Lead Developer diese Qualität haben. Aber das ist mehr eine pathologische Qualität, als dass der wirklich methodisch gut vorgeht. Und das hat sich einfach nicht bewährt. Und manche anderen Dinge, dieses Vier-Augen-Prinzip, da guckt noch einer drauf. Automatisierung hat sich auch komplett verändert. Auch das musst du dann mit reinnehmen.
Ich glaube, leider ist Christian Massnack jetzt nicht bei uns, der könnte einiges zu sagen, aber Thema Tool-Unterstützung, da hat sich natürlich viel getan. Wobei die Grundprinzipien, habe ich so das Gefühl, sind doch sehr ähnlich. Man muss es nur ein bisschen anders metten. Aber ich glaube, so insgesamt, ISTGoB, finde ich interessant, dass man international auch sagt, es gibt Good und Bad Practices.
Und wenn ein Tester was lernen muss, ist es jetzt mal richtig, er muss natürlich Agiles kennen, genauso wie er auch Wasserfall kennen muss, aber nicht mehr so einfach als Background. Aber in Testen haben sich auch aus dem Agilen viele Sachen bewährt, die auch in unserem Buch wieder beschrieben werden. Ich fand es eigentlich ganz nett, dass jetzt Agile Testing eigentlich so der Common Sense geworden ist. Und ich glaube, Manfred, wir haben ja auch lange überlegt, wie nennen wir das nicht Agile?
Das ist jetzt langsam schwierig. Früher war klar, das Normale und dann die agilen Typen da. Oder wie auch immer. Das war traditionell. Jetzt musst du umgekehrt überlegen. Moment. Ich meine, ich habe ja immer ein Problem gehabt mit diesem Begriff Wasserfall, weil ich bin jetzt, glaube ich, ba, bald 40 Jahre in diesem Business und war gefühlt nie in einem Wasserfallprojekt, sondern es waren immer iterative, wenn man so will, Projekte.
Und irgendwie hat sich die Agile Bewegung quasi einfach den Wasserfall als Antibode hingestellt damit. Den will niemand hinunterfallen, den Wasserfall, und wo man nie mehr zurück hinaufkommt. Es waren eigentlich immer iterative Projekte, was sich halt natürlich geändert hat im Verhältnis zu der Geschwindigkeit der Iterationen und der Kürze und der Umfang der einzelnen Iterationen.
Und was für mich einfach auch jetzt auch für das Buch oder in dem Buch natürlich auch wichtig ist, das war durchaus auch das Selbstverständnis des Testingenieurs, ich nenne ihn jetzt mal so, in den Projekten.
Also auch vielleicht wieder zurückblickend auf Erfahrungen von vor zehn Jahren, da habe ich teilweise dann eben auch mit Testerkolleginnen und -kollegen gesprochen, die haben gesagt, ja, sie sind in einem agilen Projekt, dann habe ich das Gedacht, wie geht es euch dann sozusagen mit diesem Sprintplaning und mit diesem Planning-Poker und was es da so alles gibt, und dann sind sie nicht mit dabei, das machen die anderen. Da habe ich gesagt, da stimmt was nicht in dem Agilenteam.
Entweder ist man Teil des Teams als sozusagen Test-Developer, wenn man so will, oder eben nicht, also außen vor, ihr dürft auch noch ein bisschen mitmachen, aber mitreden dürft ihr nicht.
Nein, also das ging schon auch in den Jahren um die Emanzipation sozusagen des Testingenieurs in diesen Projekten, es ist schon ein bisschen einfach ein Sinneswandel, es ist nicht, man ist nicht derjenige, der irgendwann am Schluss hintendran dann nochmal die Feuer, oder die Kohlen aus dem Feuer holen soll, sondern man gestaltet das Projekt von Anfang an mit, ist voll dabei und gleichwertig ist und emanzipiert ist, Mitglied dieses Entwicklungsteams.
Also das ist ein Thema, wie integriert und wie bin ich Teil eines Agilenteams. Da gibt es keine Unterscheidung zwischen den anderen Rollen.
Ein weiterer Aspekt und das ist denke ich auch sehr wichtig in vielen Projekten, die ja nicht nur ihre Closed-Shop haben, das geht irgendwann einmal auch nach außen und das ist gerade auch im Test so sehen, wir sind viel bei vielen Kundensituationen, auch die Integration der Fachbereiche in die Testaktivitäten, also überall dort, wo es dann in die Abnahme von Business-Szenarien geht, oder wenn es in die EPICs oder wenn es wirklich darum geht,
vielleicht Geschäftsprozesse mit abzuprüfen und das in irgendwelchen Safe-Value-Chains oder wie auch immer, dann ist es wichtig, auch hier mit der Umwelt, das Projekt aus den Fachbereichen, das kann aber auch, was man sieht, der Betrieb sein, beispielhaft hier auch mit zu integrieren in diese Aktivitäten und Tätigkeiten.
Also ich denke, auch dieser Aspekt ist ein sehr wichtiger und etwas, was halt bei diesem, was mir da auch immer am Herzen liegt, ist mit Agile Testing, wenn man agile Testverfahren mit anwendet, dann heißt das ja nicht, dass alles andere obsolet ist. Das hat mich immer ein bisschen gewundert und geärgert, fast schon, dass man auf einmal gesagt hat, das ist agil, da brauche ich das, was ich da meist, die Kopie gelernt habe, nicht.
Wenn ich jetzt sage, ich bin jetzt agiler Tester und ich habe keine Ahnung von Äquivalenzklassen-Tests oder Trendswert-Tests oder sonst irgendwas, dann mache ich auch was falsch, weil das sind ja gelebte Praktiken, Techniken und getrainierte Techniken, die ich ja genauso in agilen Tests vorgehen, wenn man so will, anwenden kann. Wenn ich explorativ etwas teste, dann kann ich genau auch diese Technik und soll sie ja anwenden.
Das ist ja nicht nur ein Herumspielen, schauen Sie, was ich schaffe innerhalb eines Sprints, sondern ich hoffe, auch im agilen Umfeld ein ingenieurmäßiger Test. Insofern, und das adressieren wir eben auch in diesem Buch, dass man sagt, okay, das ist alles das Handwerkszeug, wenn man so will, das muss man beibehalten. Und das kann man kreativer vielleicht umsetzen in den agilen Szenarien.
Wo natürlich, ganz kurz, weniger vielleicht wieder wert ist im Sinne von, wie ausführlich, wie detailliert beschreibe ich jetzt einen Einzeltestfall? Das wird man wahrscheinlich jetzt nicht mehr so, wie man es vielleicht früher gemacht hat. Aber je nach Szenario, wenn ich sage, ich habe dann vielleicht im Parallel irgendwo auch Automatisierer, die das dann umsetzen wollen, was ich hier habe, dann wird man es detailliert beschreiben.
Aber es geht sehr auch zu dem Thema Lean und Lean-Management auch im Test. Also mach nur das, was notwendig ist, um das Ziel bestmöglich zu erreichen. Ja, ja. Jetzt hat Martin, du hast es ja vorher auch so schön gesagt, es ist Common Sense jetzt, Agilität. Und wir haben jetzt, weiß nicht, dieses Jahr haben ja einige gefeiert, 20 Jahre Agilität, wenn man das so mal so groß aufschlagen will. Wieso, warum dieses Jahr eigentlich? Ja, ich weiß gar nicht.
Es gab ein paar Termine, die man da heranziehen kann. Und wir haben zehn Jahre das Buch. Martin, was hat sich denn deiner Meinung nach am agilen Testen in den letzten zehn Jahren, was waren denn so die drei Punkte, die sich verändert haben, die jetzt auch natürlich in dem neuen Buch auch irgendwie aufschlagen? Ja, also Manfred hat es einmal angesprochen, die Schnelllebigkeit. Also das schnelle Reagieren auf Anforderungen close to market ist nochmal anspruchsvoller geworden.
Es gibt sicherlich ein paar Ausnahmen. Ich habe zur Zeit gerade an einem Projekt zu tun, das da absolut die Ausnahme ist. Aber dieser Druck, ganz schnell zu reagieren, der ist schon sehr groß geworden. Und damit natürlich auch technologisch auch Handwerkszeug zu haben, mit der Testautomatisierung relativ schnell zu werden. Ich glaube, die Testautomatisierung hat sich auch sehr stark gewandelt.
Ich habe es ein bisschen auch mit manchen Herstellern schon diskutiert, die auch merken, ihre Werkzeuge müssen irgendwie dynamischer werden. Aber die Testautomatisierung agiert auf hohem Niveau. Jetzt ist einfach die Frage, wie integriert sich das in Continuous Integration? Also ich finde, den zweiten großen Punkt neben diesen häufig close to market und hohen Zyklen ist auch DevOps-Thematik.
Und ich finde, die ist eigentlich total spannend, weil man dort wirklich versucht, Leute zusammen zu bringen. Aber für mich ist DevOps, wie gesagt, ein Kulturthema. Also ich erlebe jetzt unheimlich viele Unternehmen, die haben eine DevOps-Abteilung. Das ist delegiert. Das ist so, wie ich früher auch immer meine Testabteilung hatte. Das waren die Qualitätssicherer irgendwo im 17. Stock. Die waren irgendwo weit weg vom Projektgeschehen. Und DevOps ist leider auch jetzt genauso missverstanden.
Aber das, finde ich, ist noch ein großes Thema, das auch Tester sehr stark mit dem Betrieb zu tun kriegen. Also es war immer auch schon ein Problem, wie kriegen Tester überhaupt mit den Leuten zu tun, die es anwenden? Das ist ja auch so ein Thema gewesen. Ist aber ganz gut im Agilen abgedeckt worden. Aber das Thema ist, das Betreiben der Software und auch vor allem die nicht-funktionalen Aspekte sind inzwischen sehr viel wichtiger geworden für Tester.
Also Security ist ja eines der Hotspots in der Qualität, finde ich jedenfalls. Also Richie, ich glaube, du kannst da auch ein Lied von singen bei den Interviews, die du führst. Und da ist auch die Rolle des Testers plötzlich eine andere. Das ist nicht nur unbedingt mehr der Fachbereich, verstehe ich, sondern der muss umfassend sehr breit aufgestellt sein. Und dann hast du nur ein paar Nerds, die dann einfach in die Tiefe gehen.
Das habe ich so das Gefühl, weil einfach wirklich die Anforderung an Tests ist jetzt sehr spezifisch geworden. Und ich glaube, das sind so Dinge, die wir dann auch in unserem Buch einfach auch mit unserer Rolle, auch mit den Tools gemerkt haben. Da müssen wir darauf reagieren jetzt stärker. Wobei ich will jetzt auch nicht sagen, dass sich alles verändert hätte in den letzten zehn Jahren.
Das ist ja das Schöne, dass man sieht, unsere Grundidee hat sich ja auch durchgesetzt, zu sagen, der Tester hat eine Rolle. Richie, du hast ja selber dich mit der Rolle des Testers nochmal sehr intensiv beschäftigt. Ich weiß nicht, ist die so viel anders geworden? Sie ist schon anspruchsvoll. Aber das war sie vorher auch. Ich könnte es jetzt nicht sagen. Also ich glaube wirklich, die hohen Zyklen sind natürlich sehr anspruchsvoll für Tester.
Die starke Spezialisierung und überhaupt, wie man so in DevOps mit der Komplexität klarkommt. Ich glaube, das sind so die drei Dinge, die ich sehe. Aber ich weiß nicht, seht ihr da andere Sachen? Ich weiß nicht. Ich sehe da auch Ähnliches. Also es hat sich in den letzten Jahren, wir sehen ja das auch immer, welche Skills, welche Profile werden von uns als Dienstleister hier auch angefordert und angefragt. Da hat sich schon dieses Technical Test, das ein bisschen herausgearbeitet.
Also ein Tester, der sich eben auch, der sich auskennt mit Abi-Schnittstellen und diese Dinge zu testen, der mit den Entwicklern reden kann, gleichsam natürlich auch mit den Fachbereichen. Also die, oder auch in den DevOps-Szenarien weiß, was sich da tut und zumindest mal punktuell auch Testautomatisierung. Also die technischen Anforderungen sind hier schon gestiegen Richtung den Testingenieurs. Das ist schon auch da so eine Betrachtung.
Aber das ergibt sich eigentlich auch aus dem gesamten Verfahren. Ja, hohe Integration und Gespräche mit Entwicklern, mit den Architekten und so weiter und so fort.
Dann gilt es natürlich, ich warte ja jetzt nicht mehr ein halbes Jahr, bis ich einmal eine fertige Applikation habe, die ich dann von der Oberfläche her einfach durchteste, entsprechend meiner Spezifikationen, sondern ich bin unter Umständen gezwungen, so halbfertige Produkte nachher in jedem Sprint zu testen und brauche da halt vielleicht meine Werkzeuge und Tools, um wirklich über Schnittstellen oder über das, was man der Entwickler bereitstellt, auch zu testen.
Und daher hat sich diese Entwicklung eigentlich schon ein bisschen abgezeichnet und sie ist eigentlich voll da. Das ist eines, was aus meiner Sicht im Moment auch noch nicht so richtig gut funktioniert, aber vielleicht täusche ich mich da auch. Das ist tatsächlich quasi diese Test- und Testorganisation und Qualitätsorganisation, wenn man sozusagen von den atomaren Projekten hin zu integrierten Systemlandschaften geht.
Also wenn man schon in der Skalierung, das ist ja ein bisschen mit dem Ganzen nachgefolgt, diese Save-Programme und diese, wie nennen sie das, diese Value-Streams, die sind dann vielleicht auf Epic-Level. Aber wer tut das dann? Wie ist das zu organisieren? Und genau genommen ist ja sowas passiert und ist das immer noch ein bisschen dabei.
Das ist also das V-Modell im agilen Testvorgehen, wo man ja zuerst auch auf der linken Seite hinuntergestoßen ist und sich die agilen Teams da unten in der V-Spitze bewegt haben. Und jetzt kommt man halt auch drauf, naja, es ist ja kaum so eine kleine Applikation für sich existent. Es gibt dann immer wieder die Umsysteme, es integrieren sich komplexe Systeme und wer sichert jetzt wirklich, jetzt bin ich auf dem aufsteigenden Asti-V-Modell, wer sichert jetzt gesamt das Funktionieren der Systeme?
Und da gibt es schon auch noch viele sozusagen Diskussionen in Unternehmen, die sich quasi hier auf den agilen Weg begeben haben und dann auf einmal draufkommen, hoppala, da fehlt mir jetzt wieder etwas, was früher vielleicht so ein Testzentrum der Hochkommer zumindest virtuell abgedeckt hat.
Da muss man sich jetzt zusammenraufen und schauen, wie teste ich jetzt quasi, ich sage es jetzt provokant, den aufsteigenden Ast im agilen V. Braucht es vielleicht dann noch ein Spin-Off der agile Systemintegrations-Test oder so? Es gibt sogar agile Integrationstest-Teams, habe ich auch schon erlebt.
Also deren eigentliche Aufgabe eigentlich eine Entwicklungsaufgabe ist, nämlich diese ganzen brutalen vielen Systeme miteinander zusammenzulöten und dann festzustellen, dass leider doch Masse und Vertausch ist. Und das kann man natürlich auch agil machen und das braucht dann auch wieder Tester. Du hast vorher die Rolle des Testers noch angesprochen, Martin, das fand ich auch schon. Ich merke das auch bei mir, wenn ich schaue, was hat sich in den letzten zehn Jahren geändert.
Also ich merke, dass das Thema der Qualität, agiles Grundprinzip ist ja, jeder ist verantwortlich für Qualität, aber wir wissen auch, wenn jeder verantwortlich ist, ist niemand verantwortlich. Ja, genau. Schönes Prinzip, danke. Ich denke, das ist jetzt schon immer mehr angekommen. Das heißt, für mich ist es, wenn ich in ein Team reinkomme, auch immer zu sehen, wie interagieren die.
Weil der Entwickler macht ja ganz viel auf Qualitätsseite mit Unitests, mit Code Reviews, mit statischer Analyse, mit Pipapo, mit Vorbereitung für Automatisierung oder die Umsetzung. Und da muss das Test-Know-How mit dazu, dass das quasi eins wird. Also dieses Zusammenspiel, dieses Verwachsen dieser zwei Professionen, ein Tester, der entwickeln kann, ein Entwickler, der testen kann. Also dass man da wieder viel mehr zusammenkommt.
Und das Zweite, was für mich ganz stark war, was ich auch versucht habe, in den Bereichen zu adressieren, ist durch diese ganze Komplexität in dem ganzen Testen, und der Test ist natürlich auch immer so ein bisschen unter Strom und unter Stress, muss was machen, weiß nicht, wie viel, wie viel teste ich, was mache ich, wo Automatisierung, dass man, glaube ich, in dem ganzen agilen Kontext auch sehr stark um die persönliche Entwicklung geht.
Wie kriege ich die Leute denn auch mental fit, diese Dinge zu bewältigen, zu machen und noch immer open-minded, zukunftsoptimistisch, lösungsorientiert da auch ranzugehen und nicht da zu sitzen und zu sagen, oh nee, nicht schon wieder was Neues. Also dieser Change-Prozess, und der trifft, ich finde, das ist etwas, was noch gutes Augenmerk bedarf, weil da bleibt auch viel liegen auf dem Weg.
Wobei ich erlebe da bei vielen Testern nach wie vor Neugierde, weil sie es einfach auch über die letzten Jahre so gewohnt sind. Es hat sich dauernd immer irgendwas verändert. Und du siehst ja auch an deinem Podcast, das Interesse ist groß, einfach zu gucken, was gibt es da Neues und so weiter, will man dran sein. Also ich glaube, die Neugierde, muss ich zumindest sagen, die ich erlebe, ist nach wie vor da,
aber es gibt natürlich so latent die Angst, jetzt auch gerade mit JGPT bzw. überhaupt mit AI, werden wir da überflüssig. Ich meine, die jetzt als alter Hase würde ich sagen, sicher nicht, weil die Tester waren schon immer überflüssig und sind es dann doch nie gewesen. Sogar Testmanager werden gesucht wie blöde, wurde auch gesagt. Das war doch das Erste, was ich abgeschafft hätte. Aber du merkst, das Management darüber fühlt sich total unwohl.
Und du hast ja safe auch angesprochen, die bauen ja ein riesen Framework darüber auf, bis das steuerbar ist, was da passiert, hin zu einem komplexen Produkt. Und also ich glaube, die Rollen verändern sich inhaltlich, ja. Und wer neugierig bleibt, und ich glaube, das haben wir in unserem Buch ja auch reingebracht, immer wieder kommt es kleine Impulse, aber grundsätzlich bleibt der Auftrag immer noch dasselbe. Es muss gemanagt werden, es hilft alles nichts.
Es muss einer nochmal so drüber gehen und sagen, was machen wir hier eigentlich. Du hast es vorhin angesprochen, nicht zu sagen, toll, ihr macht tolle Arbeit in den agilen Teams. Aber am Ende, ja, also letztens hat mich einer angesprochen, wir testen da gerade was, das werdet ihr später bei euch im Test mitverwenden. Und wer zeigt euch eigentlich, dass das, was wir erstellen, ja, also was durch unsere Applikation ins System gebracht wird, bei euch weiterverarbeitet werden kann.
Ganz normale Testaufgabe, nur so verteilt über Projekte, dass diesen Blink erstmal gar keiner sieht, ja. Und wahrscheinlich erst nachher beim Zusammenbauen, dass die Systemintegratoren dann wahrscheinlich die Krise kriegen, weil sie dann plötzlich merken, da geht gar nichts mehr.
Und genau diese Herausforderung einfach mal anzunehmen und zu sagen, wow, da muss einer drüber gucken, braucht es einen Testmanager, der einfach sagt, Leute, es ist gut, dass wir das hier machen, aber schaut, da drüben gibt es noch die, die müssen wir zusammenbringen. Und dann hast du oben das Management, sagt, wie weit sind wir? Was haben wir jetzt geschafft, ja?
Und die Agilen haben sich so Mühe gegeben, aber es ist schön, dass da drüben bei zehn Leuten was geschaffen wurde, aber das Management interessiert am Ende der Gesamtgeschäftsprozess. Und da sind zehn, zwölf Teams beschäftigt, von denen keiner so genau weiß, ob die aufeinander zurennen, ja. Und da merkst du dann plötzlich, Gesamtqualitätssicherung wird wieder ein Riesenthema.
Und schon hast du wieder einen Testmanager und musst dir wieder mit Liza Crispin überlegen, wie managen wir den ganzen Krempel. Und das ist spannend, dass so Themen immer wieder hochkommen. Also es gibt schon Konstanten in der Softwareentwicklung, finde ich schon. Aber du hast schon recht, die Techniken und die Anforderungen, die ändern sich schon rasant. Aber ich glaube, solange jemand neugierig bleibt, machen wir da nicht so Sorgen, ja. Ja, das war ein schöner Ding.
Ich würde gerne zum Abschluss noch jeder von euch einmal kurz so, sagen wir, der große Wunsch für Tester in Richtung Agilität. Was gebt ihr dem für einen Tipp mit? Wenn es so jetzt, der steht vor euch und ihr seid die Lösung. Was würdet ihr dem so mit auf den Weg geben? Einen Tipp, kurz und knackig. Lest das Buch. Das war jetzt gemeint. Nein. Natürlich auch. Aber vielleicht noch einen zweiten.
Aber was ich mir schon noch wünsche, ist, dass man auch, also zwei Dinge in Wirklichkeit, sich in den Teams wirklich diesem Thema der Qualität sozusagen zu verschreiben und wirklich hier zu schauen, dass die Dinge, das, was man produziert, was geliefert, so gut wie möglich, optimal wie möglich ist. Und dass man sich immer wieder auch auf die agilen Testtechniken und das Engineering besinnt.
Also dass das nicht einfach, okay, ich schaue, das, das, sondern wirklich ganz bewusst auch so Session-based Testing einfach mal wirklich tut, sich wirklich überlegt, wie ich das aufsetze und mit wem diese Verfahren zu nutzen. Und das unter Anwendung erlernter Testtechniken, wie wir sie einfach alle kennen. Und sich das immer wieder besinnen, das zu tun. Ich weiß, es ist manchmal gar nicht so einfach. Oft testet man einfach nur sofort sich hin. Die Fehler kommen sowieso einhergeflogen.
Oft muss man gar nicht vielfach machen. Aber dass man sich da wirklich schaut, dass man das ingenieurmäßig betreibt, auch immer geben kann. Ich würde den Leuten eher den Tipp geben, in sich selbstbewusst zu sein als Tester mit den Techniken, die man kann und mit aus inneren Selbstbewusstsein heraus, anderen zu helfen, das zu verstehen, nicht so belehrend von oben, aber wir müssen das noch testen, sondern die anderen mitzunehmen.
Auch, dass sie zumindest verstehen, was ich da den ganzen Tag tue oder vielleicht sogar selber das von mir mit übernehme, mich mit sich mitreißen lassen. Ich glaube, das ist gerade im Agilen unheimlich wichtig. Ich weiß, es gibt Projektumfelder, da geht sowas nicht. Aber das ist dann eher ein grundsätzliches Problem.
Aber ich glaube, Selbstbewusstsein und aus diesem tiefen Selbstbewusstsein nach außen sehr verständnisvoll und schon auch erklärend, eher coachend mit den Leuten umgehen, ohne mit dem erhobenen Zeigefinger. Weil der erhobene Zeigefinger kommt immer dann, wenn ich von oben runter gucke, weil ich selber mir nicht so sicher bin, ob ich richtig liege. Einfach in sich ruhend den Leuten sagen, hey, lass uns doch mal das genauer analysieren.
Ich hatte das letztens, da wurde eine Prüfung von Fachexperten mit Entwicklern zusammen entwickelt. Ganz tolle Idee. Einfach so eine Plausi-Prüfung. Direkt am lebenden Objekt. Sie kriegen diesen Antrag, welche Prüfregel kann da verletzt werden. Und das haben sie entwickelt. Und die Prüfregeln wurden einmal auf positiv getestet, also dass die Prüfregel anschlägt. Das ist bei einer Prüfregel, wenn das Fleck J ist, dann ist es falsch.
Einfach. Aber die Prüfregeln waren im auskodierten Code teilweise, glaube rein von den Zweigen, oder Faden, hätte ich da glaube ich 17, 18 Farbe gesehen. Und dass man dann einfach die Leute beiseite nimmt und sagt, lass uns mal eine Entscheidungstabelle machen, dann zeige ich dir, was du alles aus dieser Prüfung rausholen kannst. Und da geht schon manchen einfach ein Licht auf und sagen, wow, da wäre ich nie drauf gekommen. Ich hätte einfach geguckt, ob die Prüfung.
Und in diesem Sinne einfach die Leute mitnehmen. Faszinierend eher dafür zu sagen, wow, nicht so sagen, du musst da mit Entscheidungstabelle, sondern einfach sagen, schau, ich nehme dich mal mit auf eine Reise und schaust dir mal an und vielleicht ist es was für dich. Und der ein oder andere reagiert ja dann auch, sagt vielleicht auch, was soll ich noch alles machen, aber ist spannend. Ja, super, danke.
Ich würde da noch abschließen mit einem kleinen Tipp, nämlich immer auch drauf zu schauen, was bringt es denn eigentlich, was ich da mache. Wir haben ja, also das Buch strotzt ja auch vor Methoden und es gibt natürlich ganz viele Dinge, die man tun kann in dem ganzen Bereich des agilen Testens, in Testautomatisierung, in all diesen Prüfungsvarianten.
Aber auch mal zu schauen, wir können ja nicht alles machen, wirklich zu hinterfragen, ob denn diese Tests, die ich gerade mache, ob denn das wirklich irgendeinen Impact hat oder irgendeinen Mehrwert, der das bringt. Weil das ist so nach meiner Erfahrung leider nicht immer der Fall. Also da darf man auch mal kritisch drauf schauen. Ja, lieber Manfred, lieber Martin, vielen Dank, dass ihr hier wart. Wir wären ja nicht der Podcast.
Dann hätten wir nicht auch wieder drei Exemplare, druckfrisch, quasi ganz warm, wie die Morgensemmelbrötchen zur Verlosung hier. Die Infos gibt es in den Show Notes. Ich danke euch herzlich, dass ihr Zeit euch genommen habt hier für den Podcast. Leider konnte Christian nicht dabei sein, da werden wir vielleicht mal nochmal nachlegen, spätestens bei der nächsten Auflage. Dann schauen wir uns das nochmal an. Und ja, vielen Dank, ich wünsche euch noch alles Gute und noch eine schöne Weihnachtszeit.
Ja, euch auch. Und danke, Ritschi. Danke. [Musik]