Ein Vortrag, ein Podcast und eine Auszeichnung

Notizen von einem überhaupt nicht alltäglichen Konferenzbesuch Zugegeben: Unsere Teilnahme am QS-Tag 2023 in Frankfurt zog ja bereits den einen oder anderen Post auf diversen isento-Kanälen nach sich. Aber der charmanten Frage meiner Marketing-Kollegin („Wärst Du vielleicht bereit, einen Blogbeitrag…?“) kann ich mich nicht verweigern – zumal ich auf diese Weise nochmal „in der Totalen“ von einem rundum schönen und erlebnisreichen Event berichten darf. (Foto: Christian Brandes) Erste Etappe: Deutsche Bahn, 12.10.23. Es geht sehr früh mit dem Zug nach Frankfurt und zur Location. Pünktlich zur Konferenz-Eröffnung bin ich zwar nicht am Ziel, aber dafür vermeide ich Warteschlangen an der Registrierung und werde dort nicht nur hochprofessionell und freundlich begrüßt und versorgt, sondern – roter Faden dieses Events – treffe permanent bekannte Gesichter wieder! Das ist ausnahmslos ein Grund zur Freude und wird dafür sorgen, dass ich an den kommenden zwei Tagen viel und lange an Bistro-Tischen mit anderen Teilnehmer:innen diskutiere… und dafür weniger Vorträge höre. Aber die Gesprächsthemen in den Foyers und an den Ständen sind einfach zu spannend, und an allen für mich interessanten Programmpunkten kann ich eh nicht teilnehmen (4 parallele Tracks = Qual der Wahl). Wirklich unverrückbare Termine habe ich außerdem nur zwei: den eigenen Vortrag, und eine Podcast-Aufnahme mit Richard Seidl. Zu beidem gleich mehr. Zweite Etappe: Ein Wiedersehen mit Christa Preisendanz vom dPunkt-Verlag. Diesmal gibt es an ihrem Stand nicht nur Verkaufszahlen und Buchideen zu bereden, sondern Bücher zu signieren: Der Verlag stiftet 5 Exemplare von „Basiswissen Modellbasierter Test“ für eine Verlosung, was nicht nur toll für das Thema ist, sondern auch zu einem Wiedersehen mit fast allen Co-Autoren von 2010 führt. Danke für beides! Warum die Bücher-Verlosung? Auch hier haben Richard und sein Podcast die Finger im Spiel… aber immer der Reihe nach. v.l.: Christa Preisendanz, Andreas Spillner, Mario Winter, Karin Vosseberg (Foto: QS-Tag) (Foto: QS-Tag) Dritte Etappe: Vortrag halten! Ich gestehe, mir im Vorfeld ernsthaft Sorgen über die zu erwartende Teilnehmerzahl gemacht zu haben, denn zeitgleich mit mir referieren Klaudia Dussa-Zieger (ISTQB-Präsidentin!) und Mario Winter (nochmal hallo, Co-Autor!) über Version 4.0 des CTFL-Lehrplans. Und das interessiert ja nun wirklich jede:n Tester:in… Also stelle ich mich vorsorglich darauf ein, die 5 Nasen im Publikum, die sich für „Testbarkeit von User Stories“ interessieren, zu Beginn persönlich miteinander bekannt zu machen und dann loszulegen… Die Sorge indes erweist sich als unbegründet, der Saal ist ab 16:40 gut gefüllt.    Kurz vor Vortragsbeginn: Abstimmung mit dem Trackchair Hermann Will & dann doch ausnahmsweise mal technisches Gefrickel an einem etwas unkonventionellen Audio-/Video-Setup – aber rechtzeitig spielen alle Hardware-Komponenten brav mit, Headset & Presenter & Wasser sind am Start, das Adrenalin läuft mir gefühlt schon aus den Ohren… …und die Zeit auf der Bühne geht wie immer wahnsinnig schnell vorbei, die Rückfragen aus dem Publikum sind richtig klasse, und dann fliegt auch schon das erste Feedback auf diversen Kanälen ein. Wow! Vierte Etappe: Abendevent. Nur so viel: viel Essen, viele Gespräche, viele Überraschungen. Rundum gut! Tilo Linz und die Transformers (Foto: Christian Brandes) (Foto: Richard Seidl) Fünfte Etappe: 13.10., 10 Uhr, Aufnahmetermin. Richard Seidl hatte mich im Vorfeld angefunkt und gefragt, ob ich mit „meinem“ Vortragsthema für eine Podcast-Folge zur Verfügung stünde. Ist der Papst katholisch? Supergerne natürlich! Ich durfte ja selbst einige Jahre lang einen Podcast über Softwaretest & Agilität betreuen und moderieren, und das machte nicht nur unglaublich viel Spaß, das fehlt mir bis heute! Ich ziehe übrigens vor Richies Arbeit in großem Bogen meinen Hut: Besser hätte man einen deutschsprachigen Podcast zu Test- und QS-Themen nicht aufziehen können. Sein Backlog ist gut gefüllt, sein Equipment untadelig, seine Moderation sympathisch und professionell. Ich kann mit dem Begriff „Ehre“ zwar sehr wenig anfangen, fühle mich aber – wenn ich mir Richies bisherige Episoden anschaue – doch geehrt und bin dankbar, bei diesem famosen Projekt mitwirken zu dürfen. Als Win-Win-Situation verlost Richie gerne Bücher, wann immer er Autor:innen vor dem Mikrofon hat. Deshalb liegen die 5 am Vortag signierten Exemplare vor uns auf dem Aufnahmetisch, denn ich werde nicht nur akustisch aufgezeichnet, sondern auch noch gefilmt (ungewohnt!), so dass wir gegen Ende der intensiven 25 Minuten auch eins der Exemplare in die Kamera halten können. Als wir uns verabschieden, bin ich richtig happy über die Aktion, werde aber – da Richie erstaunlich viele neue Folgen an den zwei Konferenztagen eintüten wird – noch bis Januar auf die Veröffentlichung warten müssen. Sechste Etappe: Abschluss, und zugleich für mich die unerwartete Kirsche auf dem Kuchen, denn ich darf den diesjährigen „Best Presentation Award“ entgegennehmen. Mir fehlen die Worte, als ich davon erfahre, springe auf die Bühne, versuche beim Danke-Sagen niemanden zu vergessen… und muss dann schon zügig auf zu Taxi & Bahnhof, zurück nach Nürnberg, immer noch überwältigt und sehr, sehr happy. Die Reaktionen seitens isento an diesem Abend auf die Neuigkeit machen natürlich auch viel Spaß, und am Montag drauf wuchte ich die stilvolle Trophäe ins Office und merke: Da bin ich schon ein bisschen stolz drauf. Was habe ich außerdem mitgenommen? Viele fachliche und Tool-Ideen, viele neue persönliche und LinkedIn-Kontakte, Anfragen für Folgegespräche… und von Rudolf Groetz die Einladung, den gehaltenen Vortrag, aber bitte auf Englisch, auf seiner „TestBustersNight“ Anfang 2024 zu wiederholen (inzwischen geschehen). In Summe: zwei prächtige Tage! Hasn’t us? 😃 P.S.: Lust, selbst mal dabei zu sein? Der Call for Papers zum QS-Tag 2024 läuft bereits! Dr. Christian Brandes Christian ist Head of Software Test and Quality Assurance bei isento

