Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Ritschi und freue mich wieder eine Folge vom German Testing Day 2024 dabei zu haben. Mein heutiger Gesprächspartner ist Uwe Pesch, mit dem ich mich über risikobasiertes Testen unterhalten habe. Es könnte eigentlich so einfach sein, ist es aber nicht. Welche Erfahrungen er mit risikobasierten Testen gemacht hat, wie er den Ansatz lebt und welche Tipps er für uns hat,
darüber geht es in der heutigen Folge. Viel Spaß beim Hören. Hallo Uwe, schön, dass du da bist. Hallo Ritschi, danke für die Einladung, hat mich sehr gefreut. Ja, mich auch. Nach unserem Vorgespräch habe ich mich schon sehr auf unsere Folge gefreut. Du bist ein sympathisch freundlicher Mensch und da habe ich gedacht, das wird sicher eine coole Folge auch mit uns werden. Danke, vieles Kompliment,
kann ich eigentlich nur zurückgeben. Also ich glaube, seitdem wir uns kennen, auch wenn wir uns erst mal virtuell kennengelernt haben oder jetzt gestern hier, wenn wir zusammen sind, wir sind nur am grinsen. Ja, genau, vielleicht müssen wir da mal eine eigene Show draus machen. So ein ähnliches Waldorf und Städler fürs Testen. Ja, gute Idee, mal überlegen, was wir da draus machen. Schön, wir sind ja hier German Testing Day 2024 in
Frankfurt. Du hast deinen Vortrag schon gehabt gestern. Ich habe meinen Vortrag gestern. Also heute schon ganz entspannt im zweiten Tag drinnen. Und ja, ich habe ja im Vorweg deinen Abstract auch gelesen und da stand schon ganz drüber, so risikopasiertes Testen und da habe ich mir gedacht, ach, wenn ich da überlege, so viele Kunden von mir oder so, wenn man da hinkommt, da wird so viel getestet, aber so risikopasiertes wollen die alles machen, aber machen dann dann
doch nicht oder wie auch immer. Das ist doch mal schön, wenn wir auch mal darüber sprechen können. Gerne. Sag mal vielleicht ganz kurz, in was für einem Kontext arbeitest du oder was macht ihr als Unternehmen? Die Bison Gruppe hat ihren Hauptstandort in der Schweiz. Dependants in Kaiserslautern und Hamburg sind ungefähr zurzeit 350 Mitarbeiter, machen Softwareentwicklung, ERP-Bereich, mobile Lösungen, Smart Farming, also Cloud-Lösungen auch und BI-Anwendungen,
also ein ziemlich breites Produktspektrum. Fokusbranchen sind Retail und Agrar. Ah ja, okay. Also ein großer Softwarehersteller, der natürlich auch ein bisschen testen sollte, bevor er was ausliefert. Hin und wieder tun wir das. Wieso risikopasiertes Testen? Was hat euch dahin bewogen?
Wir haben ein ERP-System gehabt, was bei einem großen Kunden im Einsatz ist und dieses ERP-System hatte so einen rich client, so einen fetten client, wie man ihn von der SAP zum Beispiel auch kennt oder so und wir sind dann umgestiegen auf einen Web-Client und hatten roundabout 1000 End-to-End Tests, die abgelöst werden sollten. Also entweder durch Neu-End-to-End-Tests oder wenn es geht,
natürlich auch nicht auf so einem hohen Testlevelniveau. Das Projekt lief dann und lief und lief und lief und zu irgendeinem Zeitpunkt haben alle unsere Kunden mit dem Web-Client gearbeitet, aber keiner mit dem rich client und dann mussten wir uns irgendwas einfallen lassen, wie werden wir die los möglichst schnell und dann sind wir auf das risikobasierte Testen gekommen. Also wir haben uns überlegt, wo tut es dem Kunden am meisten weh und da wo es am meisten weh tut, fangen wir mal an,
da die Tests zu schreiben. Also nicht so eine 1 zu 1 Ablöse, sondern eher Testabdeckung in dem Bereich, wo es weh tut. Was war das zum Beispiel? Hast du da ein Beispiel für uns? Ja gut, so high risk Rechnungen gehen falsch raus. Du machst einen Rechnungslauf, haust 4500 Rechnungen raus und irgendwo summiert der falsch oder falschen Steuersatz gezogen oder sonst irgendetwas. Ist der Schaden beim Kunden ziemlich hoch, weil er die 4500 Rechnungen zurückholen muss. Unser
Schaden ist natürlich auch dementsprechend hoch, wie könnt ihr sowas ausliefern. Und da heißt es also, welche Schlagzeile möchtest du morgen nicht in der Bild-Zeitung lesen. Der Kunde liefert 4500 falsche Rechnungen. Schadenspotenzial relativ hoch, Auffindbarkeit auch relativ hoch, weil das wäre vielleicht einem aufgefallen, aber auch nicht auf den ersten Blick ersichtlich. Und dann findet man den Fehler. Also da sind wir bei der dritten Komponente der Komplexität, auch relativ hoch
und das ist ein high risk. Habt ihr denn diese Risikobewertung, habt ihr das formal gemacht oder habt ihr da schon Grundlage gehabt oder habt ihr die erst entwickelt dann auch für euch? Nein, also wir haben eine Grundlage gehabt. Denkt ihr eine Schlagzeile aus, formuliert daraus ein Risiko und die drei Komponenten Schadenspotenzial, Auffindbarkeit, Komplexität, für die hatten wir uns dann entschieden zu dem Zeitpunkt 2020. Und haben da auch ein Range von 1 bis 3, wo wir jeden
einzelnen Punkt mit bewerten. Die werden dann multipliziert und daraus gibt sich dann so eine Kennzahl. Je höher die ist, desto mehr sollte man hingucken. Ja, ja, ja. War denn da eure Erfahrung, jetzt kommen ja da Sachen raus, wo man ja manchmal vielleicht gar nicht so gerne hinschauen mag, weil es eben ja komplex ist oder so. Also wie seid ihr denn darum gegangen? Da müssen wir jetzt durch?
Ja, da war durchs Teil der Tränen. Und wir sind dann hergegangen, in der ersten Zeit hatten wir im Confluence so Risikokataloge aufgebaut und haben dann gesagt, ihr müsst in die Bugs, die reinkommen, Risiken reinschreiben, weil dadurch hast du dann eine Korrelation, wenn ich einen Bug habe, ein Risiko verletzt habe, ist die Testabdeckung vielleicht noch nicht so gut. Irgendwann haben wir dann gesagt, macht keinen Sinn und haben die Risiken ins
T-RAH gezügelt, sodass die Verlinkung besser funktioniert. Und das war eigentlich dann auch der Trigger, gerade bei den, du hattest auch eine Korrelation, hoher Risikoindex, desto höher war der Buglevel, also wo man meistens dann high ist oder high bugs. Wie viele Risiken habt ihr denn
dann so gehabt? Roundabout, ich würde sagen, für ein ERP-System sind wir bei 150 ungefähr. Wir sind halt so vorgegangen, wir haben es geteilt, also erstmal überlegt nach Domänen, Verkauf, Bestellung, Wareneingang, Lieferung, Schnittstellen, Stammdaten, dann hast du schon mal einen Cluster. Und dann darunter überlegt, was darf auf keinen Fall schiefgehen.
Ja, verstehe. Das war so der erste Schritt, das habt ihr dann quasi bei euch im QA gemacht, im Testbereich oder habt ihr quasi alle mit reingeholt oder wie habt ihr das gemacht? Ja, es fing eigentlich andersherum an. Wir haben so vier ERP-Systeme, die relativ kundenspezifisch sind und die haben damit angefangen, in Teams damit. Dann haben wir uns in die QA-Runde, also Quality Assurance-Runde mit reingenommen und hatten dann 2022 gesagt,
das ist unser Ziel, wir wollen risikobasiertes testen in der gesamten Gruppe. Hat dann nicht so richtig gut geklappt, war vielleicht etwas zu hoch gegangen das Ziel. Und haben dann 2023 gesagt, das ist jetzt gesetzt und haben auch dementsprechend einen Kurs angeboten, wo dann risikobasierte Testen vorgehen, wozu man es macht, wie man es macht, den Leuten nähergebracht.
Jetzt habt ihr ja bei dieser Analyse die Risiken dann auch gehabt, ihre große Kennzahl, es ging ja jetzt um die Transformation oder dann auch diese Tests neu zu machen aus dem End-to-End-Test, aus dem alten in das neue. Wie seid ihr denn da so vorgegangen? Wie habt ihr euch denn
dann da rangewagt? Erstmal ist so ein Risikokatalog aufgestellt, dann geguckt, welche von den Highest Risiken, die wir identifiziert hatten, aufgrund des Know-hows, also wir haben halt Business-Leute mit reingezogen, die Entwickler mit reingezogen, Architekten, alle so gefragt, wie bewertet ihr das? Und haben dann gesagt, okay gut, dann gucken wir uns das an, welche Tests gibt es denn eigentlich schon? Haben wir da schon vielleicht was? Müssen wir die
erweitern? Haben uns Cases, Test-Cases definiert und haben dann versucht, eine relativ gute Testabdeckung hinzubekommen. Und da spielen natürlich mehrere Faktoren dann auch mit rein. Du hast ja auch gesagt, diese End-to-End-Tests eventuell auch runterzuziehen auf untere Teststufen, also da vielleicht zu schauen und vielleicht auch das Thema Testautomatisierung. Wie seid
ihr denn mit diesen zwei Dingen umgegangen? Eine Testautomatisierung haben wir eigentlich, das heißt also bei jedem Bild von dem ERP-System laufen alle J-Units und Modultests und zweimal täglich laufen dann Komplett-Tests in der Hand, also inklusive End-to-End-Tests. Das heißt also, wir müssen uns eigentlich nur noch die richtigen Testlevel überlegen. Und dadurch, dass ein Großteil der Leute halt auch schon Jahre mit der Software gearbeitet
hat, kennen die dann natürlich auch die Schwachstellen. Spannend ist es dann, wenn du neue Produkte hast oder neue Funktionalitäten. Und von der Teststufe her, habt ihr das auch dann geschafft, diese End-to-End-Tests auch runterzuziehen auf unterer Ebene? Was habt ihr da so gemacht? Wir sind halt hergegangen und haben überlegt, muss das? Brauche ich unbedingt so einen End-to-End-Test?
Weil erstens teuer in der Herstellung, teuer in der Wartung und teuer im Feedback. Also ich muss halt, wenn ich einen kleinen habe, aber dann testet der nur eine Kleinigkeit und dann ist die Frage, brauche ich dafür einen End-to-End-Test? Kann ich den nicht ein Level oder zwei Level tiefer ansetzen? Weil dann ist mein Feedback gut natürlich
auch wesentlich schneller. Ja klar, natürlich. Ja, das ist ja auch die ideale Chance bei so einem Transfer, dann auch genau sich diese Frage auch zu stellen und zu schauen, okay, wie kann ich das? Wenn du jetzt so drauf schaust, diese End-to-End-Tests, die ihr vorher hattet, nach dem Übertrag, wie viel so Pi mal Daumen von Prozent habt ihr denn runtergeholt auf andere Teststufen? 40, je nach System würde ich sagen zwischen 50 und 60 Prozent. Das
ist ja schon echt ein Brett auch, was einiges einspart dann auch. Definitiv, ja. Also es hat uns damals halt bestehende Funktionalitäten überlegen und dann neue Tests dazu schreiben, hat wirklich dazu geführt, gut 50 bis 60 Prozent der alten End-to-End-Tests einfach
gekegelt wurden. Wo man gesagt hat, braucht man nicht. Gab es denn eine Rückkopplung auch zu dieser Risikobewertung noch, wenn ihr die Tests umgesetzt habt oder so festgestellt habt, die Einschätzung war jetzt vielleicht keine richtige, es ist doch mehr Risiko oder weniger? Habt ihr das noch einmal auch da reflektiert oder habt ihr das quasi als Gesetz
und der Hauptsache mal durch? Das ist ein lebendiger Prozess. Wir haben damals eine Reihe von Risiken definiert, sagen wir mal ein wenig im Verkauf, so zwölf Risiken und haben die dann bewertet. So, dann Feedback von Requirements Engineers oder auch durch den Kunden über Bugs. Das war natürlich nicht so ein schönes Feedback, aber dadurch
kannst du dann die Sachen auch neu bewerten. Und die andere Sache ist halt auch, wenn neue Anforderungen kommen, wir leben halt in einer schnelllebigen Zeit, es kommen neue Anforderungen, dann gehe ich hin und gucke mir dann an, handele ich mir ein neues Risiko ein oder verletze ich bestehende Risiken und dann kann ich auch noch einmal über die Bücher gehen. Ja, das ist ja gut, wenn man da auch so eine Rückkopplung mit drin hat. Seid ihr denn jetzt mit diesem
Transfer soweit durch oder ist der noch im… Ist ongoing. Also es ist zum einen eine never ending story, weil es sind ja mehrere Produkte, die wir haben. Andere Teams sind dann sukzessive eingestiegen, sind noch nicht alle involviert, also dauert es, bis der Flächenbrand da ist. Und damals die ERP-Truppen und Teams waren ja dadurch getriggert, wir haben alten Ruch gehabt, wir brauchen ein neues. Und mittlerweile achten wir natürlich auch mehr darauf, wenn
neue Produkte entwickelt werden, neue Funktionalitäten. Der Kunde sagt, ich habe da eine Idee. Und dann nachgefragt wird, ok, welche Schlagzeile möchtest du morgen nicht lesen. Und dann ist das so der erste Einstieg. Der Kunde weiß am besten, wo es ihnen am meisten wehtut. Dann habe ich schon auf jeden Fall mein Schadenspotenzial vielleicht ermittelt.
Habt ihr denn auch jetzt so bei diesen, wenn ihr dann so die Tests in den Hochrisikobereichen so durchgeführt habt, zum einen habt ihr denn da dann überhaupt Fehler gefunden oder war das dann eh alles nichts? Und hat das euch bestätigt auch in der Risikotestung, dass ihr sagt, ok, wenn der Fehler rausgegangen wäre, das hätte uns jetzt richtig Geld gekostet? Haben wir. Also auf der einen Seite positiv, indem wir intern noch einen Fehler festgestellt
haben, bevor das Produkt zum Kunden raus ist. Auf der anderen Seite hat es uns bestätigt, wenn wir jetzt über die letzten drei Jahre mal so die Bug-Auswertungen angucken, dann kann man einen deutlichen Trend erkennen, dass so High ist, also Blocker-Bugs und High-Bugs, die dem Kunden wehtun, wirklich massive Tendenzgen unten haben. Der Trick an der Sache ist auch darauf achten, weil du hast, wenn du überall eine hohe Bewertung hast bei jedem Schadenspotenzialaufwand,
kommt auch eine hohe Zahl raus. Wichtig ist, dass man auch die, die ein Schadenspotenzial 3 haben, im Auge behält. Du hast manchmal Sachen, die haben hohen Schadenspotenzial, sind aber schnell merkbar und einfach zu flicken. Wenn die rausgehen, dann sagt der Kunde dreimal, geht's noch? Ja, genau. Muss man natürlich beachten. Ich glaube auch generell, Risikobewertung,
wie war das bei euch in dem Prozess? Ihr habt ja jetzt schon versucht, das von Kundenseite auch zu sehen, aber es gibt ja trotzdem vielleicht auch gewisse Trade-offs, je nachdem, wer gerade drauf schaut. Der eine sagt, das ist ein großes Risiko, für den anderen wieder nicht. Wie habt ihr denn diese Gaps gelöst? Es wird diskutiert. Es werden jetzt keine Stuhlkreise gebildet. Risiko-Selbsthilfe-Gruppe. Nein, es geht eigentlich relativ zügig, sehr sachlich.
Es werden die Argumente gegenseitig gehört und dann wird ein Konsens gefunden. Es ist halt so, wenn irgendwann sagt dann, ja okay, ich kann damit leben, dass ihr das so einschätzt. Und nicht, also es kommt tatsächlich in veto, dann muss man vielleicht mal ein bisschen länger sich auseinandersetzen. Das ist halt gerade in den Themen Auffindbarkeit, wie schnell wird das sichtbar? Und ja gut, beim Thema Komplexität streiten sich dann immer die
Gelehrten. Ja, verstehe. Ich kann mir vorstellen, also das ist zumindest meine Erfahrung auch mit risikobasierten Testen. Das wäre schön, wie das bei euch war. Wenn man sich so auseinandersetzt mit den Risiken, dass da durchaus auch so Aha-Momente auch in Richtung Entwicklung gibt, weil die manchmal auch gar nicht so wissen immer, wie komplex das beim Kunden ist oder wo der eigentlich seinen Fokus ist. Man ist da so in seiner Bubble drin, man macht seine
Story, seine Anforderungen, setzt das alles um. Aber dann versteht man auch ein bisschen mehr, was eigentlich draußen passiert. Es ist so, ein anderer Nebeneffekt, sag ich jetzt mal abgesehen davon und an den richtigen Stellentest ist Bewusstsein schaffen. Und das Spannende
ist eigentlich, zieht sich durch. Also das ist nicht nur beim Entwickler, der gegebenenfalls sagt okay, der Story ist ein hohes Risiko zugeordnet worden oder sogar drei Risiken, alles passieren kann, ich muss da besonders aufmerksam sein, wenn ich da irgendeinen Entwickler unteste, sondern eigentlich durch die ganze Kette. Dadurch, dass man sich auch einen Requirements Engineer Gedanken jetzt macht und mit dem Kunden in den Dings und sagt Leute, ihr könnt
das so umsetzen oder so umsetzen. Ja, wenn wir das so machen, dann funktioniert die Preissinnung nicht mehr. Also es schafft Bewusstsein für Qualität. Ja, sehr spannend. Wenn du jetzt so einen Tipp raushauen musst, jemand kommt und sagt, ich möchte das auch machen, ich
möchte so wie Uwe auch Risikobasiertes testen, wo anfangen? Themengebiete definieren. Also entweder, wenn ich ein ERP System habe, nach Domänen oder so oder wenn ich eine mobile App habe, was weiß ich, Funktionalität der App selber, Kommunikation mit den Umsystemen, also wenn ich so ein Themengebiet habe und wenn ich die habe, dann kann ich die Risiken leichter aufnehmen. Weil es ist halt die Gefahr, auch bei einem Risiko, richtig schneiden.
Der Verkauf geht nicht. Aber der Wert, was sehe ich, 0,5 ist ja falsch. Das eine ist zu tief, das andere ist viel zu hoch. Ja, ja, okay, also auch die richtige Flughöhe fehlt. Die richtige Flughöhe, ja. Und es ist halt so, einfach mal die ersten kleinen Schritte machen. Der erste Step wäre vielleicht so Fachgebiete, Themengebiete und dann anfangen runterzubrechen. Ja, super. Wir sehen uns 2029 hier in fünf Jahren.
Treffen wir uns zufällig am German Testing Day und dann kommt, cool, hier, schau mal Uwe, kannst du dich erinnern, wir haben damals diese Folge gemacht, ja, war ja lustig. Was ist denn in der Zeit passiert in den fünf Jahren? Was habt ihr denn bei euch noch im Testteam draufgesetzt? Was war also der nächste Meilenstein? Der nächste Meilenstein wäre wirklich, also ausgerollt, Flächendecken und dann irgendwie
vielleicht auch eine Automatisierung hingekriegt, ja. Also nicht nur Test automatisch ablaufen, sondern man aufgrund von Use Cases und Risiko Beschreibung Tests generiert oder Vorschläge kriegt. Ich meine AI, KI und jeder Leistung ist gerade in aller Munde und ich denke mal nicht so, in fünf Jahren vielleicht dann da doch noch mehr Unterstützung kommt.
Na super, wir werden sehen. Bitte lassen uns überraschen. Wir lassen uns überraschen, wir machen dann das Interview und dann werden wir sehen, dann können wir das vergleichen. Werden wir machen, ja. Super. Ja, Uwe, vielen lieben Dank für diese
Einblicke, wie ihr das risikopräsierte Testen bei euch umgesetzt habt. Finde ich sehr spannend, finde ich auch einen super Ansatz, sich gerade so eine Transformation zu nehmen und das an der dann quasi auch mal wirklich dann auch durchzuexerzieren und dann auch wirklich umzusetzen, finde ich ganz toll. Ich wünsche dir noch ganz viel Spaß hier auf der Konferenz. Vielen Dank. Genießt die Zeit noch und bis bald. War eine große Freude, Richi. Vielen Dank für das Interview und hab du auch noch eine
gute Zeit hier. Dankeschön, das werde ich haben. Ich danke dir. Danke. *Musik*