Happy Quality, es ist wieder World Quality Week und da wollen wir Softwarequalität wieder mal so richtig abfeiern. Drum gibt es in dieser Woche wieder jeden Tag eine Spezialfolge zum Thema Testen Qualität und was sonst noch dazu gehört. Also lasst uns Software besser machen. Viel Spaß! Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Ritchie und habe eine Folge von den Softwarequalität 2024 aus Wien mitgebracht.
Diesmal zu Gast Björn Scherer zum Thema Shift Left. Naja, Shift Left on the Right. Also links kennen wir ja Shift Left, aber rechts auch? Und wie funktioniert das? Mit ihm habe ich darüber gesprochen, was wir denn an Testen und Testergebnissen noch auf der rechten Seite machen können. Das heißt, wenn das ganze Ding schon in Produktion ist. Die Ideen und Lösungen, die er in seinen Projekten verfolgt hat, bringt er uns heute mal näher. Und jetzt viel Spaß bei der Folge.
Hallo Björn, schön, dass du da bist. Hallo Ritchie, schön, dass ich da sein darf. Wir haben ja ein paar Anläufe gebraucht, quasi vom QS-Tag über ein paar Zwischentermine, bis wir jetzt hier bei den Software-Quality-Days zusammenstehen und die Folge endlich in den Kasten bringen. Aber so haben wir die Gelegenheit, zusammen hier zu stehen. So ist es, ne? Genau. Also sonst wäre es nur remote gegangen und das haben wir jetzt ja nicht geschafft, aber hier haben wir es jetzt in echt.
Du hast deinen Vortrag hier auch gerade gut beendet. Du siehst auch zufrieden aus, also bist du ganz entspannt. Ja, war schön. Sehr schön. Aber wir wollen uns ein bisschen unter das Thema unterhalten, was du quasi letzten Herbst hattest. Das hat mich ja ganz schön angefixt auch. Und zwar ging es da um Shift Left auf der rechten Seite. Oder nach rechts oder doch? Nach rechts, links oder so? So ein bisschen was von beidem quasi.
Genau, ja. Das wollen wir natürlich hören. Was hat es denn damit auf sich? Wir haben für uns irgendwie das Problem gehabt, am Ende des Entwicklungsprozesses stauen sich immer so die Testaktivitäten. Auch wenn man jetzt agil vorgeht oder im DevOps-Modell unterwegs ist, da ist ja nicht wie im Wasserfall, dass man eins nach dem anderen macht. Aber wenn man mal so drüber nachdenkt, jedes Feature für sich hat ja trotzdem...
Es hat ja trotzdem irgendwie einen linearen Ablauf. Das Team beschäftigt sich ja nicht von Anfang an mit allen Features gleichzeitig, sondern man fängt irgendwann an, sich mit einem Feature zu beschäftigen. Irgendwann geht es live und dann wird es in Produktion verwendet. Und irgendwo dazwischen muss es halt entwickelt werden. Aber trotzdem, auch wenn man agil unterwegs ist, haben wir die Erfahrung gemacht,
dass sich am Ende, also vor dem Go-Live zumindest, die Testaktivitäten stauen. Und dann ist immer der Test schuld, der am Ende nicht fertig wird, so nach dem Motto. Das hat sich dann auch immer wieder verändert. Das hat sich, glaube ich, vom Wasserfall zur Agilität nicht sonderlich viel geändert. Aber da gibt es halt zwei Möglichkeiten, dem zu begegnen.
Und das eine, das bekannte, ist das Shift-Lift-Prinzip, bei dem einfach versucht wird, möglichst viele Aktivitäten früh abzufackeln, nach vorne im Entwicklungsprozess zu ziehen und ja auch Dinge zu parallelisieren. Also es hilft ja nicht, wenn ich einfach die gleiche Mechanik, mache nur irgendwie früher anfange, dann staut es halt irgendwo an einer anderen Anstelle. Sondern ich muss irgendwie versuchen, Themen klein zu klopfen, damit sie besser parallelisierbar sind.
Also vielleicht eine User-Story irgendwie nicht en bloc fertigzustellen und dann innerhalb des Teams irgendwie zu übergeben, sondern irgendwie einzelne Akzeptanzkriterien zum Beispiel so weit zu bringen, dass das erste fertig ist und das schon mal parallel zu betrachten. Dann das zweite kann dann entwickelt werden, wenn das eher das erste getestet ist. Also das ist ja auch ein weiteres Prinzip vom Prinzip her.
Oder noch einen großen Schritt weiter zu gehen und zu sagen, lass uns doch wirklich parallel mit mehreren Menschen mit verschiedenen Rollen, oder eigentlich Rollen haben wir ja im Agile nicht mehr, sondern nur noch Disziplinen, mit verschiedenen Brillen quasi gleichzeitig auf das Feature zu gucken und dann Entwicklung und Test so entsprechend zu parallelisieren. Das geht teilweise Richtung Test-Driven-Development, wenn man rein auf Code-Ebene und so weiter geht.
Das kann man auch in der Technik-Ebene uns das anschauen, aber auch Richtung Acceptance-Test-Driven-Development, wenn man das auf fachlicher Ebene anschaut. Aber das Prinzip ist eben früher anfangen und das schaffen wir, indem wir Dinge anfangen zu parallelisieren. Das habt ihr bei euch auch umgesetzt. Ja, da kommen wir noch dazu. Was sind so die zwei Prinzipien? Das ist jetzt Shift-Left, das ist das, was wir gerade besprochen haben.
Das andere ist eigentlich komplett konträr dazu, nämlich Shift-Right. Also, den Entwicklungszyklus nach Produktion, also in der Produktion erst zu gucken, also nachdem es live gegangen ist. Da kriegen die erst mit Schnappatmung. Genau, das war bei uns auch so tatsächlich. Ich komme aus der Versicherung, regulierte Branche, erstmal schwierig. Der Ansatz ist so ein bisschen, wir schaffen vor Go-Live eh nicht alles zu testen.
Oder andere formulieren es auch so, wir haben in Testsystemen ja nur sowieso, sowieso nur irgendwie simulierte Umstände. Und wie es dann in Produktion wirklich ist, sehen wir ja erst dann. Heißt nicht, dass ich das so sehe, das ist so der Ansatz, der dahinter steckt. Das, was wir quasi vor Go-Live machen, dann ist nur ein minimales Testset, um den Rest dann in Produktion durch mehr Monitoring auszugleichen. Das ist so das Prinzip, was bei dem Shift-Right durchkommt.
Und wir haben uns halt überlegt, beide Ansätze haben so ein bisschen Charme. Bei dem einen kriegst du halt mehr gemacht, du kriegst gleichzeitig die Dinge zu parallelisieren, hat einen Charme. Auf der anderen Seite aber auch zu gucken, was macht denn unsere Applikation in Produktion und das live mitzuerleben und zu begleiten und mehr Monitoring zu haben. Und da haben wir uns gedacht, wir brauchen irgendwie einen Ansatz, der sich aus beiden Welten so ein bisschen was raussucht.
Und jetzt fängt der Teil an. Was haben wir denn getan? Wir wollten auch die Ergebnisse, die wir quasi auf der linken Seite des Go-Lives haben, nicht einfach nur irgendwie beim Go-Live liegen lassen und in der nächsten Iteration wiederverwenden, sondern wenn wir rechts vom Go-Live in der Produktion uns das angucken wollten, wollten wir diese Artefakte auch wiederverwenden. Das heißt, nicht nur mal was Neues aufbauen, sondern das mehr Nutzen bringen von Dingen, die wir schon haben.
Genau. Mit dem einen Ansatz habe ich schon gesagt: Acceptance Test Driven Development ist so das höhere Ziel. Das läuft natürlich sehr heterogen, muss man auch ganz klar sagen. Manche Teams finden es direkt total cool und gehen da freudig drauf. Manche Teams sind da sehr zurückhaltend, aber die Wahrheit liegt irgendwo dazwischen. Das heißt aber, ihr habt das schon auch irgendwie umgesetzt bekommen in euren Entwicklungsteams, also so ein Ansatz.
Und das liegt schon daran, das überhaupt in Betrieb zu nehmen. Genau. Also die Idee ist wirklich, sich möglichst früh mit dem Test überhaupt mal zu beschäftigen, wenn man das Feature angeht. Und wenn man es wirklich schafft, egal in welcher Form jetzt, also ich rede jetzt nicht von "Schreib alles in Gherkin" oder "Schreib es wirklich in einen Keyword Driven Ansatz", das ist uns recht egal. Also das ist Verantwortung der Teams, sich da irgendwie zu gucken, was passt für die.
Aber eben das Prinzip ist: dass wir uns möglichst früh mit dem Thema beschäftigen wollen. Und dann eben so zu dokumentieren oder so aufzuarbeiten, dass man es halt auch weiterverwenden kann. Und dann kannst du halt auch quasi vor dem Coding oder spätestens parallel zum Coding schon anfangen, die fachlichen Fälle zu definieren.
Natürlich kann ich irgendwie bei einer Web-Anwendung, wenn ich einen UI-Test oder einen End-to-End-Test irgendwie vorhabe, als höhere Stufe, kann ich noch keinen, Browser automatisieren, wenn es diese Felder noch gar nicht gibt. Aber das ist ja das alte Problem. Die Fachlichkeit, die weiß ich ja von Anfang an. Mit gutem Fall schon, ne? Ja, bitte. Bevor irgendjemand in die Tasten haut und ein Feature baut, möchte ich gerne wissen, was soll das Feature können.
Und den Teil, den kann ich auch quasi schon ausführbar oder so schreiben, dass er später ausführbar sein wird. Und das andere, wenn ich, wenn ich quasi ein Feld selektieren muss in Selenium oder in welchem Tool auch immer, das ist ja quasi nur noch der Glue-Code, den ich dann am Schluss halt noch ergänze. Aber das ist der letzte Schritt, den ich machen muss. Und dann muss es vielleicht auch die Anwendung oder die UI schon geben, wenn ich nicht alles über Konventionen regeln kann.
Aber dieser wichtige Teil, das Vorziehen, das ist eben die fachliche Definition. Und das ist auch ein Weg. Die Testfälle, also wenn wir von automatisierten Testfällen reden, so weit zu bringen, dass die auch nur fachlich motiviert sind und keine Technik mehr irgendwie auf der obersten Ebene drin haben. Und da hilft natürlich so eine Notation, wie wenn ich jetzt irgendwie mit BDD oder Gherkin Syntax allgemein oder mit Keyword-Driven unterwegs bin.
Mhm. Ein anderer Aspekt ist, dass ich mich wirklich auf den User-Kontext fokussiere. Das heißt, mich interessiert, wie bedient der User die Anwendung? Echte Use Cases, echte User Journeys. Auch wie gesagt auf einer Anwendung im Kontext von Systemtest oder wirklich End-to-End-Test über vielleicht sogar über mehrere Anwendungen. Und das eben auf der Ebene wirklich fachlich motiviert beschreiben.
Dann ein anderer Aspekt war, wir wollen fast Feedback haben für unsere Entwicklungsteams, dass die halt auch die Fehler quasi nicht spät finden, sondern möglichst früh. Was wir dazu brauchen, ist halt auch eine entsprechende Deployment-Häufigkeit. Also jetzt nicht zwingend nur im DevOps-Kontext, wo ich sowieso den Anspruch habe, zu jedem Commit schon mehrere Dinge auszulösen. Wie weit man das auch immer treiben mag, das ist nochmal so eine Frage für sich.
Aber auch wenn ich von, ich will eine höhere Deployment-Häufigkeit zumindest mal auf meine Testumgebung, sodass ich dann quasi auch höhere Teststufen anschließen kann. Also es reicht mir nicht zu sagen, ich will in einer Build-Pipeline auch die Unit-Tests mitlaufen lassen, sondern ich will auch ein Deployment haben, dann will ich einen API-Test dazu haben. Und wenn ich noch weiter gehe, will ich auch ein UI oder einen End-to-End-Test dazu haben.
Um dann quasi möglichst schnell schon Fehler zu finden, die ich vielleicht nur im Unit-Test eben nicht finde. Und dann kommt immer ganz schnell, ja aber das ist doch alles so groß. Fast Feedback. Wir versuchen ja immer neue Anwendungen so klein zu schneiden, dass sie irgendwie einen guten Kontext haben und besser entwickelbar sind. Da kommt man vielleicht in dem Zuge nicht so in die Bedrängnis.
Aber wenn wir von größeren Anwendungen sprechen, dann kriegt man das nicht irgendwie mal in einer 10 Minuten, Viertelstunde jetzt 4000 UI-Tests durchgeführt. Von welcher Größenordnung man auch immer spricht. Und da haben wir für uns so ein stufenweise Vorgehen, ja entwickelt ist übertrieben gesagt, aber uns so überlegt. Das heißt, für jede Anwendung gibt es quasi ein Subset, wo das Team sagt, das ist das Minimum an Testinformationen, was ich brauche. Im Sinne von, was entwickeln wir gerade.
Das Feature, das wir gerade entwickeln. Dazu sind die Testfälle relevant. Und das füllen wir dann so lange auf. Also von den Regressionstests bis die Schmerzgrenze für fast erreicht ist. Also wenn das Team sagt, ich will in 10 Minuten die Antwort haben oder in einer Viertelstunde oder vielleicht in einer halben Stunde, je nach Toleranz, kann ich natürlich das Testset auch entsprechend dimensionieren und schneiden. Und das kann ich pro Sprint quasi nochmal anpassen.
Das heißt, mit dem Fokus auf das aktuelle Feature und aufgefüllt mit, habe ich irgendwo sonst im System was kaputt gemacht. Wie macht ihr diese Auffüllung? Ist das quasi dann ein risikobasierter Ansatz? Ist das dynamisch? Baut sich das zusammen oder wie habt ihr das umgesetzt? Risikobasiert ist so ein bisschen der Anspruch. Aber es ist jetzt nicht irgendwie, dass es automatisch generiert oder dynamisch zusammengesetzt wird. Das ist eben Teil der Aufgabe des Teams zu gucken.
Also das Regressionstest-Set ist klar. Mhm. Ja. Das ist auch größtenteils priorisiert, dass man sagen kann, okay, jetzt nehmen wir nur die Prio 1 Testfälle oder sowas. Aber was jetzt quasi in diesem Feature-Set drin ist, das ist mehr oder weniger für dieses Feature, für diesen Sprint dann handverlesen. Und der Rest wird dann quasi, also nicht automatisch aufgefüllt, aber da ist man recht schnell in der Auswahl. Ja, verstehe. Also ganz simpel irgendwie über ein Tagging an Testfällen.
Ja. Und dann kann man das steuern. Und die Zeiten? Also 10 Minuten, eine halbe Stunde. Sind das auch die, die dann so das Team wählt? Machen die dann so auch was, was für sie passt? Und wenn das halt 10 Minuten ist, dann 10 Minuten, ne? Genau. Also da geben wir auch keine harte Grenze vor. Das ist die Toleranz des Teams, wie es arbeiten will. Genau. Ah ja, sehr cool.
Das heißt, im Sprint fangen wir recht früh an, also wenn wir uns mit dem Feature beschäftigen, nochmal dieser gedachte lineare Ablauf. Natürlich mit Regressionstest und sobald entsprechend Tests für das Feature entstehen, schiffst du das. Man shiftet dazu so ein bisschen oder man kann es auch abwechselnd dann fahren oder so.
Der Fast-Feedback-Ansatz, wie gesagt, mit Fokus auf das Feature und dann aber zum Beispiel im Nightly dann nochmal ein größeres Regressionstest, dass man da von der Reduktion so ein bisschen nochmal weggeht und das ein bisschen in die Breite treibt, um dann nochmal besseres Feedback über die gesamte Anwendung zu kriegen. Wir haben diesen Anwendungsfall jetzt nicht.
An der Stelle quasi noch zu klein wäre, könnte man noch über einen weiteren Schnitt zwischen Nightly und Weekly nachdenken, übers Wochenende dann oder sowas. Wie gesagt, das Problem haben wir jetzt in unserer Größenordnung nicht, aber das Prinzip kann man quasi entsprechend ausweiten, dass man es alle zwei, drei Tage fährt oder wöchentlich oder sowas.
Genau. Und die Idee ist quasi, das dann im Sprint mehrfach zu nutzen, also mindestens mal tagsüber, Nightly etc. Aber auch entsprechend dann klassisches Regressionstest bei der Abnahme vor Go Live. Aber dann nicht aufzuhören, sondern aus dem Testset entsprechend ein, zwei, drei sehr, sehr wichtige relevante Use Cases auszuwählen für diese Anwendung und die dann eben auch in Produktion weiterzuverwenden.
Und das ist quasi der Shift, wo wir uns aus dem Shift-Right quasi benutzen oder bedienen, um dort die Artefakte, die wir links schon aufgebaut haben, weiterzuverwenden, aber die Informationen zu sammeln, die man im Shift-Right haben will. Das heißt also, die Testfälle sind aber dann, die ihr dann quasi nach Produktionssetzung nutzt, die sind schon vorher auch mal durchgeführt oder so?
Genau, die sind effektiver Bestandteil, also mindestens dieses Regressionstestset vor Abnahme, weil ansonsten habe ich das Problem, ich stelle eine Anwendung live und die Tests quasi passen nicht mehr zur Anwendung. Ja. Also muss ich spätestens zur Abnahme. Dann muss ich die irgendwie fertig haben, aber das ist halt auch genau das gleiche Prinzip wie vorher.
Also die will ich auf, also wenn die mir in Produktion so wichtig sind, dass sie dort laufen sollen, um meine Anwendung zu monitoren und einzuschätzen, dann ist der Use Case so wichtig, dann will ich den auch in dem Fast-Feedback-Loop eigentlich drin haben. Also das sind eigentlich die ersten, die dann irgendwie, also wenn eine Anpassung gebraucht wird, das sind die ersten, die angepasst werden. Verstehe, ja. Ah ja, okay. Und die nutzt ihr dann quasi in der Produktion auch weiter?
Genau. Das ist der zweite Teil dann. Also warum machen wir eigentlich synthetisches Monitoring oder was ist synthetisches Monitoring? Monitoring ist ja normalerweise eher so der Fokus auf, es wird irgendwie, die Kunden arbeiten auf dem System, die Software wird benutzt, da passiert ein Logging, im Hintergrund werden die Logs weggeschrieben und auf Basis der Logs wird irgendwie die Anpassung gebraucht. Dann wird irgendeine Auswertung gefahren und dann wird das dann im Monitoring bereitgestellt.
Das ist super. Das funktioniert aber nur, wenn Kunden auf dem System unterwegs sind. Sobald kein Kunde mehr da ist, sei es jetzt irgendwie tagsüber, irgendwie in der Mittagspause, also je nachdem, wie das System genutzt wird. Wenn es ein Inhouse-System ist, wird das anders genutzt, wie wenn es ein Endkundensystem ist. Aber trotzdem wollen wir durchgehend ein Monitoring haben und wissen, wenn was kaputt geht, bevor es der Kunde weiß, im besten Fall.
Also wenn es super läuft und es fällt was um, haben wir es behoben, bevor der erste Kunde gemerkt hat, dass was kaputt ist. Und das können wir eben nicht gewährleisten auf Basis von Monitoring, wenn kein Kunde da ist. Deswegen wollen wir eine proaktive Durchführung und das ist eben genau das synthetische Monitoring. Da gibt es ganz viele Tools, die das irgendwie machen. Dynatrace haben wir auch im Einsatz, das bietet auch solche Möglichkeiten.
Die sind da auch richtig, also jetzt nicht nur Dynatrace, sondern egal welches Tool, die sind größtenteils da richtig gut drin, aber nicht für längere UI-basierte Anwendungen gedacht. Und gerade im synthetischen Monitoring willst du auch effektiv nochmal einen Fokus darauf legen, was tut denn der User oder wie erlebt der User das Anwendungsverhalten. Das ergänzt sich natürlich. Also wenn ich irgendwie jetzt weitere Tools im Einsatz habe, zeigen die dir genau an der, an der Stelle.
Also im Backend in dem und dem Service liegt der Fehler oder da ist es langsamer oder ne. Das brauchst du natürlich auch. Aber trotzdem, wenn du nur diese Information hast, in welchem Service knallst, kommt aus Business-Sicht immer die Frage: Ja und wo ist denn jetzt der Kunde gestört? Ja. Ja und diese, wir zäumen, das fährt quasi von der anderen Richtung auf, weil wir es quasi aus Kundensicht ausführen, wissen wir direkt das schon und nutzen das andere dann eher zur Fehleranalyse.
Wenn wir gucken wollen, wie läuft das. Mhm, verstehe. Ja. Also Monitoring, auch wenn kein User da ist und aus Sicht des Nutzers und eben auch zyklisch. Also es ist irgendwie alle 10 Minuten, Viertelstunde, halbe Stunde, je nachdem wie wichtig dir der Use Case ist, je nachdem wie häufig der beispielsweise auch schon eh läuft, also wenn jetzt von 9 bis 17 Uhr sowieso durchgehend Last auf deinem System ist, brauchst du an der Stelle vielleicht kein synthetisches Monitoring.
Mhm. Oder nicht in der Häufigkeit. Mhm. Aber über Nacht beispielsweise schon. Mhm. Also da gibt es ganz viele Schrauben, an denen man drücken kann. Ja, klar, das muss man sich dann gut überlegen. Wie oft, wie viele Use Cases habt ihr da so, die dann gemonitort werden? Ist das jetzt nur eine Handvoll oder nehmt ihr quasi, habt ihr da Prozentzahlen, die ihr quasi aus diesem Abnahmeregression-Thema dann mit rübernehmt? Ja. Auch das ist komplett in der Hand der Teams.
Also wer kennt die Anwendung besser und die Use Cases und die Relevanz welcher Use Cases, besser als das Team, das die Anwendung entwickelt? Mhm. Prinzipiell ist es den Teams sogar freigestellt, ob sie das überhaupt nutzen oder nicht. Also es ist so ein bisschen dieser Gedanke im Kontext von der DevOps-Migration, bitte zeig Verantwortung für deine Anwendung. Ja. Also es ist der Anspruch, aber wenn ein Team sagt, nö brauchen wir nicht, wir haben alles im Griff, dann ist auch das okay.
Ja. Wir versuchen quasi nur die Infrastruktur bereitzustellen und die Methodik bereitzustellen, dass die da ihre Use Cases einfach einhängen können und sich quasi nicht mehr um grundlegende Mechanik kümmern müssen. Mhm. Ja. Und jetzt so von der Anzahl her? Also genau, also die meisten Anwendungen haben so einen, zwei Kern-Use Cases, die da genutzt werden. Mhm. Die quasi aus Nutzersicht dann da einfach immer durchgehen und da auch nachgenutzt werden, ja.
Ist aber sehr, sehr speziell in unserem Fall. Cosmos Direct hat sehr viele Anwendungen. Man hat sehr viele Online-Antragsstrecken, das heißt, wenn ich eine Versicherung abschließen will, kann ich das online live tun und am Ende der Antragsstrecke habe ich quasi die Versicherung abgeschlossen. Ich schicke quasi nicht nur einen Antrag ab und dann kommt das irgendwie acht Wochen später, sondern am Ende der Antragsstrecke bist du versichert. Ja. Mehr oder weniger.
Und jetzt habe ich einen Faden verloren. Dann komme ich mit einer Frage. Also genau, Entschuldigung, das war jetzt nochmal. Ja. Aber diese Antragsstrecken sind halt sehr straight forward. Also es gibt diverse Stellen, wo du fachlich abbiegen kannst, was auch irgendwie der Kontext von einer Kfz-Versicherung, irgendwie gibt es 1,4 Millionen Möglichkeiten, durch diese Antragsstrecke zu gehen. Das kannst du nicht alles testen.
Aber um es aus betrieblicher Sicht zu prüfen, also du willst ja nicht in Produktion gucken, passen alle fachlichen Varianten, sondern du willst gucken, geht das Ding durch. Also mehr oder weniger der Happy Path oder zwei, drei Varianten. Und da reicht ganz oft schon ein Use Case. Aber das ist halt wie gesagt fachlich bei uns speziell.
Und guckt ihr da eher, also zum einen, dass es durchläuft, aber macht ihr da auch in Richtung Performance dann Messungen, dass ihr seht, okay, das Ganze wird jetzt gerade langsamer, obwohl gerade nur wir da mit unserem synthetischen Monitoring unterwegs sind. Also beobachtet ihr solche Themen auch? Aus dem, was wir jetzt da zentral aufgesetzt haben, nicht. Aber weil wir das eher beispielsweise aus den Dynatrace Daten dann auslösen. Also interessant ist das auf jeden Fall.
Du merkst es natürlich auch in der Testautomatisierung. Testautomatisierung reagiert auf die UI, also UI basierte Automatisierung. Und wenn da Dinge länger dauern, als du jetzt irgendwie ein Timeout eingestellt hast, dann fliegt dir das Ding auch um die Ohren. Also das merkst du quasi auch an der Fehlerhäufigkeit, wenn Dinge plötzlich zu langsam werden. In dem Sinne schon. Aber da haben wir natürlich auch unsere Toleranzen erhöht, um jetzt irgendwie zu viel Fleckchen auszulösen.
Aber wenn Dinge langsamer werden, sehen wir das eher jetzt irgendwie im Dynatrace Monitoring. Ein großes Thema, was mir da noch einfällt, ist das ganze Thema Testdaten. Weil wie geht man darum? Ich kenne es jetzt auch aus anderen Versicherungsumfeldern. Da gibt es dann zum Teil auch zum Beispiel so Zähler, die immer hochzählen bei jedem irgendwas. Und das lässt sich auch nicht revidieren, weil das muss so sein. Habt ihr sowas?
Und wie geht ihr generell mit Daten an, die da jetzt alle 10 Minuten angelegt werden oder so? Ja, genau. Also zum einen ist es: Was willst du denn in Produktion tun? Da waren am Anfang auch die Augen recht groß, als wir da irgendwie mit der Idee angekommen sind. So wie bei mir jetzt. Genau. Das war auch ein langer Kampf, das überhaupt zu ermöglichen und zu sagen: Wie kriegen wir unser System, unsere Datenlage und unsere Daten, die wir da haben, zu vermitteln? Ja, genau.
Also wir haben eine ganze Anlage und unseren Testansatz dahin, dass das überhaupt geht. Nummer eins: Wir dürfen das natürlich nicht mit realen Kundendaten machen. Da brauchen wir überhaupt nicht drüber zu reden. Das heißt, wir haben quasi definiert, was brauchen wir dazu, beziehungsweise für jeden Use Case definiert. Welche Daten braucht der? Welche Daten müssen im System vorhanden sein? Und die quasi einmalig in Produktion eingelegt.
Mhm. Und die Tests dürfen quasi dann nur diese Daten benutzen. Das ist zum Beispiel ein konkreter Login mit einer gewissen Menge von Verträgen oder solche Geschichten. Das heißt, das sind synthetische Daten oder sehr, sehr wenige explizite synthetische Daten, aber in Produktion. Darauf basiert der Test. Aber umgekehrt, der Use Case muss auch dazu passen.
Das heißt, wenn ich irgendwie eine Antragsstrecke durchgehe bei uns und der Kunde hat schon einen Account, verhält die Antragsstrecke sich anders, als wenn es ein Neukunde ist, den wir noch nicht kennen. Dazu muss der Use Case passen. Der Use Case muss auch, bevor ich das Initial überhaupt mal in dem Produktionsmonitoring-Kontext benutzen darf, einmal auf Testumgebung oder also auf Pre-Production nachweisen: Ich mache hier nichts kaputt. Dazu mussten wir auch entsprechend Anwendungen anpassen.
Das heißt, der Test muss oder der Use Case muss quasi sagen können: "Ich habe hier den Monitoring-Use Case." Das heißt, wir müssen das irgendwie den echten Kunden von dem Monitoring unterscheiden können. Und dann, wie du sagst, in Produktion werden Auswertungen gefahren. Denkt man nur mal an eine Risiko-Lebensversicherung, muss man ganz viel Informationen über Krankheiten oder Gesundheitszustände angeben. Und da gibt es natürlich Auswertungen, wie verhält sich der Kunde in Produktion.
Sondern man muss auch die Anwendung des Kunde-Auswertungs-Kontextes nachweisen. Wenn wir das jetzt irgendwie auf Nischenprodukte anwenden, führen wir wahrscheinlich, wenn wir das alle 15 Minuten machen, zehnmal mehr durch, als jetzt echte Kunden kommen. Übertrieben gesagt. Da würden wir natürlich alle Auswertungen verfälschen. Und sowas muss man natürlich entsprechend auch berücksichtigen und nachweisen, dass das entsprechend gut aneinander vorbeigeht.
Oder allein schon normales Tracking, also Web-Tracking, was man so standardmäßig auch im E-Commerce im Einsatz hat. Das willst du natürlich nicht verfälschen. Das musst du irgendwie per Cookies ausschalten oder solche Dinge. Die Versicherung ist der volle Renner. Da weißt du, der Monitor, der da so freilässig vor sich hin arbeitet. Ja, ist klar. Ich glaube, das ist total wichtig, sich darüber auch die Konsequenzen, die dann da hinten raus entstehen, einfach auch bewusst zu machen. Genau.
Und dann, wenn du den gleichen Use Case oder den gleichen Testfall quasi vorher in Test nutzen willst, musst du natürlich andere Daten benutzen als nachher ein Produkt. Das heißt, auch dein Testfall oder dein Testframework braucht quasi einen Monitoring-Modus. Da brauchst du ein bisschen Tuning, da muss man sich immer ein bisschen reindenken, aber es geht. Ich finde es total spannend, weil ihr hier quasi mehrere Sachen verbindet.
Also diesen Shift-Left-Ansatz, aber auch eben so diese Qualität über den gesamten Prozess und eben nicht mit Release beendet, sondern noch weiter in die Produktion hinein, die Dinge. Wie können wir die nutzen? Das ist natürlich schon im gesamthändlichen Qualitätsgedanken noch einmal eine ganz schöne Facette. Ganz oft kriege ich auch die Frage gestellt: Warum macht ihr denn das mit UI-Tests? Die sind doch so anfällig und nicht mit API-Tests oder sowas.
Haben wir auch, aber es geht auch ganz viel darum, was ist denn schon… Also ich habe ja gesagt, dieser Aspekt der Wiederverwendung, was ist denn schon da? Welche Artefakte haben wir vorher schon erzeugt? Welche können wir weiter benutzen? Und eben, wir wollen noch einmal diese User-Sicht, weil das ist genau das, mit dem wir unsere UI oder End-to-End-Tests auch aufbauen, dass sie explizit User-Fokus haben. Und das kriegst du halt auf Schnittstellen-Ebene deutlich schlechter raus.
Ist aber noch ein Skill- und Know-How-Thema. Also du bist ja im… Also wir arbeiten mit cross-funktionalen Teams und wenn du da jetzt irgendwie nochmal ein Tool mit reinbringst, weil das jetzt irgendwie Monitoring stark ist. Muss sich auch jemand, also mindestens einer in dem Team ja damit beschäftigen und wenn es einer ist, ist der Bus-Faktor gleich eins. Also wie viele Leute müssen überfahren werden, damit der Skill weg ist. Ist auch doof. Also wollten wir explizit kein extra Tooling haben.
Stabilität ist auch ein Thema. Wir haben ganz, ganz viel investiert, jetzt unabhängig von dieser Maßnahme, vorher schon in, wie kriegen wir unsere Testautomatisierung stabil. Ja, wichtiges Thema. Riesenthema, Testflakiness. Und auf der anderen Seite, wir können es quasi möglichst früh schon, das was du eben auch gefragt hast, wir können es schon sehr früh in unseren Standard-Testprozess einbinden und würden dort entsprechende Anpassungen oder Probleme an der Stelle schon früh mit kriegen.
Deswegen war das für uns ein guter Ansatz. Sehr spannend. Wenn du jetzt so drauf schaust, wenn das mal so stabil läuft, wie das jetzt bei euch so aussieht, was hast du denn da für so eine Idee für die, was wäre so ein Next-Step oder wo würdest du gerne noch mehr optimieren oder verbessern oder noch draufsetzen? Ja, also ein Ding, was wir halt auch schon gemacht haben, muss ich kurz noch erzählen, um genau diese Frage beantworten zu können.
Das heißt, wir haben auch entsprechend schon ein Alerting gebaut. Das heißt, es gibt irgendwie ein zentrales Control-Center, was dann irgendwie sowieso aktiv ist. Und das wird da schon auch entsprechend geplant. Und das wird da schon auch entsprechend hinreporten und das in unsere Prozesse so ein bisschen integrieren. Weil gerade, wenn jetzt irgendwie nachts was umfällt, bist du vielleicht nicht mit dem Team vor Ort, nachts nicht so häufig zumindest. Gerade in der Bar irgendwo.
Also das gibt es schon, diese Standard-Prozesse, die gibt es in den Unternehmen. Da haben wir uns integriert. Und das ist auch ein ganz wichtiger Schritt, dass wir das auch noch mal umdrehen und auch die Teams direkt zu alerten. Das heißt, die, die eh was tun müssen, wenn was umfällt, ist das Team, das für die Anwendung verantwortlich ist.
Und da das Alerting, das Offizielle zwar immer noch zu lassen, aber quasi direkt die Fastlane zu ziehen und zu sagen, hey, hier bei der Wandelnung halt so, das ist das Problem. Das direkt in die Teams wieder reinzuspielen, das ist natürlich, spart dann einen Haufen Aufwand und Nachwanderlöse noch. Was wir gerade noch am machen sind, ist auch ein entsprechendes Reporting noch aufzubauen. Also ein kleines Dashboard dazu gibt es schon.
Das heißt, ich will irgendwie natürlich recht schnell erkennen, wenn ich so ein Alert kriege, was ist denn betroffen? Also jedes Team kriegt quasi nur seine Alerts dann von seiner Anwendung. Aber das, was in diesem großen offiziellen Weg läuft, das schlägt dann irgendwo bei einem zentralen Manager auf, der gerade in Anführungszeichen Dienst hat. Und dann will der erstmal wissen, ist jetzt Anwendung A kaputt oder Anwendung C kaputt oder ist es A bis F kaputt?
Also haben wir einen Flächenbrand oder haben wir ein einzelnes Problem? Da haben wir ein entsprechendes Dashboard aufgebaut, das das versucht recht schnell zu zeigen. Aber wenn wir dann quasi nochmal eine Stufe tiefer gehen wollen, was sind denn die Ursachen? Also jetzt auch zumindest aus User-Sicht, was kann man da irgendwie bewerten? In welchen Schritten geht es schief? Das so ein bisschen zu aggregieren, auch über die Historie nochmal zu gucken, da geht noch ein bisschen was.
Ja, schöne Aussichten. Da kann man ja noch gut weiterarbeiten. Da bin ich schon gespannt, was du da bald mal berichtest davon. Super. Björn, vielen lieben Dank für diese Einsichten. Ich finde das einen ganz genialen Ansatz. Der Podcast hat ja als Untertitel "Qualität als Haltung" und das ist natürlich, weil Qualität einfach auch ein übergreifendes Thema ist im gesamten Entwicklungsprozess. Genau. Und man zieht das noch ein Stück weiter und versucht alles da mit reinzunehmen.
Das finde ich genau die richtige Richtung, sich darüber mal Gedanken zu machen und das umzusetzen. Ganz klasse, dass du uns hier vorgestellt hast. Dankeschön. Und ich denke, das wird den einen oder anderen sicher auch inspirieren, da mal in die Richtung zu denken. Genau. Ich wünsche dir noch ganz viel Spaß hier bei den Software-Quality-Days. Den will ich auch. Genieß die Zeit. Du bist ja jetzt schon durch mit deinem Thema. Ich kann nur noch genießen. Du kannst nur noch mal genießen.
Heute Abendprogramm und morgen noch ein paar Vorträge. Sehr schön. Dann bis bald und Dankeschön. Vielen Dank. Untertitelung des ZDF, 2020