Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Heute machen wir mal Perspektivwechsel. Bei mir zu Gast Philipp Huber, Business Analyst bei einem Data Warehouse Projekt. Also er war nicht immer Business Analyst. Früher habe ich mit ihm zusammen in Testprojekten zusammen Testfälle geschrubbt.
Wie er Qualität in seiner Rolle lebt, welche Herausforderungen er hat und wie die Test- und Qualitätssicht in frühen Phasen der Softwareentwicklung helfen kann, darüber habe ich mich mit ihm unterhalten. Viel Spaß bei der Folge. Hallo Philipp, schön, dass du da bist. Hallo Richard, danke für die Einladung. Ja, wir kennen uns ja schon ein paar Jährchen. Kann man so sagen. Wir haben ja schon ein bisschen was hinter uns an gemeinsamer Testerfahrung von früher. Und damals noch beide im Testing.
Im Software-Testing tief unterwegs, in allen Facetten Testfälle geschrieben und durchgeführt. Und jetzt ist es ja so, wenn ich jetzt in deinen Lebenslauf reinschaue, du machst jetzt mit Testen ja gerade nicht mehr so viel, sondern du hast die Seiten gewechselt sozusagen. Ja, genau. Ich habe die Seiten gewechselt. Ich bin jetzt Business Analyst.
Genau, und das ist natürlich eine spannende Sicht auch mal zum einen einfach jetzt auch darauf zu schauen, was hast du denn da so mitgenommen quasi aus der Tester-Sicht mit in deine BA-Rolle und zum anderen auch, was kannst du denn dort gestalten mit Qualität und mit Testen? Ja, schauen wir einfach mal ein bisschen drauf.
Was würdest du denn sagen, also jetzt einfach mal auch so ins Blaue hineingefragt, als Business Analyst, was ist denn so deine größte, deine wichtigste Aufgabe, die du eigentlich machst? Was hast du denn da so für eine große Aufgabe, die du eigentlich im Softwareentwicklungsprozess leistest? Tja, also wenn ich mit Leuten spreche und die vielleicht nicht so IT-ner sind und ich versuche denen das zu erklären, habe ich immer ganz einfache Erklärungen.
Es ist vielleicht etwas phasierend ungenau, man kann darüber diskutieren, aber ich mag sie trotzdem. Und zwar das ist als Tester habe ich immer geschaut, ob das richtig ist. Als Business Analyst sage ich, was richtig sein soll. Irgendwie passt das, glaube ich, ganz gut. Das ist natürlich viel komplizierter. Und der grobe Vereinfachung. Ich denke aber, dass man aus beiden Seiten viel mitnehmen kann.
Also ich merke oft in der Analyse, dass mir die Testsicht durchaus weiterhilft, weil du tust dann zum Beispiel so Grenzfälle, genau die Sachen, wo du als Tester genau hinschaust. Genau sowas überlegst du dir dann auch, was du vielleicht als, ich sage jetzt mal, nur gelernter Business Analyst vielleicht nicht so im Fokus hast. Ich muss ehrlich sagen, ich bin mein Testerhut nie ganz losgeworden. Also ein bisschen bin ich da immer noch involviert. Vor allem, weil es ja auch im selben Projekt ist.
Also da ist dann oft so, dass ich dann vielleicht nochmal um Rat gefragt werde von den Testern. Es sind auch Test-Tools, die ich geschrieben habe, wo teilweise auch noch Sachen von dir drinnen sind. Also wir haben irgendwo noch immer das Ritchie-Match-Skript im Einsatz. Schau. Ja, also. Ich sehe da sehr viel, dass das eigentlich wirklich zwei Seiten derselben Medaille sind.
Ja. Und ich denke mir auch gerade in agilen Teams, wo es dann geht um T-Shaping und dass du eben Tasks machst, die halt anfallen, ist es oft so, dass man mal da, mal da mehr den Fokus hat. Und wenn man da wirklich beide Seiten kennt und berücksichtigt und die Tools, die Methodik und so weiter gut kennt, das Produkt natürlich auch von beiden Seiten gut kennt, dann hilft das sehr viel.
Ja, ich glaube auch, es ist ja auch eine, es ist ja heutzutage ja eh nicht mehr möglich, quasi nur mehr in irgendeiner Rolle drinnen zu sein und zu sagen, ich mache nur mehr das. Also dieser ganzheitliche Blick auf den, auf einen Softwareentwicklungsprozess und auf ein Projekt, das muss einfach auch da sein bei jedem, ob das jetzt ein BA ist, ein Tester, ein Entwickler oder sowas, die alle in irgendeinem Team dann vor sich hinarbeiten.
Was würdest du denn sagen, du hast schon gesagt, so in Grenzwerte, auf was achtest du denn, wenn du in Bezug auf Qualität so deine Anforderungen schreibst oder die Spezifikationen formulierst, was sind denn da so Sachen, wo du denkst, da achtest du vielleicht, weil du ein bisschen die Testersicht auch darauf hast, noch mehr oder worauf, wo merkst du, sind manchmal einfach auch Lücken, wo man mehr drauf schauen sollte in dem Umfeld?
Ja, was ich vielleicht anders mache als andere Business-Analysten, die den Background nicht haben, jetzt in meiner Umgebung ist, dass ich versuche, den Test zu machen. Und den Test dann wirklich auch beizubringen und mitzugeben, um was es da eigentlich geht. Also was bei mir noch dazu kommt, das haben wir jetzt gerade noch nicht besprochen, ist, ich bin Business-Analyst und war davor Tester in einem Warehouse bei einer großen Bankengruppe, was natürlich ein unglaublich komplexes Produkt ist.
Und es ist jetzt nicht sowas wie, ich habe auch zum Beispiel mal für Straßenverkehrs-Unfall-Statistik gearbeitet. Jeder kann sich darunter was vorstellen. Was ist ein Unfall? Was ist ein Beteiligter? Was ist ein Unfall? Was ist ein Unfall? Aber in einem Banken-Warehouse, und das habe ich als Tester und als Junior vor allem gesehen, das war für mich mehr oder weniger ein Datengrab. Da gibt es viele Sachen, du hast aber keine Ahnung, wofür das gut ist. Und das versuche ich, den Testern mitzugeben.
Und ich versuche, sie auch dahin zu lenken und auch mit dem Input, den ich gebe, dass sie da wirklich auch hinterfragen, was wir da eigentlich machen. Und was mir da besonders wichtig ist, ist, dass die Tester auch mich, die Tester auch mich challengen. Weil es war eigentlich oft so, dass die Tester das, was von Business-Analysten vorgegeben ist, als die Wahrheit annehmen. Es ist so gemappt, die Daten müssen so fließen, diese Werte werden so und so gemappt. Das ist die Wahrheit.
Und wenn das irgendwie anders hinten rauskommt, dann muss der Code falsch sein oder mein Testfall oder was auch immer. Und das ist eigentlich nicht so, weil auch Business-Analysten machen Fehler. Und deswegen ist mir sehr wichtig, dass die Tester auch das, was sie da machen, das challengen und auch die Spezifikation in Frage stellen. Und dazu müssen sie einfach auch ein bisschen den Background kennen.
Wenn das jetzt für mich ein Datenfriedhof ist, wie ich gesagt habe, und ich habe keine Ahnung, wozu sind die Felder, wie sind die Entitäten miteinander verwandt, was bedeutet das alles? Dann kann ich das auch nicht challengen. Dann bin ich wirklich eigentlich nur auf einen sehr technischen Test reduziert. Und das ist meiner Meinung nach nicht ausreichend. Ja, man entdeckt ja auch, dass man sich nicht nur auf einen sehr technischen Test reduziert.
Ja, auch immer, also ich kann mich erinnern, so an die Testprojekte auch früher, wo wir auch gemeinsam gewirkt haben. Man entdeckt halt dann auch häufig auch einfach Probleme in den Anforderungen, gar nicht nur im Code. Das ist ja eigentlich, ich würde es vielleicht sogar fast sagen, sogar ein sehr großer Anteil, dass man Lücken aufdeckt oder Probleme aufdeckt, die einfach so nicht durchdacht waren und das einfach auch zurückspielen muss.
Und wenn ich jetzt aber nur das für bare Münze nehme, so wie du sagst, und das einfach so stupide durchführe, dann komme ich da natürlich nicht hin. Aber dann hauen alle immer nur auf den Entwickler drauf. Und ich denke, ja, also der muss das richten, aber der kann ja wahrscheinlich gar nichts dafür. Wie seid ihr denn da in der Kommunikation auch?
Also ich meine, du machst ja die Anforderungen, also du versuchst es ja zu übersetzen auch, von einer Fachlichkeit hin, dass auch ein Entwickler das versteht. Primär, ne? Und gar nicht so sehr der Tester. Also der ist ja quasi dann in zweiter Linie dann betroffen davon. Wie funktioniert das? Wie ist denn da so die Kommunikation, der Austausch, um da auch nochmal Qualität reinzubringen?
Ich versuche es so, dass ich, wenn ich jetzt Anforderungen habe und die den Tester, und natürlich auch den Entwicklern mitgebe, wir haben jetzt vor allem über die Tester gesprochen, dass ich erstens einmal erkläre, um was es geht, quasi direkte Kommunikation, auch in Calls oder in Meetings, und dass ich das aber auch die wichtigsten Punkte schriftlich dokumentiere.
Weil wir sind im datengetriebenen Umfeld und oft schaut die Spezifikation so aus, es ist ein SQL Statement, oder etwas, was die grundsätzliche Struktur von einem SQL Statement hat, was der Business Analyst übergibt ans Entwicklungsteam oder an die Entwicklungskollegen. Und ich glaube, es ist nicht ausreichend, um end-to-end die Qualität sicherstellen zu können. Das kommt dann eben wieder auch auf das Verständnis zurück, dass die hinter mir in der Kette auch ein gewisses Verständnis haben.
Sie werden nie das komplette Verständnis haben wie ich als Business Analyst, der sich Tag ein, Tag aus damit beschäftigt. Aber die wichtigsten Punkte muss man zumindest mitgeben können und sie in die Lage bringen, dass sie das challengen können. Jetzt bist du ja in einer Schnittstellenfunktion, also du überlegst dir ja die Dinge jetzt nicht per se, sondern du kriegst ja auch Anforderungen, die wahrscheinlich auf einem Geschäftslevel oder auf einem sehr fachlichen, abstrakten Level sind.
Fallen dir da, wenn du diese Sachen, die du jetzt in der Kette hast, nicht mehr verstanden hast, wenn du diese Sachen liest, über ein Tool kriegen oder sonst irgendwo in einen Workshop mitgehen, fallen dir da dann schon per se Dinge auf, da fehlt ja noch die Hälfte, da muss man nochmal ran? Ja, das kommt sehr oft vor und das ist auch eigentlich ein sehr großer Teil von meiner Arbeit, dass du die Requirements natürlich auch challengst.
Weil oft kommt jemand von Business Seite nicht unbedingt mit einem Requirement, sondern mit einer halbfertigen Lösung, wie sie es denn vorstellen. Mit sowas kommen die Leute zu dir und das ist eben oft nicht richtig. Beziehungsweise oft könnte man es noch viel besser machen und da kommt dann wieder der Business Analyst zum Vorschein, dass du dann fragst, was willst du eigentlich genau, was brauchst du? Denk nicht daran, wie die Lösung ausschauen soll, sondern sag einfach, was du brauchst.
Und das kommt durchaus sehr häufig vor. Man muss auch dazu sagen, das Umfeld, wo ich arbeite, ist relativ komplex, weil wir haben zwei verschiedene Wehrhäuser, die unterschiedlichen Fokus haben. Und oft haben wir dann Fälle, wo von der Business Seite jemand kommt und sagt, ja, das müssen wir über das eine Wehrhaus und über das andere dann schleusen und hin und her, dann kommen die Daten zurück.
Da kommt man eigentlich darauf, dass die das gar nicht brauchen und dass das viel einfacher auch gehen würde. Und das sind, glaube ich, auch wichtige Sachen, die ich dann challengen muss und auch mit dem, der die Anforderung stellt, diskutieren muss. Das ist ja ein ganz ein typisches Beispiel von, wenn man früher ein Problem schon behebt, dass es später nicht irgendwie böse Auswirkungen hat. Weil ich habe schon so viele Software-Systeme auch gesehen, wo die Rolle nicht da war.
Die Anforderung war schon die fertige Lösung, die wurde dann dazu gebaut. Und so sieht das dann auch aus. Es wird dann überall so eine Lösung noch drauf gepfropft. Die Architektur wird irgendwie unübersichtlich und überhaupt nicht mehr so, dass sie irgendwelchen Prinzipien entspricht. Und das ist natürlich schon etwas, was du auch mit verhindern kannst, schon an sehr früher Stelle, bevor überhaupt noch jetzt die erste Zeile Code dann da auch geschrieben ist. Ja, genau das stimmt.
Ich sehe das auch als unglaublich wichtig an und ich gebe mir da wirklich sehr viel Mühe, solche Situationen zu verhindern. Es geht dann teilweise auch oft darum, dass du, ich sage mal, sehr ähnliche Requirements aus unterschiedlichen Ecken hast. Im Warehouse, gerade in dem Bereich, wo ich tätig bin, da gibt es unterschiedliche Bereiche und die haben für dieselbe Sache die unterschiedlichen Fachbereiche nicht unbedingt dieselbe Sicht.
Aber trotzdem, im Warehouse musst du eigentlich eine Sicht darauf haben. Ein ganz einfaches Beispiel ist Arten von Kunden. Also in dem, was ich jetzt gerade mache, in dem Projekt, ich habe jetzt schon, ich weiß nicht, die zwanzigste verschiedene Art, wie man Kunden klassifizieren kann. Und ich denke mir, man muss da einfach genauer drauf schauen und mit den verschiedenen Fachbereichen sprechen. Wie kann man das vereinheitlichen?
Weil es bringt nichts, wenn ich im Warehouse jetzt zwei Jahre 20 verschiedene Kunden-Typen, Attribute habe. Weil das eine ist vielleicht ein Rital-Customer, das andere ist vielleicht irgendein großer Geschäftskunde. Da gibt es aber verschiedene Nodes, wie das abgestimmt wird oder unterschieden wird. Und da muss man sich wirklich als Business-Analyst Mühe geben, das so gut wie möglich hinzukriegen, weil alles, was man mitschleppt, wird man später nicht mehr los. Vor allem eben im Warehouse.
Und mit dem muss man dann leben. Deswegen lieber gleich am Anfang Mühe geben. Anstatt dann den Ballast mitzuziehen. Wie formal sind denn so deine Arbeitsschritte? Also wenn du jetzt quasi Anforderungen bekommst, sind das quasi so Schmierzettel oder irgendwelche fragilen Word-Dokumente? Oder gibt es da einen strukturierten Prozess bei euch, wo auch Qualitätssicherung im Zuge von Reviews oder so mit drin ist? Oder ist das eher so ein Flow?
Ja, da wir ja mit verschiedenen Bereichen zu tun haben, ist es auch verschieden. Also es gibt jetzt kein zentrales, ich sage mal Requirements, Erfassungstool oder sonst irgendwie einen ganz zentralen Prozess, wo das passiert. Es funktioniert mal besser, mal schlechter. Was wir sehr viel natürlich haben, sind Excel-Listen. Ich brauche diese und diese und diese Felder. Und die geht man halt dann durch. Intern machen wir es dann doch ein bisschen mehr streamlined, sage ich mal.
Also wir haben doch eigene Tools, um jetzt sowas zu tracken. Was wir auch haben, ist ein Business Data Model, was für die ganze Gruppe gilt, die ganze Firma. Und da halten sich aber auch halt manche mehr dran, manche weniger. Für manche ist das einfach nur irgendein Anhängsel, was sich irgendwer dort im Warehouse überlegt. Und für andere ist das auch wirklich, wie sie ihr Geschäft sind.
Und das macht es natürlich einfacher, wenn sich die Leute und die Abteilungen daran halten und das auch akzeptieren. Aber wir sind eine große Firma und es ist halt teilweise Kraut und Trüben. Es ist halt auch so, dass wir haben jetzt in den letzten Jahren viel getan in Richtung Agilität. Wir haben vor allem auch noch viel gemacht, was wir in der letzten Zeit gemacht haben. Und das ist natürlich auch ein sehr, sehr guter Punkt.
Wir haben früher sehr viele klassische Wasserfallprojekte gehabt und auch die Mentalität von den Leuten und das Mindset war halt teilweise noch recht altmodisch. Das hat sich jetzt geändert. Aber das heißt halt auch oft, und du weißt das bestimmt, ja, manche Leute verwechseln Agilität halt auch mit einem Sauhaufen. Und das ist dann nicht gut, weil es ist eigentlich nicht, was gemeint ist. Ja, aber es ist auf alle Fälle spannend. Man muss sich immer wieder auf etwas Neues einstellen.
Und ja, es ist aber interessant. Ja, sehr spannend. Jetzt ist es ja so, dass du ja mit der Testsicht dann auch drauf schaust auf die Anforderungen und so. Hast du denn dann schon auch oder gibst du das quasi auch schon mit, dass da schon diverse Testfälle auch mit einfallen oder auch in weiterer Linie vielleicht gleich angeschlossen daran auch das Thema Testautomatisierung?
Ich meine, das ist ja im Data Warehouse Umfeld ja auch sehr naheliegend, dass man viele Sachen nicht unbedingt mit der Hand testet. Ja, total. Das ist ein sehr großes Thema bei uns. Also Testen, Testfälle, wie komme ich an Testdaten und so weiter. Und das ist vor allem dann ein Problem, wenn du neue Anforderungen hast. Weil für neue Felder, neue Entitäten hast du im Normalfall keine brauchbaren Testdaten, weil das alles erst entwickelt wird.
Und das ist tatsächlich manchmal mitunter recht problematisch. Ich habe in der Zeit, wo ich gewechselt bin zwischen, also von Tester auf Business Analyst, habe ich für eins von unseren Warehäusern einen Ansatz entwickelt. Der von der darunterliegenden Technologie war zwar vielleicht etwas rustikal, weil es war Excel mit Makros und Quality Center und so weiter. Aber es hat super funktioniert.
Und zwar hat das so funktioniert, dass du in einem Excel-Sheet hast du die Datenkonstellationen eingeben können. Für einen alten Excel-Hacker wie mich ist das natürlich super, weil du kannst mit Formeln arbeiten. Du kannst dir dann quasi ein Testset, was mehrere zusammenhängende Entitäten darstellt, kannst du einfach kopieren. Als neuen Testfile sozusagen einfügen und halt nur das ändern, was du brauchst. Also du kannst jetzt wirklich so die Konstellationen so darstellen.
Und du hast gleichzeitig auch Expected Result angeben können. Expected Result heißt in dem Fall, was irgendein analytischer Faktor, eine analytische Applikation, die die Daten vom Warehouse sehen soll. Das heißt, wir haben Transformationen drin. Und im Warehouse haben wir natürlich Transformationen. Und das ist ein wichtiger Teil von dem, was wir machen. Wir kriegen Daten aus irgendeiner Quelle daher in einer bestimmten Struktur.
Und irgendein Consumer System sieht die Daten dann in einer anderen Struktur. Und um sicherzustellen, dass diese Transformation richtig ist, haben wir eben mit diesem Ansatz gearbeitet. Das heißt, wir haben die Daten vorne in Abstimmung mit dem Fachbereich, haben wir quasi diese Testfälle durchgemacht, haben die eingegeben und dann hinten rausgeschaut. Okay, wie erwarten wir uns diese Konstellation? Zum Beispiel ich habe zwei Kunden und die Kunden, die haben verschiedene Arten von Konten.
Und wie werden diese Konten dann in der Endapplikation dargestellt? Ja, das hat eigentlich super funktioniert, weil du hast im Excel die Daten eingegeben. Das ist super praktisch, super schnell. Und du hast gleichzeitig auch die Daten eingegeben. Und du hast gleichzeitig die Expected Results gehabt. Das heißt, wie die Files, die die Consuming Applikation die kriegt, hast du auch eingegeben.
Und die Automatisierung daraufhin hat so funktioniert, dass du, also du hast ein Excel Makro gehabt, was dann die Daten, die du eingegeben hast, auf der Vorderseite sozusagen, direkt ins Warehouse, in die Staging Area geschrieben hat. Das konnte man dann durchladen durchs Warehouse bis in den Core. Und wir haben gleichzeitig automatisierte Quality Center Testfälle gehabt. Die dann das Expected Result gegen den Output von der letzten Strecke sozusagen verglichen hat.
Das heißt, du hast eigentlich die Generierung von den Daten basierend auf manuell spezifizierten Test Cases automatisiert gehabt. Und du hast auch automatisiert gehabt, den Output zu prüfen. Das ist super angenommen worden von den Fachbereichen. Die Qualität war sehr gut. Wir haben auch gewusst, was wir da testen, welche Szenarien wir haben. Weil ein großes Thema jetzt. Zum Beispiel, wo wir diesen Ansatz in anderen Bereichen einfach nicht so gut verwenden können.
Da haben wir oft das Problem, ich sage mal, wir sehen den Wald vor lauter Bäumen nicht. Wir haben vielleicht eine Tabelle mit 10 Millionen Datensätzen. Aber ich weiß nicht, beziehungsweise es ist sehr schwer herauszufinden, sind in diesen 10 Millionen Datensätzen alle Konstellationen, die ich brauche, abgedeckt. Speziell wenn es um neue Daten geht. Wenn es um neue Daten geht, ist es sehr schwierig, das mit produktiven Daten zu testen.
Und wenn man dann sagt, okay, dann gibst du halt ein paar Records dazu oder veränderst die Records oder so. Ja, das ist eine manuelle Intervention. Die kostet immer Aufwand. Das ist schwer zu pflegen. Du musst dann auch denken, wenn ich in einem halben Jahr dieselben Testfälle wieder ausführen will, vielleicht auf einem anderen Datenset, was halt dann näher an der Produktion ist, wie wir es jetzt haben. Das funktioniert dann einfach nicht mehr gescheit.
Deswegen war ich eigentlich ein großer Fan von diesen isolierten Daten. Ich sage mal, businessbasierten Testcases, die wir jederzeit und überall deployen und laufen lassen haben können. Ja, da sind ja ein paar spannende Sachen drin. Jetzt kann man natürlich sagen, Excel und Makro und sowas, das ist natürlich jetzt total unprofessionell.
Aber es ist natürlich, muss man sehen, auch für Fachleute, gerade für Facharbeiter, Fachmitarbeiter, ist es natürlich Excel auch ein Standard-Tool, mit dem die gut arbeiten können. Und da tun sie sich ja oft leichter, als jetzt in irgendeinem Werkzeug, was ihnen total unbekannt ist, sich da reinzuarbeiten und dann dort Daten zu pflegen und irgendwelche Dinge zu machen. Excel ist dann so ein bisschen die Wohlfühlzone und erhöht halt auch die Akzeptanz darauf.
Ja genau, also das war wirklich ein großes Plus eigentlich von der Lösung, dass das super vom Business angenommen worden ist. Und die haben auch direkt Testdaten. erstellen können damit. Ich meine, natürlich ist das dann auch über meinen Tisch gegangen und vielleicht muss man da die eine oder andere technische Kleinigkeit daran ändern, aber im Grunde hat es super funktioniert und du sagst es richtig, wichtig ist die Akzeptanz. Das beste Tool
nutzt mir nichts, wenn es die Leute nicht verstehen und nicht akzeptieren. Und es war auch damals ein bisschen aus der Not heraus geboren, weil es war wirklich ein Projekt, wo wir mit den bestehenden Tools einfach nicht weitergekommen sind, weil es einfach so viele neue Strukturen waren. Das heißt, wir haben da den Ansatz mit "Okay, wir nehmen was Existierendes und frimmeln ein bisschen was dazu
und das geht schon", das hat da einfach nicht mehr funktioniert. Und wir haben auch keine Zeit gehabt, da jetzt irgendwie eine große Recherche zu machen, welche Tools würden uns da supporten und so. Es hat sich irgendwie einfach so ergeben. Das Ganze war mir eigentlich von Anfang an klar, dass Excel keine besonders sustainable Lösung ist. Das ist ein Thema, das ich mir immer wieder so in den
Augen habe. Und das ist auch das, was mir auch immer noch wichtig ist, weil du hast da natürlich verschiedenste Versionen von selben Excel-File herumschmieren, auf File Shares, E-Mails und so weiter. Aber ich denke, der generelle Workflow ist eigentlich gut und den kannst du auch mit anderen Tools umsetzen. Mit besseren Tools als Excel. Und du kannst dann auch weiterdenken und vielleicht auch mit, zum Beispiel mit ChatGPT dir dann die Testszenarien in so einem Format hinbiegen und ausgeben lassen. Also das ist
zum Beispiel schon auch was, was ich in meiner jetzigen Arbeit als BA mache, dass ich eben versuche, den Test dann Testfälle mitzugeben oder konkrete Testszenarien. Vielleicht nicht immer in dem Detail schon genau mit den Expected Results und so, weil ich denke trotzdem, das ist eher die Arbeit vom
Tester, das ins letzte Detail zu spezifizieren, die ganzen Edge Cases und so weiter. Aber als BA kann ich einen gewissen Input geben. Und das mache ich zum Beispiel auch schon, dass ich einen ChatGPT eingebe und sage, ich habe diese und
diese Strukturen. Was könntest du da für Testfälle vorschlagen? Und natürlich kannst du es nicht eins zu eins übernehmen. Aber als Inspiration finde ich es eigentlich ganz gut. Und wenn man da weiterspinnt und das ist natürlich wie überall bei uns auch ein großes Thema, AI, Generative AI und so. Und ich denke mal, wenn man sich da ein bisschen hinsetzt und sich was überlegt, kann man da auch sehr viel Nutzen für so eine Lösung gewinnen.
Ja, ich meine, ihr seid natürlich auch ja sehr auch datengetrieben. Also Data Warehouse ist ja ein...
Ja, ein paar Regeln und ein Haufen Daten oder umgekehrt, Haufen Regeln und viele Daten. Also ich merke ja auch das Thema Testdaten, so wenn ich jetzt so die letzten Podcast-Folgen, die letzten zig mehr anhöre, auch das, was welche Themen interessiert haben, das ganze Thema Testdaten und Testdatenmanagement ist ein brennendes Thema für ganz viele Unternehmen, gerade für Große mit vielen Daten oder dann auch noch mit sehr heterogenen Systemlandschaften, wo sich das dann über mehr
Systeme dann einfach auch mitstreckt. Das merke ich, da ist einfach total... Und so wie ich es jetzt verstanden habe, ihr löst das ja quasi auf zwei... Also ihr arbeitet ja schon auch mit Produktivdaten zum einen, aber auch eben mit diesen synthetischen Daten aus Generatoren heraus, die ja euch quasi... Also auch so eine Mischung in euren Test setzt dann drinnen, ne?
Ja, genau. Also sehr viel erschlagen wir sozusagen über Regression mit Produktionsdaten. Das heißt, wir haben einfach ein Baseline-Datum. An Produktiv- oder Produktionsnahen Daten, die sind dann anonymisiert und so weiter, das schon. Ja, und da vergleichen wir einfach gegen die vorige Release, ob wir keine unerwarteten Abweichungen haben. Der Teufel im Detail ist dann natürlich, ich habe eine Abweichung, ist die so, wie ich sie erwartet habe? Ja. Ja.
Verstehe. Jetzt bist du ja an einer, haben wir ja schon vorher gesagt, dadurch, dass du sehr früh auch in dem ganzen Prozess einer Anforderung ja mit dabei bist, hast du da natürlich auch einen großen Hebel, die Qualität auch schon mitzugestalten. Und in deinem speziellen Fall, weil du quasi auch aus der Technik und aus dem Testing kommst und auch entwickeln kannst und sowas, hast du natürlich dann auch einen anderen Fokus drauf. Viele Business-Analysten kommen ja auch von einer eher fachlichen Sicht, da jetzt auch diesen Einsicht, der
Fokus da nicht haben. Was würdest denn du für einen Tipp geben? Was könnte denn ein Business-Analyst tun, um mehr diese Qualitätssicht zu bekommen, um mehr diesen Tester-Skill auch zu bekommen, um da mehr Qualität schon zu Beginn auch mit reinzuarbeiten? Was würdest du da so als Ratschlag mitgeben? Ich glaube, ein guter Ratschlag ist immer, wenn du mal die Schuhe vom anderen anziehst. Also das haben wir bei uns in der Technik.
Ich glaube, ein guter Ratschlag ist immer, wenn du mal die Schuhe vom anderen anziehst. Also das haben wir bei uns in der Technik. Also wie du sagst, finde ich auch ganz eine tolle Idee da, um den Horizont zu erweitern und mal eine andere Sicht auch zu bekommen. Und etwas, was ja auch ein Kern in diesen ganzen agilen Themen auch mit drinnen steckt, eben aus einem Kastl rauszukommen und mal auch das Ganze zu sehen und den Perspektivwechsel einzunehmen.
Super, Philipp. Vielen lieben Dank, dass du hier Rede und Antwort gestanden hast. Als erster Business-Analyst, denke ich, im Podcast. Super, Philipp. Vielen lieben Dank, dass du hier Rede und Antwort gestanden hast. Als erster Business-Analyst, denke ich, im Podcast. Wobei ich muss immer vorsichtig sein, weil die Ausstrahlung von der Aufnahme im Anlass ist manchmal ein bisschen durcheinander, aber es wird klappen. Du wirst der erste BA sein.
Super. Ich danke dir schön, dass du hier warst. Ich wünsche dir noch alles Gute und bis bald mal. Ich danke dir und bis bald. Ciao. Musik Musik Untertitelung des ZDF, 2020