„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:
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?
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:
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.
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
[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: „Agiles RE – wie geht das?“
[7] Brandes, C., Heller, M.: „Qualitätsmamagement in agilen IT-Projekten – quo vadis?“, HMD Praxis der Wirtschaftsinformatik, 53(2), 169-184 (Heft 308); auch separat erhältlich in der Reihe „Essentials/HMD Best Paper Awards“, https://link.springer.com/book/10.1007/978-3-658-18085-0</a
[8] Podcast „QualityHeroes“, Folge 22: „Testbarkeit von Requirements – was ist das genau?“
Dr. Christian Brandes
Christian ist Software Test and Quality Assurance bei isento