Systematische Tests als Ergänzung für erfahrungsbasierte Tests

„Discard an axiom.“ – Brian Eno & Peter Schmidt, „Oblique Strategies“ Anschnallen bitte: In diesem Blogpost werden wir eine wohlvertraute Aussage zum Testen um 180 Grad herumdrehen. 🙂 Tester:innen [1], die die Zertifizierung zum „ISTQB Certified Tester Foundation Level“ absolvieren, lernen dort 3 Kategorien von Testentwurfsmethoden kennen („Black Box“, „White Box“, „erfahrungsbasiert“) sowie eine Trennung in systematische und intuitive Testfälle. Nachdem der Lehrplan verschiedene Black-Box- und White-Box-Techniken behandelt, die er völlig zurecht dem systematischen Testen zuordnet, werden die Techniken aus dem erfahrungsbasierten Test – wie z.B. exploratives Testen – in Abgrenzung dazu wie folgt positioniert: Erfahrungsbasierte Tests sind eine gute Ergänzung systematischer Tests – nicht mehr, aber auch nicht weniger. Dies illustrieren wir in Bild 1: Bild 1 Und für die, die’s genau wissen wollen, hier die entsprechenden Lehrplan-Aussagen im Wortlaut: „Diese [erfahrungsbasierten] Verfahren können Testfälle identifizieren, die durch andere systematische Verfahren nicht so leicht zu identifizieren wären. (…) Die [systematische] Überdeckung ist bei diesen Verfahren schwer zu beurteilen und möglicherweise nicht messbar. (…) Exploratives Testen ist dort am nützlichsten, wo es wenig oder ungenügende Spezifikationen (…) gibt. [Es ist] nützlich, um andere formalere Testverfahren zu ergänzen.“ [4] Die Haltung dahinter kann man lesen als: Systematik und Überdeckungsmessung sind für den Testerfolg „wichtiger“ als z.B. explorative Tests. Auftritt Realität, zumindest in vielen Projekten (= die gefühlte Mehrheit, aber das ist eine rein subjektive Einschätzung und würde es meiner Meinung nach verdienen, systematisch untersucht zu werden): Teams, die agil arbeiten, wenden leider nur selten systematische Testentwurfsmethoden an, weil ihnen meistens schlicht der Input dafür fehlt, die sog. „Testbasis“: In User Stories finden sich kaum formale Spezifikationen oder Referenzen darauf, also z.B. Entscheidungstabellen oder grafische Modelle, die Zustandsübergänge oder Prozesse beschreiben. Und da es also wenig Spezifikation gibt (getrieben von einem oft falsch verstandenen wenig Dokumentation), behelfen sich Tester:innen in solchen Situationen mit – genau! – explorativen Tests der entwickelten Software! Als Konsequenz nehmen diese eine zentrale Stellung im agilen Testvorgehen ein und dominieren in manchen Teams sogar den Testaufwand, siehe Bild 2… was im Ergebnis deutlich anders aussieht als Bild 1, nicht wahr? Bild 2 Als Coach, der die Testbarkeit von Stories sicherstellen möchte, versuche ich in solchen Situationen gerne, gemeinsam mit dem Team so viel Requirements Specification in jede User Story zu packen, wie es für das Team und sein Story-Verständnis hilfreich ist. Details dazu habe ich in [5] und [6] ausgeführt, deshalb möchte ich das jetzt & hier nicht wiederholen. (Nur so viel: Die Grundidee dabei ist, eine mit dem Team abgestimmte Menge von Anforderungs-Spezifikationen und Requirements-Engineering-Artefakten in eine Story zu packen und die Akzeptanzkriterien dazu als konkrete Beispiele zu formulieren.) Hier geht es mir vielmehr um die Ergebnisse dieser Maßnahmen, also ihre Auswirkungen auf das Testvorgehen: (1) Explorative Tests werden zu einer User Story IMMER durchgeführt, weil deren Ziele (= schnelles Feedback, Fehler aus User-Perspektive finden, etwas über das SUT lernen) unbestreitbar immer wertvoll sind. (2) Automatisierte Test zu den Akzeptanzkriterien empfehle ich ebenfalls IMMER, weil diese Tests per Definition gute Kandidaten dafür sind, bei jedem Release bzw. Build wiederholt zu werden; ergo lohnt sich deren Automatisierung. (Vorausgesetzt natürlich, die Akzeptanzkriterien sind werthaltig und hilfreich – aber genau dabei helfen ja Methoden wie „Specification By Example“.) (3) Jetzt kommt’s: Systematische Tests und die zugehörige Testbasis hingegen entstehen pro Story nicht immer, sondern JE NACH PRODUKTRISIKO! Risikobasiertes Testen und agile Denkweise gehen ja problemlos Hand in Hand [7], denn: Im agilen Requirements Engineering wird nur formal spezifiziert (also dokumentiert), was einen Wert oder Nutzen für jemanden hat, und dies ist natürlich insbesondere dann gegeben, wenn eine gewünschte Funktionalität mit einem hohen Produktrisiko einhergeht. Diesen Dreiklang – erstmals vorgestellt in einem Podcast [8] – nenne ich in Ermangelung eines pfiffigeren Namens die „Triple-X-Teststrategie“. Sie ist nach meiner Erfahrung ein guter Startpunkt für das Testen in einem agilen Team und sieht zusammengefasst so aus: Bild 3 Und jetzt schließt sich der Kreis in diesem kleinen Blogbeitrag, denn wenn man in Bild 3 genau hinschaut, passiert darin das genaue Gegenteil von Bild 1 und damit die angekündigte Umkehrung des eingangs beschriebenen Statements: Systematische Tests sind eine gute Ergänzung erfahrungsbasierter Tests – sofern sie ein entsprechendes Produktrisiko adressieren. Bild 4 Wer die ISTQB-Inhalte gut kennt, wird an dieser Stelle vermutlich erstmal zusammenzucken. (Das ging auch mir so, aber nicht sehr lange!) Zur Abrundung der Idee hier nur noch ein paar kurze Ergänzungen: In Projekten mit hohen Produktrisiken und/oder regulatorischen Vorgaben führt das Triple-X-Kriterium je nach Produktrisiko dazu, dass sich Bild 4 im Grunde wieder in Bild 1 verwandelt (d.h. viel formale Spezifikation, viele systematische Tests, deutlich weniger Exploration). Also: keine Sorge! Verwechselt Bild 4 aber bitte nicht mit dem altbekannten Hinweis, dass man im explorativen Test jederzeit punktuell mit Black-Box-Methoden o.ä. arbeiten kann (Stichwort hybride Formen)! Hier geht es um viel mehr, insbesondere um Planung im Team und benötigte Testbasis. Man kann die Triple-X-Strategie noch weiter ausdifferenzieren, wenn man z.B. Unittests und systematische White-Box-Entwurfsverfahren detaillierter betrachtet. Ich hab’s mir in diesem Blog geschenkt, um bewusst plakativ zu bleiben. 🙂 Nicht vergessen: Auch exploratives/erfahrungsbasiertes Testen kann mit der Zeit stumpf werden – etwa, wenn über einen zu langen Zeitraum immer dieselben Tester:innen dieselben Testaufgaben mit den immer gleichen Ansätzen durchführen. Dagegen gibt es Lösungen, die man auch nutzen sollte. Denn, wenn erfahrungsbasierte Tests den Löwenanteil einer Teststrategie einnehmen, lauert hier natürlich ein Projektrisiko. Gutes Testen sollte immer risikobasiert sein, aber natürlich auch regelmäßig Freiräume vorsehen, in denen Tester:innen scheinbar unkritische Teile einer Software erkunden können, um ggf. auf noch unentdeckte interessante Probleme zu stoßen. Die Triple-X-Strategie unterstützt beides. Das war’s. Und jetzt würde mich brennend interessieren, was Du, liebe:r Leser:in, von Bild 3 & Bild 4 hältst. P.S.: Herzlichen Dank an meinen isento-Testkollegen Christian Neyses für sein Feedback! P.P.S.: Wer einen besseren Namen als „Triple-X“ findet, mit dem man sich die drei Begriffe „Exploration“, „Acceptance“ und „Risks“ genauso gut merken kann – immer her damit, wir teilen uns dann den Ruhm. 🙂 Quellen: [1] https://isento.de/blog/no-walking-alone-wie-2-trainees-zu-isento-testerinnen-wurden/ [2] https://www.german-testing-board.info/wp-content/uploads/2023/05/ISTQB_CTFL_Syllabus-v4.0.pdf [3] https://daniel-delimata.medium.com/dear-istqb-please-update-your-syllabi-it-is-2023-already-ec9eb4fb5334 [4] https://www.german-testing-board.info/wp-content/uploads/2022/01/GTB-CTFL_Lehrplan_v3.1_DE.pdf – Hinweis: Die zitierte Aussage findet sich in V3.1 des Lehrplans und wurde in V4.0 offenbar ersatzlos gestrichen, d.h. insbesondere durch keine geänderte Aussage ersetzt. [5] Brandes, C: Verständnis durch story-spezifische Artefakte. objektSPEKTRUM 03/2019 [6] Podcast „QualityHeroes“, Folge 9:

