Hallo und herzlich willkommen zu einer neuen Folge von Podcast Software Testing. Ich bin euer Host Ritschi und heute bei mir zu Gast Jörn Münzel und Steffen Schild. Beide wirkten in der Arbeitsgruppe zum Berufsbild-Testen im German Testing Board mit und mit ihnen spreche ich darüber, welche Skills man als Tester heute braucht, was sich verändert hat gegenüber der letzten Jahre und wie man seine Testerkarriere heute planen kann. Und jetzt viel Spaß bei der Folge.
Hallo Steffen, hallo Jörn, schön, dass ihr da seid. Hallo Ritschi. Ja, hallo Ritschi. Schön, dass du da bist. Ja, ich freue mich, dass ihr hier im Podcast zu Gast seid und mit mir heute auch ein Thema betrachtet, also ein bisschen so ein Blick auch auf die Rolle des Testers heute auch und was der eigentlich so macht. Wir sind im Podcast immer sehr tief in irgendwelchen technischen Themen drinnen und da schauen wir heute mal noch einen anderen Blick drauf.
Das finde ich sehr, sehr praktikabel und da würde ich sagen, wir werfen uns einfach mal rein ins Getümmel. Steffen, ich gebe dir einfach mal vielleicht das Wort. Was, als Mann der Industrie, was sind so gerade das Thema Herausforderungen, Tester wie unseren Testing Qualität? Das ist eine gute Frage, weil das Testen an sich ändert sich nicht. Die Anforderungen
ans Testen ändern sich nicht. Was sich ändert, ist die Arbeitsweise. Wie wir arbeiten, wie wir zusammenarbeiten, wie wir als Team immer mehr diesen Team Gedanken finden, wie wir agil natürlich arbeiten. Klar, das ist ja die Ausgangslage und was sich da ändert, ist das Verständnis für den Tester oder für das Testen an sich und deswegen war das eine super Idee, dieses Berufsbild mal zu überarbeiten und sich mal damit zu beschäftigen, was wir eigentlich
machen. Ich bin selber Tester. Ich bin selber seit 10, 20 Jahren im Testbetrieb aktuell unterwegs und dieser Wandel ist auf der einen Seite super, weil er uns endlich das gibt, was wir schon immer haben wollten. Auf der anderen Seite ist es aber genau dieses Problem, sich wieder zurecht zu finden. Wie finden wir uns als individueller Tester sozusagen in einem Team wieder, was agil
arbeitet und wo keine individuellen Tätigkeiten eigentlich mehr da sind? Das war der Anstoß, das mal ganz intensiv zu Gemüte zu führen und darüber nachzudenken, wie können wir damit umgehen. Vielleicht bleiben wir da noch mal kurz so ein bisschen in der Historie, machen wir ein bisschen Vergangenheitsbewältigung. Wie war es denn früher als Tester, wenn du sagst, es hat sich gewandelt?
Früher hast du als Tester deine Aufgaben über den Zaun geworfen bekommen, deine Requirements und dann hast du die Software bekommen, die irgendjemand anders entwickelt hat und dann hast du sie getestet. Du hast dann deine Testfälle geschrieben und hast die Testfälle durchgeführt und hast dann angefangen, die Bugs zu melden. Ab da wurde es dann unangenehm. Das war die frühere Arbeitsphase, also mehr dieses sequenzielle, dieses Nacheinanderarbeiten. Das ist jetzt ganz anders geworden.
Das ist natürlich ganz viel durch das agile Thema der letzten, sagen wir mal, es gibt ja auch schon 20 Jahre, das ist ja nicht neu, aber ich glaube auch dem Tester, dem ist es relativ schnell auf die Füße gefallen, weil man auch gemerkt hat, dieses viele manuelle Herumtesten, so in einem Sprint ständig Regressionstests zu machen, also die alten Konzepte, das hat nicht mehr so gut funktioniert auf einmal. Nein, das funktioniert nicht mehr und es ist auch gut so, dass es nicht
funktioniert, weil es war nie gut so, wie es war. Es hat immer diese Zusammenarbeit gefehlt, dieser Austausch mit den anderen Kollegen, dieses Verständnis dafür, was ist denn Testen eigentlich? Es ist ja nicht der Tester, sondern es ist das Testen, was stattfinden muss. Natürlich ist es eine Person oder die Person des Testers, der Beruf des Testers, der das Testen ausführt. Oder nicht? Das ist genau die Frage, weil eben dieses "oder nicht" ist, glaube ich, genau der richtige
Ansatzpunkt. Es ist nicht die Person, es ist das, was getan werden muss, um die Qualität sicher zu stellen. Und da geht es jetzt darum eigentlich, und das ist jetzt die Schwierigkeit, glaube ich, die Skills zu finden, die diese Tätigkeiten des Testens möglichst effizient und möglichst gut
umsetzen. Welche Personen können diese Skills erfüllen, ausüben? Und das ist jetzt dieser Wandel, wo wir uns als klassische Tester, als Testpersonen wiederfinden, wo sich auch die anderen Kollegen im Team wiederfinden, dass es eben nicht mehr die eine Person ist, die dafür zuständig ist, sondern dieses "whole team approach", was vor ein paar Jahren so gehypt hat, aber genau den Kern trifft. Weil Tester haben noch nie Fehler eingebaut. Oder doch, weil sie
nicht frühzeitig darauf achten konnten, dass sie nicht eingebaut werden. Und jetzt ist die Frage, wie kriegt man das hin? Welche Skills brauchen wir? Wann brauchen wir diese Skills im Software Entwicklungsprozess? Das ist gerade das, gerade natürlich seit 10, 20 Jahren. Aber je intensiver es eingesetzt wird, agile Vorgehensweisen, desto prägnanter wird es und desto mehr trifft es die breite Masse. Ich würde da gerne nochmal eingreifen, weil ich finde das sehr gut,
was Steffen gerade gesagt hat. Ich denke, es sind zwei Kriterien für mich, die da sehr stark auch eine Rolle spielen. Das eine ist im Prinzip eine Organisation, die auch effektiv und effizient arbeiten will. Und auf der anderen Seite sind es halt auch Menschen, Personen, Individuen, die sich einbringen wollen. Und das ist ja halt auch, ich denke für uns, also für mich persönlich, auch ein großer Lerneffekt der Agilität gewesen. Natürlich ist es erst mal alles im Team.
Aber mit der Zeit haben wir doch gelernt, manchmal ist das Team zu klein, manchmal hat es doch nicht die ganzen Kompetenzen, die es braucht. Und manchmal ist auch das Produkt zu groß, dass man auch nicht mit einem Team auskommt. Dann kommt man doch wieder in die Organisation. Man muss vielleicht doch Releases bauen. Man muss das ganze Thema Testumgebung komplexer sehen. Man
muss halt auch die Themen Testautomatisierung detaillierter sehen. Also es kommen ja Anforderungen rein, dass das Spektrum der Personen, die man braucht, ja ein sehr breites ist auf der einen Seite, um effizient wirklich zu arbeiten. Und auf der anderen Seite, die Leute sich natürlich auch persönlich als Wissenden wiederfinden wollen. Also nicht nur sozusagen Indianer im großen Dorf sein, sondern man will ja für sich persönlich auch eine Weiterentwicklung erreichen. Das heißt,
man muss sich selber halt auch überlegen, wo sind meine persönlichen Schwerpunkte. Und das in Kombination halt mit den Zielen der Agilität, das ist, denke ich, halt schon eine Herausforderung für jede Organisation auch. Das ist spannend, was du da sagst. Du bist ja seit vielen Jahren im German Testing Board auch aktiv, also die Vertretung des IST-Copy für Deutschland
sozusagen. Und das IST-Copy kommt ja auch ursprünglich mal aus der alten Welt. Ich meine, das sieht heute anders, aber die ursprünglichen Zertifizierungen, die haben das ja sehr klassisch alles auch adressiert. Wie hast denn du quasi aus dieser Zertifizierungssicht, aus dieser Lernschicht das wahrgenommen in den letzten 20 Jahren? Wie hat sich denn das verändert? Wie ist denn da der Bedarf gewachsen oder ist er sich angepasst? Ja, der Bedarf ist ja sehr stark
gewachsen. Also wie ich, ähnlich wahrscheinlich wie du, vor 10, 15 Jahren auch in Kontakt gekommen bist intensiver mit dem ganzen Lehrplan des IST-Copy. Da war das ja auch noch überschaubar von der Anzahl der Lehrpläne. Aber im Prinzip gerade so 2012/2013 fing das ja sehr stark an, dass aus 4, 5 Grundlehrplänen 15 Lehrpläne geworden sind. Und wir uns damals im GTB schon angefangen haben,
Gedanken zu machen, wer braucht die eigentlich? Ja, wir bauen Lehrpläne, weil wir denken, das macht Sinn, weil das Themen sind, über die man lehren kann, wo es sehr gut ist, wenn man Wissen aneignet, um in der Praxis gut arbeiten zu können. Aber auf der anderen Seite fehlte sozusagen ein bisschen der Überbau. Und das war halt auch beim GTB die Idee, dieses Berufsbild aufzusetzen und sich mal zu überlegen, welche Aufgabenbereiche gibt es eigentlich im Testen?
Und was braucht man eigentlich für die verschiedenen Aufgabenbereiche? Und das, wenn man sich vertiefen will, auch sozusagen Spezialisierung stattfinden. Klassisches Beispiel, was, wenn ich mich mit Testautomatisierung auseinandersetze, da muss ich halt verschiedene Werkzeuge lernen. Ich muss halt programmieren lernen oder ich komme aus der Programmierung
und lerne das Testen. Aber ich werde vielleicht nicht der Testanalyst oder ich werde auch nicht der Testmanager, der jetzt ein Konzept macht oder eine Planung mit 10, 15, 20 Leuten macht. Und das hat eigentlich bei uns ein bisschen dazu geführt, dass wir uns überlegt haben, welche Einflussfaktoren gibt es eigentlich und wie kann man das mal strukturiert auch darstellen?
Und das hat halt zum ersten Berufsbild 2017 geführt, was wir halt jetzt auch mit Hilfe von neuen Kollegen wie zum Beispiel Steffen halt auch jetzt vor ein, zwei Jahren überarbeitet haben, weil einfach das Thema Agilität und damit auch das Beiseiteschieben von Rollen, wie wir es jetzt in dem neuen Berufsbild bezeichnet haben, mehr mit Positionen. Also
mit einer Position ist eine Aufgabe, die ich für eine Zeit verantwortlich übernehme. Das heißt aber nicht, dass ich sozusagen mein Leben lang in dieser Position verharre, wenn es mir natürlich Spaß macht, vielleicht. Aber gerade der agile Teamgedanke erwartet ja auch, dass man zu unterschiedlichen Zeitpunkten unterschiedliche Schwerpunkte hat.
Steffen hat es angedeutet. In der Anforderungsdefinition oder wenn wir sozusagen Backlog-Analyse machen, dann sind es halt mehr die Randbedingungen zu testen, vielleicht Acceptance-Kriterien zu entwickeln und solche Punkte. Und wenn es nachher sozusagen in die Umsetzung geht, muss auch Testautomatisierung, Testdatenmanagement, solche Themen halt, Testumgebungsmanagement muss halt damit reinkommen. Du hast jetzt schon die ersten Skills oder Themen ja auch schon mit angesprochen,
Steffen. Aus der Praxis heraus, was würdest du denn sagen, wenn wir da mal tiefer reingehen, was sind denn so die Skills, die Positionen, die man heute in so einem agilen Team als Test irgendwas dann einfach auch haben sollte? Das ist eben das. Es ist sehr vielschichtig. Es war schon immer sehr vielschichtig,
aber es ist nicht so wahrgenommen worden. Und jetzt gerade mit dieser zeitweisen Tätigkeit, wenn wir jetzt auch kleine Dinge nur entwickeln, kleine Features, einzelne Features statt das ganze Produkt fertig machen, sondern das so stückweise aufbauen, inkrementell aufbauen, dann ändern sich tatsächlich die Anforderungen an das, was getan werden muss.
Sowohl das, was implementiert werden muss. Also mal ist es eine Datenbank, die man aufbauen muss, mal ist es eine Oberfläche, die man neu macht oder erweitert, mal sind es die Schnittstellen zwischen Frontend und Backend, die zusätzlich eingebaut werden. Mal ist es irgendein Hardware-Teil,
was man anschließt an ein existierendes Gerät. Mal ist es irgendeine Komponente, die ausgetauscht wird, die effektiver wird, wenn wir an Kommunikationskanäle sprechen, dann Kaka eingesetzt und dafür werden andere serielle Übertragungswege dann abgeschaltet. Und das alles wird von einem Team entwickelt und das sind genau die Sachen, die im Team vorhanden
sein müssen. Das technische Verständnis dafür, auch bei einem Modell. Das heißt, auch vor allem bei jemandem, der eine Testaffinität hat, der dieses Qualitätsgedanken so verinnerlicht hat, der muss natürlich das Big Picture verstehen. Er muss Analyse-Fähigkeiten haben. Er muss verstehen oder herausbekommen können, herausarbeiten können, wie das zusammenpasst alles. Ob es da Inkonsistenzen gibt zu dem, was schon da ist in Bezug auf das, was wir einbauen,
also diese analytische Fähigkeit. Es ist dann aber auch die technische Fähigkeit, wie ist denn die Technik, die wir jetzt gerade implementieren, was hat das denn für Auswirkungen auf unser bestehendes System oder auf das, was danach kommen wird. Weil wir sind ja nicht fertig, wir machen ja Stück für Stück. Also kommt auch noch irgendwas, was dann auf dem aufbaut, was wir jetzt gerade machen. Wie ist das denn mit Blick in die Zukunft. Dieses technische
Verständnis muss da sein. Und die analytische Fähigkeit im Sinne dann auf die Testtätigkeit an sich. Also, wir haben das vorhin schon gesagt, die Testdaten zu erzeugen, was ja die Grundlage dafür ist, dann für die Testfälle, die wir erstellen. Das baut ja im Prinzip alles auf unterschiedlichen Testdaten auf, die sich dann unterschiedlich auswirken und unterschiedliche Reaktionen herauskitzeln aus dem System. Diese Testdatenerzeugung, diese Analyse,
dieses Testdesign sozusagen. Also das Design von dem, wie wir unsere Qualität sicherstellen wollen. Und jetzt ist schon dieser Begriff Test ist eigentlich schon rausgefallen. Es geht um diese Qualität, die wir entsprechen wollen. Und natürlich, Testautomatisierung ist wichtig für agiles Vorgehen. Das ist natürlich auch was. Irgendjemand muss diesen Testfall, den jemand
entworfen hat, weil jemand etwas analysiert hat, muss diesen Testfall dann implementieren. Und das kann jetzt der Tester sein, der entweder, weil er das sowieso schon kann, weil er aus der Programmierung gekommen ist und jetzt sich einen Test beschrieben hat, wie es bei mir war. Oder der mehr aus der nicht technischen Richtung gekommen ist, der sich für das Testen interessiert hat und
jetzt plötzlich vor der Herausforderung steht, ich muss jetzt programmieren können. Oder ist es vielleicht sogar der Programmierer, der sowieso im Team ist, der halt dann das Programmieren des von jemand anders entwickelten Testfalls erledigt. Also hier haben wir vielleicht sogar oder ganz sicher sogar oder sinnvollerweise je nachdem so eine Aufsplittung der Tätigkeiten tatsächlich auf verschiedene Personen, je nach Skill. Das ist aber auch das Spannende und das ist das,
was uns die Möglichkeit gibt, uns weiterzuentwickeln. Indem wir diese Spezialskills uns auf die Fahne schreiben. Ich möchte das selber automatisieren können, also muss ich selber programmieren lernen oder wieder aus der Modenkiste auspacken, weil ich es früher mal
gemacht habe. Da kann ich mich weiterentwickeln. Ich muss mich mit der Technik intensiv beschäftigen, also muss ich mich technisch weiterbilden oder ich muss jetzt mich mit Schnittstellen beschäftigen, also muss ich mich in Richtung REST oder API oder wie auch immer die Frameworks heißen,
weiterentwickeln. Und dann, wie wir uns vorhin angesprochen haben, diese Ausbildungspfade, die klassischen, die dann immer mehr erweitert worden sind durch Spezialausbildungen zum Performance-Tester, zum Security-Tester, zum Game-Tester, zum Testautomatisierer und so weiter. Das ist genau das, was jetzt eigentlich diese Nischen bildet, die wir entweder aufgreifen können, weil es uns persönlich interessiert, die wir aufgreifen müssen, weil es wichtig für das
Team ist und es sonst keiner macht. Das ist das, was jetzt das Ganze wieder zusammenfügt. Ja, aber ich würde es gerne noch ein bisschen ergänzen. Auf der einen Seite zusammenfügt, aber auf der anderen Seite halt auch die Breite zeigt, die man braucht. Das heißt also auch, wenn man wirklich effizient Qualität produzieren will, muss man halt trotzdem
auch ein bisschen planerisch dabei sein. Nicht jeder ist in der Lage, sich selber so weit zu bilden, dass er das vielleicht alles kann und nicht jeder ist auch gewillt, sagen wir mal, vom Testanalysten bis zum Testmanager bis zum Testautomation-Engineer alles zu machen, weil es einfach auch ihm keinen Spaß macht. Also ich denke, wir müssen hier immer ein bisschen einerseits das Team und die Organisation sehen, denen zum Beispiel jetzt so ein Berufsbild als
Referenzidee Hilfe gibt. Was gibt es für Aufgaben? Was brauche ich für Leute? Aber natürlich auch den Leuten Hilfe gibt zu sagen Ja, was gibt es denn eigentlich und wo finde ich auch Hilfe? Also wo finde ich jetzt Lehrpläne, wo ich mich spezialisieren kann? Wo finde ich Ausbildung, die ich noch brauche? Und das ist auch nicht immer nur, sagen wir mal, ICQB Certified Tester Programm, sondern das haben wir auch ganz klar gemacht. Da gehört halt Domänenwissen dazu. Da gehört Technologiewissen
dazu. Da gehört Prozesswissen dazu und natürlich Testwissen. Wir als ICQB können beisteuern im Bereich des Testwissens, aber gerade da, wo es dann mit Werkzeugen losgeht, sind wir natürlich auch nicht mehr da. Da kommen dann die Werkzeughersteller, die spezialisierte Kurse anbieten oder es kommen andere Bereiche, die halt unterstützen, Wissen anzusammeln. Trotzdem macht es natürlich Sinn,
sich vorher zu überlegen, was brauche ich eigentlich oder was passt auch zusammen? Ich denke, wenn ich jetzt Performance Kurs mache und Security Kurs macht und Safety Kurs macht, das passt nicht unbedingt alles zusammen. Damit verbessere ich mich eigentlich vielleicht in der Breite, aber ich werde trotzdem nicht besser, weil ich auch für gewisse Themen Erfahrung brauche. Ich
meine, das stellen wir jetzt auch ganz klar in dem Berufsbild dar. Wissen ist eine Sache. Können und es gemacht haben und die Erfahrung gesammelt haben, ist natürlich eigentlich die wichtigere Sache. Ich meine, jeder erinnert sich vielleicht an die Schule zurück. Wir haben viele Sachen in Mathematik gelernt. Manches braucht man nicht, aber manches mit manchem hat man gute Erfahrungen gesammelt. Ich meine, also so ein Dreisatz hilft manchmal schon im Leben, wenn man ihn gelernt
hat. So ähnlich ist es halt auch mit den Testen. Da sind natürlich auch, wie Steffen es gesagt hat, gerade wenn wir es schaffen, Programmierer zu bringen, sich auch mal mit Testthemen auseinanderzusetzen, dann ist für die das Programmieren einer Testautomatisierung natürlich nicht mehr das Hexenwerk, weil sie sozusagen das Konzept dahinter verstanden haben. Das ist ein ganz spannender Punkt, weil ich habe gerade letzte Woche wieder mit
Kollegen gesprochen über genau diese Problematik. Ein Programmierer dazu zu bringen, sich mit Testen zu beschäftigen, das ist ganz spannend. Das ist wichtig, weil der Programmierer ist Teil des Teams
genauso wie der Tester. Also muss auch er sich mit Qualitätssicherung beschäftigen, also damit beschäftigen, die bestmögliche Qualität zu liefern und wie macht man das, indem man vielleicht Testmethodiken anwendet, die klassisch immer nur bei den anderen waren, weil die hatten das auf der Visitenkarte stehen und plötzlich bin ich aber als Teil des Teams eben
auch dafür verantwortlich. Da ist schon dieses Knowledge Sharing das Entscheidende. Aber auch aus der anderen Sicht, diese Idee einen Programmierer oder einen Analysten oder einen UX Designer oder wen auch immer wir im Team haben, dazu zu bringen, sich mit diesen Basics, also diese Testmethoden, die wir im ZDFL oder in anderen Sachen lernen, die tauchen natürlich im ZDFL auf, aber so eine Äquivalenzklassenanalyse, so eine Entscheidungstabelle, ich erzähle das immer
wieder in unseren Community Meetings und so, das ist das, was ein Programmierer sowieso auch machen muss, weil wie kann er denn sonst seine If-Then-Else-Schleifen aufbauen oder seine Methoden strukturieren, seine Architektur aufbauen, wenn er nicht diese Entscheidungstabelle, diese Kombinatorik im Kopf hat. Und deswegen tut er das schon, was wir als Tester auch machen. Es
ist nur nicht bewusst. Und dieses Bewusstsein zu schaffen, das ist der Weg, wie wir aus meiner Sicht tatsächlich auch andere Disziplinen in Richtung Test bringen können, indem wir mal aufzeigen, das, was du tust, ist ja schon Testing. Jetzt musst du das nur noch konsequent anwenden und alles ist gut, sozusagen. Und genau dafür ist nämlich auch so eine Aufstellung, mal so eine Zusammenfassung der notwendigen Skills für diese Qualität, die wir haben wollen. Wann
brauchen wir diese Skills? Wer kann sie ausüben? Und das ist so wichtig, das zu haben, weil das sehr wenige Leute auf dem Schirm haben. Gerade wenn du dich mit Recruitern unterhältst oder mit jungen Ressources unterhältst, die dafür da sind, die richtigen Leute zu finden. Auch hier ist dieses Bewusstsein nur sehr sporadisch verbreitet. Wie sind denn die Zusammenhänge? Was ist denn tatsächlich die Skills, die jemand benötigt, den wir jetzt suchen, um eine Testerstelle
zu besetzen? Und noch viel schlimmer, wie du es vorhin angesprochen hast, ein Team zusammenzustellen, was ein Gewerk umsetzt. Was brauche ich da für Skills drin? Und da ist gerade so eine Zusammenstellung, wie wir es in diesem Berufsbild gemacht haben, aus meiner Sicht so wertvoll, weil da kann man mal nachlesen. Man muss nicht alles wissen, aber man muss wissen, wo es steht. Und da hat man sowas und da kann man sich dann aus so einer Zusammenstellung tatsächlich auch
sich sein Team zusammensuchen und die Skills finden, die wir im Team brauchen. Und dann matchen wir das auf die Stellenbewerbungen, die eingehen oder wir matchen das dann auf die Profile in LinkedIn oder in Xing, die hinterlegt sind bei potenziellen Kandidaten und suchen dann über das, was klassischerweise als Testertätigkeit verstanden wird, hinaus interessante Leute,
die das sowieso schon machen, was wir brauchen. Deswegen finde ich das so wichtig, mal so ein großes Big Picture auch im Testing zu haben, was da alles zusammengehört. Finde ich super spannend, weil du es quasi auf die Ebene noch bringst. Und was da, finde ich, auch noch drinsteckt, du hast es am Anfang gesagt, ist, dass sehr viel implizit ja schon da ist. Also viele Entwickler nutzen solche Dinge schon, viele Business Analysten nutzen diese Methodiken
schon. Und das ist, wenn man das im Lehrplan sieht, Äquivalenzklassen, was ist denn das? Aber es ist ja, das ist einfach tägliches Doing und viele Tester, die jetzt noch nicht zertifiziert sind, die machen das auch schon, die machen das halt intuitiv. Und dieses Bewusstsein dann auch mal, es ist eigentlich vieles schon da und das einfach bewusst zu machen, finde ich da auch sehr wesentlich. Ich würde dir ja sehr voll Recht geben. Das war halt auch so ein bisschen
die Idee eigentlich, dass man das einfach mal transparent macht und aufstellt. Und auch, was Steffen eben schon gesagt hat, was wir also schon sozusagen testerweise praktiziert haben, sozusagen auch mal gute Aufgabenbeschreibungen aus dem Schema zu machen. Dass man einfach sagt, was brauche ich eigentlich? Und man hat eine Vorlage und muss sie natürlich an seinen Kontext anpassen. Da steht natürlich nicht drin, um welche Domäne es konkret geht, aber steht drin,
ich brauche Domänenwissen. Und wenn ich Testanalyst bin, dann muss ich halt vertieft auch wissen, worum es fachlich, funktional auch geht. Ja, oder wenn ich Security mäßig was machen will, dann muss ich halt schon den Kontext, muss die Technologie kennen, in welchem Umfeld das stattfindet, was die für Technik einsetzen. Das kann ich spezialisieren. Aber ich habe ein Template und habe eine Idee, um zu sagen, okay, was brauche ich eigentlich? Brauche ich jetzt einen Testanalysten,
brauche ich einen Testengineer, brauche ich einen Testautomation Engineer? Und auch in welcher Verantwortung brauche ich ihn? Brauche ich ihn, weil ich jetzt was programmieren muss oder muss er wirklich auch mal konzeptionell arbeiten? Also hat er eine verantwortliche Position? Das heißt, sollte er auch gewisse Erfahrungswerte mitbringen und sowas? Und umgekehrt kann das natürlich auch jeder für sich selber nutzen, um zu sagen, wo stehe ich eigentlich? Was kann ich? Wo fühle ich mich
gut? Und daraus Ideen entwickeln aus der Perspektive und sagen, vielleicht sollte ich mich doch noch mal in diesem Thema spezialisieren. Ich habe jetzt Foundation Level gemacht. Ich habe in fünf Projekten gearbeitet, mal als Testanalyst oder mal auch schon mal als Testkoordinator oder Testmanager oder sowas. Aber ich würde mich eigentlich sehr stark für Performance interessieren. Das ist so ein Thema, was mir Spaß macht. Dann könnte ich mich halt gucken, werde ich, ob ich doch nicht eher
verantwortlicher Spezialist werden will, der vielleicht auch mehr Projekten arbeitet. Ich meine, gewisse Tätigkeiten oder Skills hat man auch in Organisationen eher Projekt- oder Team-übergreifend sinnvollerweise. Es gibt ja diese Center of Competence oder je nachdem, wie man sich organisiert. Und es gibt halt Leute, die im Team sind und dort vielleicht
aber auch verantwortlich sind. Und ich sage mal, drei Business-Analysten führen, die jetzt halt den Abnahmetest durchführen, die vielleicht die Basis gelernt haben und die halt den Experten im Hintergrund haben, wenn sie eine Frage haben. Jetzt ist eine Sache, das finde ich ganz schön, was wir da jetzt auch noch mal auf diese Skis geguckt haben. Was mir so ein bisschen fehlt,
um auch den Bogen zu schließen. Was ist denn mit den ganzen Management-Skis? Sind die denn da auch drinnen, die schönen Schätzmethoden, die ich alle gelernt habe, Steuerung, Maßnahmen, Metriken, Reports, Konzepte und so was? Wie sind denn die da drin? Vielleicht könnt ihr da noch mal kurz drauf eingehen. Die sind natürlich auch drin. Also was wir auch reinschreiben ist, an das Thema heranzugehen, ohne einen Plan zu haben, ohne ein Konzept zu haben, bringt nichts.
Ja, ich denke, das haben wir auch in den letzten 20 Jahren der Agilität gelernt. Ich brauche auch ein Häuptling oder ein paar Häuptlinge vielleicht im Team. Wobei das verteilt sich. Vielleicht ist der eine heute Häuptling, weil er das Testmanagement macht und den Test konzipiert oder plant. Morgen ist der Nachbar wieder der Häuptling, weil es um Backlog-Analyse geht und ich brauche die
Business-Kompetenz. Und beim nächsten dritten Tag ist der Häuptling derjenige, der vielleicht der Chef-Programmierer oder erfahrenste Programmierer ist, der dann halt sagt, okay, wir nehmen dieses Tool und dieses Framework. Ich denke, und das ist halt für das Testen, für den Bereich Testen genauso wichtig, wenn ich keine gewisse Expertise habe und einen Plan wenigstens als Modell im Kopf
habe, dann renne ich halt irgendwo hin. Klar, es gibt immer verschiebbare Leitplanken, aber das ist ja auch der Vorteil der Agilität, dass ich vielleicht nach zwei, drei, vier Wochen Zurückblick sage, war das gut so oder war es nicht gut so? Und ich ein Jahr lang arbeite und erst dann feststelle, dass ich falsch gerannt bin. Aber trotzdem brauchen wir natürlich Leute, die auch planen können, diese Tätigkeiten und auch diese Wissenskomponenten haben. Wobei die natürlich auch, da komme ich
jetzt wieder zurück, für jeden im Team sinnvoll sind. Wenn ich ein gewisses Gefühl entwickel, wie schätze ich irgendwas ab oder wie erzeuge ich auch mal einen gescheiten Report, weil ich den fundiert auch unterlegen kann durch eine Metrik. Das ist klar, das ist jetzt mal, ich sage mal, Testerhandwerk, aber das sind Basics, die wahrscheinlich sehr schnell auch jeder andere versteht und lernen kann. Genauso umgekehrt, wenn ich jetzt vom Testen her vielleicht komme und ich
habe einen guten Programmierer, der mich anleitet, wie ich das programmiere. Ich bin ja auch als Tester, kann ich ja nicht sagen, igitt, igitt, programmieren tue ich nicht. Und genauso umgekehrt als Programmierer kann ich heute auch nicht mehr sagen, nee, ich teste nicht. Also ich denke, aus dieser Denkschematik, die wir vor 20, 15, 15, 20 Jahren sehr stark hatten, müssen wir raus oder sind wir raus. Aber wie Steffen ganz am Anfang gesagt hat, die Probleme und die Aufgaben bleiben.
Das ist der Punkt. Diese Management-Tätigkeiten, die du angesprochen hast, das ist was, was im Agieren erstmal, also je nachdem, wenn wir das, was die meisten machen, Scrum nehmen oder sowas, gibt es das nicht mehr. Das taucht nicht auf als Rolle. Das ist einfach nicht da. Aber das muss jemand tun, weil gerade Scrum braucht Planung ohne Ende. Wenn du Scrum machst, ohne einen Plan zu
haben, dann lass es bitte sein, weil das wird nicht funktionieren, auf gar keinen Fall. Da stehst du in drei Wochen da oder sechs Wochen da, weil du doch ein bisschen das verstehst und merkst, dass es eher schlimmer wird als besser. Deswegen diese Planungstätigkeiten, diese Management-Tätigkeiten, die müssen gemacht werden. Es gibt halt nur nicht mehr den, der Manager auf der Visitkarte stehen hat. Das ist auch einer der Skills, die im Team vorhanden sein müssen.
Und deswegen ist genau das, was Jörn gesagt hat, das ist ein Thema, was in die breite Masse geht. Je nachdem, wie du als Mitarbeitender jetzt in dem Team bist. Letztes Jahr warst du in einem anderen Team. Nächstes Jahr machst du ein anderes Projekt. Du hast andere Kolleginnen, du hast andere Leute, mit denen du zusammenarbeitest. Du hast eine andere Branche,
du hast einen anderen Kunden, der vielleicht andere Stick, andere Prozesse hat. Das heißt, einmal muss das Team diese Tätigkeit mehr fokussieren, einmal muss es auf eine andere Tätigkeit mehr fokussieren. Aber die Leute, die im Team sind, die müssen das machen. Und deswegen ist auch dieses Management-Wissen bei jedem aufgehoben. Jeder muss im Prinzip Management-Fähigkeiten haben. Mal mehr, mal weniger. Niemand kann alles wissen. Das ist
unrealistisch. Aber es kann passieren, dass du der bist, gerade in diesem Team, der vielleicht am geeignetsten ist, einen Plan aufzustellen. Um das Wort Management zu vermeiden. Einen Plan aufzustellen, eine Abfolge, den Prozess zu verbessern oder erst aufzustellen. Die Reihenfolge vielleicht mit voranzutreiben, wie wir was machen. Wer abschätzen kann, ob wir das auch in den Sprint reinbekommen. Oder man lässt es lieber für den nächsten Sprint, weil wir sind eigentlich schon
voll. Es kann sein, dass das dich heute dicht trifft. Im anderen Team ist vielleicht jemand anders, der mehr dieses Standing hat. Den gab es im letzten Projekt nicht. So wechseln die Aufgaben, die du hast. Das ist auch eine ganz gute Karrieremöglichkeit, wenn man so will. Nicht
mehr diese klassischen Karrieren. Du hast immer diese Position inne. Aber wenn du dich weiter bildest, wenn du dich engagierst, wenn du dich in eine Richtung fortbildest, dann ist es umso wahrscheinlicher, dass auch im nächsten Projekt du derjenige bist, der diese Tätigkeiten verantwortet oder vorantreibt. Es ändert sich, aber trotzdem, dieser Karriereweg ist immerhin da, weil jemand muss es machen. Das hat eine schöne Überleitung gebracht, nämlich zu meiner Abschlussfrage,
die ich mir für heute so überlegt habe. Steffen, wenn ihr so einen Tipp habt für einen Tester, für eine Testerin, die jetzt da so über sich im Projekt ist und sagt, was will ich denn eigentlich in Zukunft, wo könnte es denn hingehen? So ein Tipp, wie können die sich orientieren, welche Idee würdet ihr da mitgeben? Ja, ganz einfach erst mal. Die einfachste Antwort. Wir haben ja dieses Berufsbild als Dokument auf der German Testing Board Homepage hinterlegt. Da kann
man reingucken. Das muss man nicht von vorne nach hinten durchlesen. Das kann man sich mal angucken, Ideen holen. Es gibt da auch einen zweiseitigen Abstrakt dazu auf der Homepage in Deutsch und in Englisch beides als Einstieg, als Ideengeber. Wir haben dort auch so ein bisschen diesen Ansatz gesagt. Wie kann ich das Ganze nutzen, um mich persönlich weiterzuentwickeln? Das ist halt auch,
ich meine für mich immer so der klassische Deming Circle, DuPlan, Act, Check sozusagen. Also, dass man sich einen Plan macht, was könnte sein, dann halt aber auch regelmäßig sich selber wieder reflektiert, was mache ich eigentlich und was will ich machen? Wo liegen meine Stärken? Was macht mir Spaß? Da, ich denke, ist es ein Preis. Also, gerade wenn man sagt, okay, Testen ist für
mich die Basis. In dem Bereich möchte ich tätig sein, weil Analyse mir Spaß macht, weil Prüfen mir zweiter oder sozusagen das Vier-Augen-Prinzip ich für sehr wichtig halte, dass man einmal über Ideen halt auch jemand noch mal drüber guckt. Ist das wirklich eine gute Idee oder ist es halt nur eine Idee oder eine schlechte Idee oder es fehlt noch was? Ja, und wenn man das hat, dann kann man quasi da, ich denke, eine ganze Menge Anregungen finden. Ist hinuntergebrochen zu konkreten Kursen,
die man halt auch dann auch machen kann. Das haben wir halt auch eingebaut, aber in erster Linie geht es ein bisschen darum, sich zu überlegen, wo sind eigentlich meine Stärken, Schwächen, was will ich? Und das muss im Prinzip im Endeffekt jeder selber machen. Da kann man von außen nichts geben. Ich meine, da kann man höchstens vielleicht sagen, Kollegen fragen, du hast Erfahrung da drin oder man guckt, ob man jemanden, gerade auch bei den Testing Boards, jemanden findet oder ASQF. Es
gibt ja gewisse Circles, wo man einfach auch mal mit Leuten reden kann. Ich habe das schon öfters gemacht mit Kollegen, mit denen ich dann einfach diskutiert habe, was hast du bisher gemacht, was hat dir Spaß gemacht, was hast du gut gemacht und wo willst du dich weiterentwickeln? Und dann kann man das Referenzschema nehmen und kann sagen, okay, vielleicht ist das Thema Test Datenmanagement jetzt was, was dich sehr stark interessiert oder Testautomatisierung,
weil du gerne an der Schnittstelle zwischen Technik und Qualität stehst. Aber das ist eine sehr individuelle Sache aus meiner Sicht. Super, danke schön. Steffen, du noch einen abschließenden Tipp. Kann ich mich anschließen an dem, was Jörn gesagt hat? Es muss immer bei, oder sollte immer bei sich selber anfangen. Gerade wenn wir agil arbeiten, schaut euch an, was passiert bei euch im Team und zwar aktiv. Agilität ist eine aktive Tätigkeit. Deswegen muss man aus sich rausgehen.
Man muss sich bewusst sein, dass man dort ist, weil man die Person ist, die dort das Team weiter bringt. Das ist so. Jeder macht das. Wenn du das mal verinnerlicht hast, dann schau dir an, was passiert im Team. Wo krankt es? Hast du Ideen, das verbessern zu können? Was gefällt dir am meisten? Was macht dir am meisten Spaß, wie Jörn gesagt hat? Das gibt es ja, weil du kannst ja jede Tätigkeit im Prinzip machen im Team. Schau dir an, was macht dir Spaß?
Möchtest du da weiterkommen? Möchtest du dich intensiver damit beschäftigen? Dann sprich mit jemandem darüber oder nimm dir mal so eine Aufstellung, wie wir es jetzt im Berufsbild testen haben. Schau dir mal an, was kannst du? Was möchtest du? Was ergeben sich daraus für Weiterentwicklungsmöglichkeiten? Einmal in Sachen Fortbildung, aber auch vor allem in
Sachen Seniorität, also in Sachen Professionalität. In Sachen, was ich vorhin gesagt habe, dieses Verantwortung übernehmen für einen kleinen Bereich, für einen etwas größeren Bereich, für einen viel größeren Bereich. Das ist das, was ich als Karriere bezeichnen würde. Da kann in der Tat so ein Berufsbild super helfen. Das andere, da möchte ich Jörn ein bisschen widersprechen. Das ist eine individuelle Sache, aber auch als Teamlead oder auch als
Personalverantwortlicher kannst du das genauso machen. Du kannst dir anschauen, was machen denn deine unterschiedlichen Leute in den einzelnen Projekten? Was gibt es für andere Leute in den Projekten? Schau dir mal an, wie so etwas mit einem Berufsbild oder einer anderen Aufstellung passt. Was passt da zusammen? Ich merke, der ist in der Sache gut. Dann könnte
ich ihm doch mal den Weiterbildungskurs empfehlen oder mal mit ihm überreden. Du willst dich in dem Bereich mehr Verantwortung übernehmen, weil ich es nachschlagen kann, weil ich ja auch nicht der Experte bin als personalführende Person. Dann bin ich nicht der Fachlegexperte. Aber ich kann mir mit so einer Aufstellung eine Orientierung holen und dann mit der Kollegin darüber sprechen. Super. Das sind zwei tolle Tipps noch zum Abschluss hier. Ich glaube,
die können gut mittragen. Wir werden das natürlich auch alles verlinken, überall, wo wir es haben, mit dem Berufsbild und so, dass da auch jeder schnell Zugriff darauf hat. Lieber Steffen, lieber Jörn, vielen Dank, dass ihr heute hier im Podcast wart. Das war eine sehr spannende Folge, glaube ich, für das ganze Thema. Was macht ein Tester heute eigentlich und wo kann es hingehen? Ich glaube, das hat mir auch noch mal ein schönes Bild darauf gegeben und das, denke ich,
wird auch der Community gut gefallen. Da wird auch das eine oder andere Feedback dazu kommen. Vielen Dank, dass ihr da wart. Ich wünsche euch noch eine schöne Zeit und sage bis zum nächsten Mal. Ich freue mich auf ein Wiedersehen. Gerne. Vielen Dank auch dir. Und willkommen. Hat Spaß gemacht. Super. Ciao. Ciao. [Musik]