Episode 229. 404. Risk not found. Risiken, die keiner kommen sieht. Herzlich willkommen beim Zukunftsarchitekten, der Systems Engineering Podcast für Machende und Entscheidende. Am Mikrofon ist wieder Björn Schorre. Als Systemingenieur gebe ich dir Tipps und Impulse, damit du dein Projekt zum Erfolg führen kannst.
So wirst du in der heutigen Episode erfahren, aus welchem Grund Riskstorming eine hervorragende Methode ist, um Risiken zu finden und wie du Riskstorming anwenden kannst und welchen Wert die Ergebnisse für dein Projekt haben. Ja, heute darf ich einen ganz besonderen Menschen hier bei mir im Podcast begrüßen. Geht schon richtig gut los hier im neuen Jahr.
Er ist Sprachwissenschaftler und ist nach seiner Ausbildung, seinem Studium, direkt ins Testen gestartet, weil er nicht nach Papua-Neuguinea wollte. Herzlich willkommen bei mir hier im Podcast, Christian Kram. Ja, hallo Björn, schön, dass ich da sein darf. Stimmt, genau. Ich habe genau null Tage in dem Job, den ich studiert habe, gearbeitet. Okay, du bist dann direkt nach deiner Ausbildung ins Testen gestartet. Oder nein, andersrum, fangen wir andersrum an.
Was hat dich dazu bewegt, Sprachwissenschaftler zu studieren und das dann nachher nicht zu machen? Darf ich Klugscheißen sagen? Ja, ne? Also Sprachwissenschaften ist studiertes Klugscheißen, wenn man so will. Also Wörter verdrehen und Inhalte bearbeiten.
Nein, Spaß beiseite. Also mich hat das damals bewogen, dass ich eigentlich die Strukturen, die sich hinter Sprache verbergen, wie funktionieren die eigentlich, dass ich das mega spannend fand, als ich das erste Mal drüber gestolpert bin und dann gesagt habe, hey, cool, das will ich mal studieren, ohne wirklich genau zu wissen, was ich hinterher damit machen will. Und das ist eigentlich auch schon so der Bogen zu meinem Einstieg ins Testen.
Irgendwann ergab sich, dass dann eine Professorin Hiwi suchte für das Thema Testen. Und dann habe ich hier geschrieben, weil ich gerade auf Jobsuche war. Und so bin ich halt ins Testen reingerutscht, wie das eigentlich alle Menschen so machen, dass sie ins Testen reinrutschen. Okay, achso, du meinst prinzipiell jeder, der irgendwann mal Systeme,
Produkte testet, hat das gar nicht wirklich studiert. sondern du sagst, die sind, oder ist deine Erfahrung, die sind alle dann so reingerutscht aus anderen Bereichen dahin gekommen. Ja, also ich kenne herzlich wenig Menschen, die irgendwie nach dem Abitur geschrieben haben, oh je oder ole, besser gesagt, ich möchte jetzt unbedingt Tester werden und also Studiengänge gibt es da ja auch wenig und bis gar nicht und Ausbildungsgänge ungefähr genauso viele, nämlich Richtung Null.
Und Testen ist halt etwas, was auch im Informatikstudium immer wieder zu kurz kommt und was man halt in der Praxis sehr häufig sieht, ist, dass dort viele Menschen sind, die die Quereinsteiger sind, weil sie einfach entsprechendes Fachwissen mitbringen und das war bei mir auch damals der Einstieg, dass ich dann über meine Sprachwissenschaftskenntnisse oder das Wissen, was ich da hatte, dann angefangen habe.
Sachen in einem sprachwissenschaftlichen Kontext zu testen Und so bin ich halt in diese Schiene testen reingekommen. Und ehrlich zu sein, fühle ich mich auch ganz wohl. Deswegen sitze ich hier noch. Ja, super. Was hast du denn zu Anfang getestet? Was war denn das für Produkte, Systeme? Systeme ist sogar das richtige Stichwort, bevor ich diese sprachwissenschaftlichen Sachen gemacht habe. An der Uni damals meine ersten Sachen, die ich getestet habe.
Offiziell hieß das Körper unterstützende Systeme. Wir kennen es meistens unter Matratzen und Stühle. Also ich war in der vergleichenden Warenprüfung und Forschung zunächst tätig und wir haben in der Tat Matratzen getestet. Und ja, bevor die Frage kommt, da gehört auch mal zu, dass man sich da mal eine halbe Stunde drauflegt und sagt, ist bequem und ist nicht bequem. Das ist wunderbar. Also so einen Test würde ich auch machen.
Musstest du dann parallel noch andere Tests durchführen, während du da gelegen hast? Ja, andere Tests nicht, aber wir hatten zumindest standardisierte Testumgebungen im Sinne von, dass das in Klimakammern passiert ist bei so und so viel Grad Celsius und so und so viel Luftfeuchtigkeit und solchen Sachen. Und wir haben auch Lasttests gemacht und all solche Sachen. Und war eigentlich ein spaßiger Job. Was weniger spaßig war, war halt so dieses typische Uni-Problem.
Projektbezogene Arbeitsverträge, die dann so drei Monate dauerten. Und dann habe ich irgendwann von so einem Headhunter eine Mail gekriegt, der sagte, Mensch, kannst du Computer ein- und ausschalten? Da habe ich gesagt, ja, kann ich. Und dann hat er gesagt, klar, dann gehst du jetzt Software-Tester. Oh Mann, das darf aber kein Softwareentwickler oder Softwaretester hier hören, dass man nur nach der Qualifikation ein- und ausschalten gefragt hat.
Ja, ein bisschen mehr war es dann schon. Aber beim Testen ist es ja nicht ganz verkehrt, wenn man auch die interne Perspektive manchmal komplett ausblenden kann und sich einfach mal vorstellt, wie würde ein Nutzer das Produkt? Oh ja, ja, ja, ja. Das finde ich auch super spannend, weil die sind ja am Ende des Tages die, die diese Systeme ja auch ein Leben lang irgendwo benutzen werden.
Nicht nur, also diese ganzen Interna, die betrachte ich ja auch nur während des Entwicklungszyklus und danach übergeben wir das ja an den Nutzer. Ja, eben. Als Nutzer interessiert mich das doch gar nicht, ob das elegant programmiert wurde oder die Requirements toll geschrieben wurden oder ja. Irgendwelche ganz tollen Testmethoden angewendet habe. Als Nutzer interessiert mich, löst mir das mein Problem? Hilft mir das Zeug?
Und wenn ich das nicht tut, kann es noch so elegant sein, dann nutze ich es nicht. Ja, genau. Löst ist mein Problem. Und komme ich auch mit den Bedienungsmöglichkeiten dann da zurecht, die es mir anbietet. Du, wir wollen uns heute ja über Riskstorming unterhalten. Das ist ein Thema, was du bei OSE vorangebracht hast, wo du, ich habe da mal nachgelesen, ich glaube seit 2020 verstärkt reingegangen bist. Und ja, vielleicht können wir erst mal anfangen damit zu beschreiben,
was ist denn überhaupt das Problem, was existiert und was du versuchst mit diesem Thema zu lösen. Ja. Ja, fangen wir mit der Frage mal direkt an. Riskstorming ist ein kollaboratives Workshop-Format, in dem wir im Team gemeinsam Risiken identifizieren können, um dann auf Basis dieser Risiken unsere Teststrategien, unsere Vorgehensweisen zu koordinieren. Das ist so ganz grob gesagt das, worum es bei Riskstorming geht.
Und das ist so ein spielerischer Ansatz, wo mit Basis eines Kartendecks, eines Kartenspiels gemeinsam dieses Thema angegangen wird. Und die Geschichte, du hast gerade eine Jahreszahl genannt, die Geschichte ist eigentlich noch ein paar Jahre älter. Ich habe das vorhin extra mal nachgeguckt, das ist inzwischen zehn Jahre her. Dass ich da irgendwann mal einen Blogpost geschrieben hatte,
ging es um Personas. Das kennen wir aus dem Requirements Engineering, funktioniert auch im Testen wunderbar, dieses Konzept. Und dann schrieb mich nach diesem Blogpost jemand an und sagte, Mensch, hier, ich will gerade eine Ressource für Tester entwickeln, wo es darum geht, einfach eine Wissensbasis aufzubauen. Und haben uns ein bisschen ausgetauscht und ein Jahr später, das war diese Person, ein Kartenspiel quasi rausgebracht als Wissensbasis für Tester.
Und um dieses Kartenspiel hat sich dann Jahre später auch dieses Restorming-Workshop-Format ergeben. Und seitdem bin ich da durchaus überzeugt von. Und das war auch schon deutlich vor meiner OSE-Zeit. Okay, also ihr habt das auf, oder das wurde dann entwickelt, weil ihr gesehen habt oder festgestellt habt, dass im Testen gewisse Probleme unter Umständen nicht angegangen werden oder nicht getestet werden.
Wie kann ich mir das vorstellen? Ja. Es ist so eine typische Frage, die man als Tester im Alltag immer wieder gestellt bekommt. Warum habt ihr das eigentlich nicht getestet? Hinterher sind wir alle schlauer, dann wissen wir, das hätten wir testen müssen. Und diese Frage wollen wir natürlich möglichst frühzeitig vorwegnehmen. Und ein Ansatz, der sich in den letzten Jahren durchaus etabliert hat, ist das risikobasierte Testen.
Also, dass wir uns von vornherein Gedanken machen, welche Risiken existieren überhaupt rund um ein Softwareprodukt und was können wir machen, um diese Risiken zu minimieren. Und da ist Testen ja durchaus ein valides Mittel. Über Testen kann ich halt die Eintrittswahrscheinlichkeit eines Risikos nach unten treiben, indem ich einfach sage, hey, wir haben unter diesen Konstellationen gezeigt, dass dieses Risiko nicht eintritt.
Und da kommt jetzt wirklich dieses Risk Swimming, dieses Workshop-Format ins Spiel, denn das ist so aufgebaut, dass es phasenorientiert vorgeht und die allererste Phase ist, dass wir uns interdisziplinär übergreifend zusammensetzen und erst einmal die entscheidenden Qualitätsmerkmale identifizieren. Das ist ja eigentlich etwas, was wir aus dem Requirements Engineering kennen und in der Architektur auch nutzen.
Spannenderweise, was wir im Test immer wieder feststellen, ist, egal mit welcher beteiligten Partei wir aus dem Software-Entwicklungs-Lebenszyklus oder Entwicklungs-Lebenszyklus wir reden, es haben immer doch wieder unterschiedliche Menschen ein unterschiedliches Verständnis, welche Qualitätswerkmale überhaupt die wichtigen sind. Und deswegen im ersten Schritt die Leute mal an einen Tisch zu holen und zu sagen, hey, worum geht es denn überhaupt? Was ist uns wichtig?
Ist uns die Performance wichtig? Ist uns das Zeitverhalten wichtig? Oder ist uns doch vielleicht eher sowas wie Security oder Wartbarkeit wichtig? Das einmal gemeinsam auf den Tisch zu bringen, halte ich für sehr, sehr sinnvoll. Und das ist der erste Schritt, mit dem Riskstorming halt einsteigt.
Und das Ganze spielerisch und auch mit einer Auswahl, Denn wir haben ja eben schon über Kunden und Anwender so ein bisschen gesprochen, denn im Endeffekt, wenn wir irgendwann mal Anwender fragen, was ist denn wichtig, ist die Antwort ja meistens ja alles. Und ganz so einfach ist es halt nicht. Und hier geht es halt im ersten Schritt darum, dass wir uns auf die Kernqualitätsmerkmale einmal einigen wollen. Ja, okay.
Das heißt also, diese erste Phase ist, ihr stellt zusammen, was sind die wichtigsten oder was sind überhaupt die Qualitätsmerkmale dieses Systems oder des Produktes und priorisiert ihr die dann auch schon in dem Moment? Also was ist davon noch am wichtigsten oder…. Naja, indirekt. Also dadurch, dass wir eine Auswahl treffen auf sechs Stück in diesem Format, haben wir die sechs wichtigsten.
Die sind jetzt untereinander nicht nochmal abgestuft, sondern wir sagen einfach, das sind die sechs Kernelemente. Und im nächsten Schritt geht es dann so vor, dass man sich zu jedem dieser Qualitätsmerkmale einfach einmal überlegt, was sind Risiken, die es potenziell dazu geben könnte. Also, dass wir auch dieses Risikothema loslösen von etwaigen Anforderungen und das Risikothema verknüpfen mit den Qualitätsmerkmalen. Was könnte bei dem Produkt möglicherweise schief gehen in dem Kontext?
Das ist so Schritt zwei. Okay, das heißt also danach, also du hast, was hast du gesagt, sechs, oder die sechs wichtigsten Qualitätsaspekte, die nehmt ihr danach raus und dazu überlegt ihr euch. Welche Risiken könnten denn auftreten oder was könnte denn die Ursache sein, dass jetzt so ein Qualitätsmerkmal nicht erreicht wird.
Ja, genau. Und das Schöne ist, mit ihr sind halt nicht nur wir Tester gemeint, sondern dadurch, dass das Ganze interdisziplinär stattfindet, sind alle beteiligten Parteien des Entwicklungszyklus mit dabei. Genau, ich meinte auch mit ihr das Team in diesem Workshop. Genau, genau. Genau, das ist vielleicht auch gar nicht mal so schlecht zu sagen. Also ihr, dieses Workshop-Team, ist interdisziplinär.
Da sind jetzt nicht nur Menschen aus dem Test mit dabei, sondern auch Entwickler, Entwicklerinnen, Produktmanagerinnen und Manager. Also alle, es könnten theoretisch alle daran teilnehmen, die irgendwas mit dem Produkt zu tun haben.
Ganz genau. Und ich habe es auch in der Vergangenheit mit Teams auch schon so gemacht, dass wir diesen Workshop natürlich nicht nur als One-und-Done-Geschichte machen, sondern immer mal wieder durchführen und das Ganze auch beleuchten und damit unterschiedliche Inhalte angegangen sind, von dem Gesamtprodukt bis zu Teilaspekten eines Produktes bis runter sogar zu einzelnen User-Stories. Und natürlich werden sich dann die Teilnehmenden auch verändern.
Also, wenn ich das ganze Produkt mir angucke, dann werde ich dort Kunden, Kundeninnen, Vertreter auch sitzen haben. Ich werde dort vielleicht auch die Anforderungsmenschen mitsitzen haben, die Programmierenden, die Architekten, Architektinnen, während ich, wenn ich vielleicht mit der User Story selber am Markieren bin, dann sitze ich da vielleicht noch mit dem Scrum Team zusammen.
Also das kann durchaus unterschiedliche Personengruppen haben, aber wir haben immer eine gewisse Interdisziplinarität. Ich möchte halt nicht, dass es jetzt eine Gruppe gibt, die die Risiken für alle festlegt. Und das zeigt auch so ein bisschen, dass dieser Ansatz eher so aus dem Agilen auch kommt und weniger so aus dem klassischen Risikomanagement, wo wir vielleicht sogar dedizierte Risikomanagerinnen sitzen haben, die sich genau mit dieser Thematik beschäftigen.
Okay, aber diese Person, diese Risikomanager und Managerinnen, die könnten ja jetzt dieses Workshop-Format hernehmen und dann in die Teams reingehen und das Ganze herauskitzeln, also diese Risiken herauszukitzeln, zu identifizieren, das ist ja eigentlich auch deren erster Schritt in ihrem eigenen Prozess. Exakt. Und das Schöne an dem Format ist, dass es auch relativ gut zugänglich ist.
Also durch diesen Kartenspielansatz, durch diesen Gamification-Ansatz müssen wir gar nicht bis auf die technische Ebene runter, sondern können auch durchaus auf der Produktebene machen. Also ich habe das neulich mal in einem Meetup gemacht und da haben wir das mit Menschen gemacht, die überhaupt nicht aus der IT kamen.
Da hatte ich dann auf einmal Menschen, die aus dem Foodbusiness kamen, also die wirklich Lebensmittel hergestellt haben und so weiter und das war total spannend, was die auf einmal für Aspekte gebracht haben. Ich nutze in meinen Meetups und so weiter, nutze ich gerne irgendwie irgendwelche popkulturellen Beispiele, so Raumschiff Enterprise oder irgendwas aus Krieg der Sterne, halt irgendwas, was jeder kennt, so nach dem Motto.
Und es war total spannend, was die für Qualitätsmerkmale auf einmal bei so einem Raumschiff in den Vordergrund stellen, wo Entwickler und Menschen aus dem technischen Hintergrund auf einmal ganz andere Sachen nutzen oder sagen würden. Okay. Ja, und dann, du hast eben gesagt, du gehst bis runter auf die Ebene, wo User-Stories für Softwareentwicklende geschrieben werden.
Und das zeigt ja auch wirklich diese ganze Bandbreite, dieser Prozess des Risikomanagements, der ist ja egal, wo du hinguckst, ob du nun in die klassische Entwicklung guckst oder in die agile Entwicklung, die ist ja immer über den gesamten Entwicklungszyklus gezogen. Also du kannst ja immer wieder erkennen, das musst du während der gesamten Entwicklungszeit musst du da drauf achten. Egal, was da jetzt kommt, Risiken identifizieren oder managen. Aber das kann sich ja auch wiederholen.
Genau. Und das ist aus Testensicht leider etwas, wo wir häufig einen Bruch haben, dass diese Informationen beim Testen nur sehr rudimentär ankommen. Also das Thema rund um Risiken ist häufig etwas, das findet sich dann in der Architektur wieder, das findet sich vielleicht auch in den Anforderungen wieder. Aber diese Zwischenschritte, die wir definitiv brauchen, da müssen wir nicht drüber reden, da wird das Thema Risiko häufig etwas verbessert und geht verloren.
Und durch diesen interdisziplinären Ansatz haben wir als Testsicht natürlich den schönen Vorteil, weil wir hiermit involviert sind, dass wir gleich bei den Risiken mit dabei sind. Und das Schöne ist, dass wir dann in der dritten Phase von diesem Risk-Storming das gleich nutzen können und uns überlegen, hey, wie werden wir überhaupt diese Risiken mitigieren wollen durch Testansätze?
Also, dass wir uns überlegen, was sind Methodiken, was sind Heuristiken, was sind Ansätze, die wir hier nutzen können, was sind verschiedene Muster, die wir hier erwarten, um diese ganzen Sachen auch zu sehen. Ein Teil der Karten geht sogar um Gefühle, so wildes Zeug sprechen wir normalerweise nie drüber, so Gefühle in der Softwareentwicklung. Nee, nee, bloß nicht. Nein, auf gar keinen Fall, gerade in Norddeutschland, nee, machen wir nicht, genau.
Du, ich weiß ja auch immer, du hast es auch ein Gefühl, ne? Wenn du das sagst, dann glaube ich dir das sofort. Nein. Durst steht nicht bei den Karten dabei, aber da sind auf einmal so Sachen wie Gleichgültigkeit. Und das ist zum Beispiel ein Gefühl, was wir als Tester total schlimm finden. Also, wenn wir irgendwie erwarten, dass Anwender, Anwenderinnen gegenüber einem Aspekt unserer Software komplett gleichgültig sind, ja, warum ist das so? Brauchen wir diesen Aspekt der Software überhaupt?
Sind sie gleichgültig, weil sie resigniert haben? Sind sie gleichgültig, weil sie es nicht brauchen? Ja, also, wenn man sich solche Gedanken schon im Vorfeld macht, dann kann das durchaus auch ganz hilfreich sein, um einen gewissen Fokus auf das Testen auch zu bekommen an der Stelle.
Das Schöne ist dadurch, dass wir jetzt hier gemeinsam diese Karten schmeißen und das sind wirklich ja, du hast das Deck ja auch schon in der Hand gehabt, das sind ja, wir sprechen ja nicht von 20 Karten, sondern vielleicht so 150, 200 Karten. Da kann ich richtig schön schon mal festlegen, hey, was will ich wo an welcher Stelle bei welchem Risiko überhaupt machen, was erwarte ich da?
Und das ist total super, um einen ersten Schritt, einen ersten Wurf in Richtung einer gemeinsam erstellten Teststrategie zu haben und vor allen Dingen einer risikobasierten Teststrategie. Ja, genau. Da wollte ich nämlich auch noch drauf hinaus, weil du eben gesagt hast, das wird auch gerne mal vergessen, dass das weitergegeben wird in Richtung Tests.
Also, zu Anfang hat vielleicht irgendjemand da gesessen, der oder die Risikomanagerin, diverse Sachen aufgeschrieben, vielleicht auch alten Projekten übernommen und dann in irgendeine Liste gefüllt und dann damit die Architektur gefüttert. Und dann bleibt das auf der Strecke. Dann werden Tester, Testerinnen nicht involviert in das Thema und die wissen natürlich dann auch nicht, was sie testen sollen. Also wo hat jetzt das Testmanagement ein besonderes Risiko identifiziert?
Dann muss das natürlich auch irgendwo in der Teststrategie abgedeckt sein, damit wir sicher sein können, dass wir das mit diesen Maßnahmen auch eliminiert haben oder zumindest nicht. Auftritts- oder Auswirkungswahrscheinlichkeit reduziert haben. Das muss ich ja irgendwie versuchen nachzuweisen.
Genau. Und gerade in Situationen, wo ich vielleicht noch einen Medienbruch habe, also wo die Leute gar nicht mehr miteinander reden, sondern dass irgendwie in irgendwelchen Dokumenten einfach nur festgehalten wird. Ja, und also ist ein Basketballtrainer gewesen, aber ich bin ja trotzdem recht, der hat irgendwann mal gesagt, naja, was Person A sagt, was B versteht und was Person C wirklich gemeint hat, das sind drei verschiedene Sachen. Und dieses Phänomen kennen wir ja alle in der Kommunikation.
Und deswegen hier jetzt auf einmal die Leute an einen Tisch zu holen, hat sich aus meiner Sicht sehr, sehr bewährt. Ja, das ist gut. Ich habe jetzt aus diesem Riskstorming bis jetzt zwei Phasen oder haben wir schon drei Phasen, vier Phasen beschrieben? Wir sind in der dritten, oder? Wir sind in der dritten, genau. Wir haben Phase 1, wo wir die Qualitätsmerkmale gemeinsam festlegen. Phase 2, wo wir die Risiken spezifisch für diese Qualitätsmerkmale identifizieren.
Und Phase 3 ist dann diese Mitigationsmaßnahme. Also was wollen wir tun, um überhaupt diese Risiken anzugehen, zu testen. Das ist so die dritte. Und ja, das ist aber nicht die letzte. Es kommt noch eine vierte, denn was häufig natürlich auch passiert ist, dann machen wir so einen Workshop, haben irgendwie wunderbare Karten dahingeschmissen, haben vielleicht auch noch ein Foto davon gemacht, um das Ganze zu dokumentieren und dann landet es in irgendeiner Schublade.
Natürlich blöd, wie bei allen anderen Sachen, die in irgendwelchen Schubladen landen. Und deswegen ist Phase 4, das ist gerade bei der Online-Variante von Risk Swimming, sehr, sehr stark im Mittelpunkt auch, dass wir einfach mal festlegen, hey, wer nimmt sich überhaupt welches Themas an? Also, dass wir jetzt überlegen, das Risiko X, nimmt das Björn mit oder nimmt das Christian mit? Wer kümmert sich da drum?
Und da können wir vielleicht sogar, ich will nicht sagen priorisieren, aber zumindest vielleicht auch schon irgendwelche Meilensteine festlegen, dass wir sagen, so, okay, das Thema muss bis dahin aber geklärt sein, wenn wir so etwas schon absehen können. Und dass wir sagen können, hey, wir müssen bis zum ersten, dritten oder so etwas auf jeden Fall uns mit diesem Risiko weiter auseinandergesetzt werden.
Und diese ganze Information, ich meine, ganz ehrlich, das ist aus Testsicht nichts anderes als die ganzen Sachen, die ich sowieso in mein Testkonzept hinterher reinschreiben würde. Und insofern haben wir hier ein gemeinsam vorbereitetes Testkonzept, auf das wir uns dann hinterher auch alle berufen können.
Und das ist eigentlich ein ganz schöner Aspekt. Ja, das finde ich auch immer sehr schade, wenn dann diese Themen, die man besprochen hat in so einem Workshop, wenn die dann irgendwo untergehen und gar nicht mehr weiterverfolgt werden. Da brauchst du ja am Ende des Tages jemanden, der sich auch irgendwie darum kümmert. Genau, und deswegen ist so ein Plan gar nicht mal so verkehrt.
Und hier an dieser Stelle könnte man ja vielleicht auch sagen, das liegt dann am Ende des Tages bei dem Team oder die Person, die sich ums Risikomanagement kümmert, das einfach mitzunehmen und in die verschiedenen Bereiche, die du auch eben schon angesprochen hast, Architektur, Entwicklung, Testing, dann mit reinstreut. Dass man das einfach auch kommuniziert. Hey, wir müssen da irgendwie noch einen Schutz bauen in der Architektur.
Das muss implementiert werden. Wisst ihr das? Habt ihr das auf dem Schirm? Wenn nicht, müssen wir da noch eine User-Story schreiben. Und natürlich muss es dann nachher auch im Testplan, in der Teststrategie auftauchen. Ganz genau. Und was ich halt am Riskstorming so sehr mag, ist, dass es sehr, sehr leichtgewichtig ist. Also, denn was haben wir meistens nicht?
Zeit. Und deswegen uns ein schwergewichtiges Risikomanagement aufzubauen, dass das, ich muss es anders formulieren, so ein schwergewichtiges Risikomanagement, das kann super hilfreich sein. Und gleichzeitig fällt es sehr, sehr häufig hinten runter, weil wir keine Zeit haben, weil wir immer getrieben sind von, irgendwie hat das man es schön als Delivery Trap beschrieben, wir müssen Features liefern, liefern, liefern, liefern.
Weil wir immer nur liefern müssen, kommen wir gar nicht dazu, uns um die wichtigen Sachen auch zu kümmern, die dabei helfen, die Sachen, die wir liefern, überhaupt gut zu machen. Und da kann Riskstorming als ein sehr leichtgewichtiges Workshop-Format echt gut seine Karten ausspielen, um diesen Karl Lauer jetzt hier mal bei dem Kartenspiel zu machen. Genau, also vielleicht kannst du uns ja nochmal ein paar Worte zu dem Spiel, vielleicht auch noch zu der Haptik erzählen.
Ich habe das ja einmal mit dir zusammen mitgemacht. Du hattest da ein Spieltableau und wir hatten verschiedene Karten, daran kann ich mich noch erinnern. Und diese Phasen hast du dann entsprechend anmoderiert oder Ja, genau. Fazilitiert. Ja, Neudeutsch facilitated. Ja, genau. Aber im Prinzip trifft es das ganz gut. Also es gibt, und wenn man im Internet danach googelt, findet man das, oder eine andere Suchmaschine seiner Wahl nutzt, findet man das Spielbrett auch sehr schnell.
Das ist also Open Source, das ist frei zugänglich. Und das soll das Ganze ein bisschen unterstützen. Es geht auch ohne Spielbrett. Das Entscheidende ist wirklich dieses Kartenspiel. Also das ist ein Kartenspiel mit bestimmt 200 Karten, mit verschiedenen Kategorien. Wir haben einmal farblich codiert die Qualitätsmerkmale, wir haben farblich codiert verschiedene Techniken, verschiedene Heuristiken, verschiedene Muster, die eben schon erwähnten Gefühle.
Und man muss sich das im Prinzip vom Format her so vorstellen wie ein ganz normales Skatblatt. Also die Karten haben das gleiche Format, da sind halt nur keine Symbole und Ziffern drauf, sondern da sind dann halt Beschreibungen drauf. Also das geht von so Sachen wie Äquivalenzklassen, die die meisten vielleicht mal irgendwo aufgeschnappt haben, bis hin zu so...
Was ist meine Lieblingskarte? Der Ikea-Effekt. Man ist ja immer stolz auf Sachen, die man selber zusammengeschraubt hat, als auf Sachen, die man fertig kauft. Und das sind Sachen, die vielleicht auch in unserer Risikostrategie mit berücksichtigt werden müssen, dass wir in der Vergangenheit immer zu sehr von unseren eigenen Produkten überzeugt waren. Ist das etwas, was wir in Zukunft mal betrachten müssen? Und da gibt es halt wirklich sehr, sehr, sehr, sehr viele Karten.
Das Kartenspiel selber gibt es seit, ich sagte es eben schon, seit gut zehn Jahren jetzt auf Englisch und wir haben bei OSE vor ein paar Jahren dann mal, ich will nicht sagen so eine Nacht-und-Nebel-Aktion, aber durchaus mal eine Kleinserie auf Deutsch auch drucken lassen, um halt das Ganze auch hier in Deutschland noch ein bisschen populärer zu machen. Genau.
Okay, und dann bist du im Team unterwegs und da bekommt nicht jeder alle Karten, sondern du verteilst dann diese Karten entsprechend der Farbcodierung an die jeweiligen Leute oder also Farbcodierung gleich Testschwerpunkt oder wie macht ihr das dann? Ja, ganz eindeutig ist, es kommt darauf an.
In der ersten Phase, wo wir uns nur mit den Qualitätsmerkmalen beschäftigen, nehmen wir uns natürlich erstmal nur die Farbe, die anderen lassen wir erstmal außen vor und wir haben dann ein Deck pro Team, pro Gruppe, das sich innerhalb dieses Workshops gerade befindet. Das hat aus meiner Sicht den irrsinnigen Vorteil, dass man miteinander reden muss. Dass ich nicht einfach nur stumm meine Karten hinschmeiße, sondern dass wir uns darauf einigen müssen.
Und das ist etwas, was man auch sehr häufig beobachtet, dass dann erst einmal relativ stumm so Karten hingelegt werden und irgendwann... Kommt an dieser Punkt, gerade bei den Qualitätsmerkmalen, wenn man sich auf sechs einigen muss, dass man anfängt, darüber zu reden. Warum sehe ich das so? Warum ist das aus Anforderungssicht dieses Qualitätsmerkmal wichtig? Warum ist aus Architekturperspektive jenes wichtig? Warum ist vielleicht dieses aus Testenperspektive besonders wichtig?
Und damit bekomme ich auch nochmal einen Einblick, warum dieses Qualitätsmerkmal an der Stelle vielleicht anderen Menschen auch wichtiger ist, was ich vorher sonst vielleicht nicht gewusst hätte. Und das passiert natürlich nicht nur bei den Qualitätsmerkmalen, sondern auch hinterher bei den Heuristiken, bei den Methoden, wo wir festlegen, was wir dagegen machen wollen, dass man sich überlegt, so hey, haben wir das berücksichtigt? haben müssen, sollten wir das?
Ist das etwas, was überhaupt nicht im Fokus ist? Auch das ist total legitim, zu sagen, ganz ehrlich, Performance interessiert uns nicht. Das ist okay, aber das ist auch gut, dass wir das mal ausgesprochen haben. Ja, weil sonst gibt es ja auch die Gedanken bei anderen Menschen, die an dem Produkt beteiligt sind, an dem System beteiligt sind, die sich denken, Performance, das ist besonders wichtig, da muss ich drauf achten.
Aber so wie du es jetzt sagst, dann spricht man drüber, dann erklärt man vielleicht auch mal den Einsatzzweck und dann versteht man plötzlich, ach, ja, das ist gar nicht so wichtig. Also dieser muss nicht innerhalb von zwei Sekunden geantwortet haben, sondern da reicht es auch, wenn die Antwort nach zehn Sekunden da ist, weil diverse andere Oberflächen oder Aktionen oder sonst was da noch durchgeführt werden, die das Ganze überdecken.
Ja, genau. Oder Gegenbeispiel, was ich in einem Workshop noch nicht hatte, war, da waren sich alle einig, die Performance ist gar nicht wichtig. Und dann kam einer um die Ecke und sagte, Leute, euch ist klar, nächstes Jahr gilt eine neue Norm für uns und diese Norm fordert Folgendes. Und da war dann auf einmal festgehalten, dass das System innerhalb von, ich weiß die Zeitspanne nicht mehr, aber innerhalb einer bestimmten Zeitspanne
eine Reaktion liefern muss. Und alle so, oh nee, das war uns gar nicht klar. Und dieses implizite Wissen, was dann einer dort hatte, das ist dann einfach in diesem Gespräch mal explizit gemacht worden. Auf einmal wurde dann das Thema Performance deutlich, deutlich nach oben gepriorisiert auch. Okay, und dann, das war einmal bei der Identifikation, da hast du so ein paar Sachen festgelegt und dann werden auch über diese Risiken diskutiert.
Ich weiß, dass ich da, ich musste mir nicht alle Karten durchlesen, nicht alle 200 Karten, sondern ich bekam so ein paar davon in die Hand. Und wie war denn da die Auswahl nochmal? Da kann ich mich gar nicht mehr so genau dran erinnern. Hattet ihr die dann durch Zufall verteilt oder wie war das, wie ist das passiert? Die zweite Phase ist nicht mit Karten, sondern wir nutzen Haftklebezettel eines Herstellers deiner Wahl, wo man sich dann frei zu den Qualitätsmerkmalen einfach mal überlegt.
Also welches Risiko könnte meinetwegen zum Qualitätsmerkmal Performance überhaupt eintreten? Wir haben da keine vorgefertigten Risiken.
So ein Standardkatalog an Risiken, der hilft mir nicht wirklich weiter, sondern wir wollen dort dann die Risiken uns selber überlegen und das Schöne ist, dadurch, dass wir hier jetzt uns die Risiken gezielt für die Qualitätsmerkmale überlegen, haben wir nochmal einen leicht anderen Drall darauf, als wenn wir einfach nur die Risiken zu den Anforderungen uns angucken. Ach so, auf den Karten sind die Qualitätsmerkmale drauf. Exakt. Ah, ja, okay, gut.
Das wollte ich jetzt nochmal explizit hier festhalten. Super. Okay, und dann geht ein sehr kreativer Prozess einher, wie ich dich jetzt verstanden habe, zu diesen sechs ausgewählten Qualitätskriterien werden sich dann, denkt man sich dann diese Risiken aus, die das Projekt torpedieren könnten. Okay. Ja, das Projekt und das Produkt vor allen Dingen auch am Ende. Also das ist dann, ob man da ein normales Brainstorming macht oder irgendwelche Kreativtechniken, das bleibt jedem selbst überlassen.
Ich habe meistens mit einfachem Brainstorming schon relativ gute Erfahrungen gemacht, dass man sich wirklich das anguckt. Das ist mein Qualitätsmerkmal A, das ist mein Qualitätsmerkmal B und dann geht man die durch und überlegt sich, welche Risiken können dazu auftreten. Was kann uns hier gefährden? Ja, okay, gut. Und dann hat man nachher zu diesen Qualitätsmerkmalen diverse Risiken und darauf könnte ich mir dann in der Phase 3 überlegen, wie kann ich diese Risiken denn einfangen.
Genau. Entweder minimieren oder die Auswirkungswahrscheinlichkeit oder Schwere reduzieren. Ja, über Testen haben wir meist keinen großen Hebel auf die Schwere, sondern mehr auf die Eintrittswahrscheinlichkeit. Aber klar, wenn mir Sachen einfallen rund um das Thema, wie kann ich ein Risiko vom Schadensmaß eher kleiner bekommen, auch das sollte dann natürlich mit einfließen. Aber meistens werden wir uns dadurch etwas überlegen, welche Art von Heuristiken wollen wir beim exportiven Test nutzen?
Welche Testmethoden wollen wir hier nutzen, um überhaupt gezielt ranzugehen? Ist so etwas wie Last- und Performance-Tests sinnvoll? Das sind so Sachen, mit denen wir uns da beschäftigen. Also im Prinzip schon mal so eine grobe Strategie festlegen, wie wollen wir dieses Risiko überhaupt angehen? Aus Testsicht wohlgemerkt. Okay, cool. Und dann hat man ja eine wunderbare Liste, die man im Risikomanagement und vor allem dann im Testen auch verwenden kann und abarbeiten kann.
Wenn da steht, das wollen wir durch Testschritte, Testszenarien abdecken, dann ist das ja für die Testabteilung eine wunderbare Liste, die abgearbeitet werden kann. Exakt. Ich setze nämlich erst einmal Leitplanken, innerhalb derer ich mich bewege. Also da putzt du jetzt noch keine klaren Testfälle oder so etwas. Nee, nee, nee, das verstehe ich. Das ist auch viel zu früh.
Aber wir haben erst einmal Leitplanken, innerhalb derer wir dann hingehen können und mit unseren her eingebrachten Testmethoden dann uns überlegen können, die Testfälle zu schreiben. Wir wissen also, wo wir den Fokus, wo wir den Schwerpunkt nehmen müssen. Ja, genau, genau. Weil wenn irgendwas beim Testen nicht funktioniert, dann ist es so nach dem Gießkannenprinzip überall so ein bisschen.
Ja, das wird dem Produkt nicht gerecht, sondern wir müssen natürlich unsere Schwerpunkte setzen und dadurch, dass wir hier unsere Schwerpunkte jetzt auf die Risiken setzen, können wir dann hinterher dafür sorgen, dass die Kunden hoffentlich auch das Produkt haben, was sie wollen und nicht nur das, was beschrieben wurde, sondern das, was ihnen dann auch wirklich hinterher hilft, ihr Problem zu lösen. Ja, genau.
Ja, und so hat man dann auch wirklich diesen Durchgang von diesen Phasen bis rein in die Teststrategie. Das heißt also, die sind dann wirklich nicht verloren. Und jetzt kann man sich selber noch überlegen, ob man da irgendwelche Traceability oder was auch immer einbaut.
Würde ich jetzt sagen, muss nicht zwangsläufig sein. Aber wer das haben möchte, wer dann diesen Prozess auch noch mal durchführen will, so wie du es gesagt hast, da ist es ja dann vielleicht auch sinnvoll, wenn man sieht, okay, dieses Testszenario haben wir entworfen, weil wir vor zwei Monaten das Ganze hier schon mal gemacht haben. Und da sind gewisse... Risiken identifiziert worden? Also bei mir rennt zu öffnet Tournein ein, was das Thema Traceability angeht.
Also bin ich ein großer Freund von. Und ich würde auch einhergehen und die Risiken, die wir identifiziert haben, vielleicht im Sinne einer Risikoliste irgendwas irgendwo aufzuführen und dass ich dann eine Traceability zwischen der Risikoliste und den einzelnen Elementen dieser Liste und den Testfällen hinterher aufbaue, klar. Also das gehört für mich zum guten Handwerkszeug dazu. Genau, aber ist jetzt hier nicht in diesem Podcast der Fokus.
Können wir gerne mal was anderes besprechen. Sehr gerne. Weil ich finde auch, dass das unglaublich weiterhilft. Aber ja, wunderbar. Ich persönlich habe jetzt viel nochmal über das Riskstorming gelernt, wie es abläuft. Ich glaube, es macht jetzt hier keinen Sinn, diese ganzen Risiken, nein, die ganzen Qualitätsmerkmale im Detail zu besprechen. Dazu kann man sich ja vielleicht selber, wenn man daran interessiert ist, dieses Kartendeck kaufen.
Ich habe es schon gesehen, dass es das irgendwo im Netz im Englischen gibt. Du hast gesagt, es gibt da auch eine limitierte Auflage auf Deutsch. Ja, also die englische Version gibt es beim Ministry of Testing. Da mache ich jetzt auch gerne hier schamlos Werbung für. Da kann man sich die bestellen. Es gibt eine Kleinserie auf Deutsch.
Wer da Interesse hat, kann gerne auf mich zukommen. Die verkaufen wir bei Ose quasi zum, zum Selbstkostenpreis, also wir wollen da irgendwie nicht großartig Umsatz mitmachen, aber wir wollen zumindest unsere Druckkosten wieder reinbekommen, also von daher so zwei, drei haben wir da noch und als wer das Interesse hat, kann ich gerne auf mich zukommen.
Und wer erstmal einen Blick vorab werfen möchte, es gibt übrigens Riskstorming Online, da kann man sich das Ganze vorab schon mal im Netz angucken, wenn man sagt, wir sind mit verteilten Teams unterwegs und können uns gar nicht so physisch in einem Raum ständig treffen. Das geht natürlich auch online heutzutage alles. Okay, und du bietest das auch als moderierten Workshop an?
Ja. Okay, also wer das gerne im Team dann machen möchte, kann sich dann auch über dieselbe E-Mail-Adresse christian.gram.ose.de bei Christian melden und kann sich dann dort ein Workshop für sein eigenes Team buchen. Kommt Christian bestimmt gerne rum. Ja, klar. Daran wird es nicht scheitern. Genau. Christian, super Thema. Finde ich jedenfalls zur Erweiterung, zum ganzen Rundmachen im Systems Engineering, wo ich ja hier diesen Podcast zu betreibe.
Und hat mir wirklich Spaß gemacht. Bevor wir jetzt rausgehen, haben wir irgendwas vergessen? Also haben wir alle Themen besprochen oder hast du da noch irgendwas, wo du sagen würdest, boah, also Riskstorming, das hätten wir eigentlich auch sagen müssen? Risk-Storming ist ein großes Thema auf dem QS Barcamp.
Das ist so ein Community-Event, was wir einmal im Jahr in Hamburg veranstalten und da ist das ursprünglich vor ein paar Jahren auch mal vorgestellt worden und letztes Mal im Herbst ist auch die neue Version des Kartenspiels dort auch etabliert worden. Also wer das einfach mal zwanglos ausprobieren möchte und irgendwie im Großraum Hamburg oder so unterwegs ist, möchte ich hiermit sehr warm, wärmstens das QS Barcamp ans Herz legen. Das ist wirklich eine nette Community-Veranstaltung.
Kommt vorbei, wir freuen uns. Ja, das stimmt. Barcamps sind sowieso immer wunderbare Netzwerkveranstaltungen. Das kann ich nur bestätigen. Okay, alles das, worüber wir gesprochen haben, das englische Kartenspiel, Riskstorming Online und das QS Barcamp sowie E-Mail-Adressen und die Beschreibung vom Riskstorming auf den OSE-Seiten werde ich in die Shownotes packen, sodass das problemlos aufgerufen werden kann.
Und dann bleibt mir jetzt nur noch übrig, dir herzlichen Dank zu sagen, Christian, dass du hier warst, dass du dieses Thema vorgestellt hast. Und ja, ich wünsche dir noch ein wunderbares Jahr 2025. Ja, herzlichen Dank. Es hat mich sehr gefreut, hier zu sein. Und ich weiß gar nicht, über 200 Folgen mit dem Podcast, das ist echt große Leistung. Ich freue mich, dass ich Teil davon sein will. Du bist 229 jetzt. Das stimmt. Fast meine Hausnummer. Naja. Alles klar. Danke, Christian. Danke, bis dann.
Das war mein Interview mit Christian Kram, Trainer für System- und Software-Tests bei der Firma Ose in Hamburg. Zusammenfassend für die heutige Episode unsere drei Tipps. Identifiziere die gewünschten Qualitätsmerkmale für dein System, werde kreativ bei der Findung von möglichen Risiken, die sich aus diesen Qualitätsmerkmalen ableiten und bewerte diese Risiken und erstelle einen Plan, wie diese größten Risiken eliminiert werden können.
Das war die heutige Episode des Zukunftsarchitekten, der Systems Engineering Podcast für Machende und Entscheidende. Mein Name ist Björn Schaure und ich danke dir fürs Zuhören. Hab Spaß an dem, was du machst und vor allem wünsche ich dir einen hohen Wirkungsgrad. Tschüss und bis zum nächsten Mal. Music.