Sind automatisierte Tests wirklich notwendig?

Wer sich schon einmal mit Testautomatisierung beschäftigt hat, weiß: Es ist toll, automatisierte Tests zu haben, die man jederzeit durchführen und beliebig oft wiederholen kann – aber dorthin zu kommen, kann ein langer und oft steiniger Weg sein. Und sogar noch schwieriger ist es für Projekte, ihre wachsende Zahl an automatisierten Tests lauffähig und aktuell zu halten: Viele Testautomatisierungen werden leider irgendwann über Bord geworfen, weil ihre Wartungs- und Pflegeaufwände nicht mehr gestemmt werden können. Vor diesem Hintergrund ist die Frage „Braucht man das alles wirklich?“ vollkommen berechtigt. Dr. Christian Brandes, unser „Head of Test & QA“, wurde mit genau dieser Frage konfrontiert, und da wir die kurze und lange Antwort darauf nicht für uns behalten wollten, haben wir hier für euch alles Wichtige zum Thema zusammengefasst. Jetzt kommt das ABER… Entscheidend für den Erfolg einer Automatisierung ist, sich vorher ausreichend Gedanken darüber zu machen, WELCHE Tests automatisiert werden sollen und WIE diese Automatisierung aussehen soll. Die erste Frage „Welche Tests?“ führt vor allem zur Regressionsstrategie: Welche Tests sind so wertvoll, dass sie immer wieder wiederholt werden sollen? Typische Antworten darauf sind: Tests zu Normalabläufen (Pareto-Regel, „happy path“), Tests der Akzeptanzkriterien, sowie nachträgliche Tests zu „durchgerutschten“ Fehlern (Korrekturprinzip). Denn: „Alles“ zu automatisieren ist nicht möglich und meist auch nicht sinnvoll, worauf schon Dorothy Graham hinwies („Automated chaos just gives faster chaos“). Nicht vergessen: Testen liefert „nur“ Informationen, und automatisierte Tests liefern diese Informationen eben schneller und häufiger. Die zweite Frage „Wie automatisieren?“ muss eine grundlegende Tatsache berücksichtigen: Testautomatisierung ist Softwareentwicklung, d.h. dafür sind Programmierkenntnisse notwendig. Und um nicht mit stetig zunehmender „technischer Schuld“ im Testcode konfrontiert zu werden, sollte man sich im Vorfeld eine Automatisierungs-Architektur überlegen, die zur Aufgabenstellung passt, die die Modularisierung und Wiederverwendung von Testcode fördert, sinnvolle Schichten definiert, damit nicht bei jeder UI-Anpassung zahllose Skripten angefasst werden müssen, und vielleicht auch Testschritte und Testdaten trennt. Hier kommen also bewährte Techniken wie KDT (keyword-driven testing) und DDT (data-driven testing) zum Zuge. Testcode sollte außerdem nicht als „zweitklassiger“ Code betrachtet werden, auch er muss lesbar und verständlich sein, versioniert werden und Coding Guidelines folgen. Und als Sahnehäubchen ist irgendwann das Thema „Kontrolle über die Testumgebung“ zu knacken, da mangelnde Kontrolle über Datenbestände u.ä. leider häufig mittels „intelligenterer Testautomatisierung“ kompensiert wird – was aber wiederum die Pflegeaufwände und Fehleranfälligkeit des Testcodes erhöht und in Summe oft teurer ausfällt als die Behebung des Problems „an der Wurzel“. Fazit Die einzigen Projekte, die sich mit Testautomatisierung NICHT zu beschäftigen brauchen, sind solche, die ein sehr simples Produkt bauen und/oder keine nennenswerten Produktrisiken beachten müssen. Für alle anderen gilt: die „richtigen“ Tests automatisieren, diese „richtig“ automatisieren, und das Ganze in einem durchdachten Mix mit manuellen Testaktivitäten auf die Straße zu bringen – „das ist der Weg“, wie ein Mandalorianer sagen würde. 😉 Eine ausführlichere Antwort auf die Frage „Sind automatisierte Tests notwendig?“ kannst du dir im Video von Dr. Christian Brandes ansehen. Dieses und weitere informative Videos findest du auf unserem Youtube-Kanal isento.insights. Sie sehen gerade einen Platzhalterinhalt von Standard. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf den Button unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden. Inhalt entsperren Erforderlichen Service akzeptieren und Inhalte entsperren Mehr Informationen Dr. Christian Brandes Christian ist Software Test and Quality Assurance bei isento