Es gibt wenige Sachen, die mich als Testmanager aus der Ruhe gebracht haben. Eine Sache jedoch mit 100-prozentiger Sicherheit:
„Aber ohne Anforderung kann ich doch gar nicht anfangen zu testen!“
Wenn ich diese Aussage höre, schwanke ich mit meiner Reaktion zwischen einem deutlichen Facepalm und einem „Okay-Wir-Sollten-Reden“. Manchmal auch beides gleichzeitig.
Woher rühren solche Aussagen nun?
Übermäßig häufig höre ich sie in klassischen Umfeldern, die sehr prozesslastig sind und davon ausgehen, dass Testen eine definierte Phase ist – dem stimme ich übrigens nicht zu, aber das ist eine Diskussion für sich. In agilen oder kontextgetriebenen Umfeldern höre ich es hingegen eher selten bis gar nicht. Unabhängig davon beruht es allerdings auf der Fehlannahme, dass zunächst eine komplette Testbasis benötigt wird, um mit Testaktivitäten irgendeiner Art überhaupt beginnen zu können. Weiterhin beobachte ich häufig, dass dies mit einer Reduktion der Testentwurfsverfahren einhergeht, die so oder so den Fokus des Testens unnötig einengt. Allgemeinhin werden drei Arten von Testentwurfsverfahren unterschieden:
- anforderungsbasiert
- strukturorientiert
- erfahrungsbasiert
Werden nun ausschließlich anforderungsbasierte Tests realisiert, so werden die anderen beiden an dieser Stelle ignoriert, was der Qualität nicht unbedingt zuträglich ist. Im Gegenteil: In Zeiten von kurzen Releasezyklen und crossfunktionalen Teams rückt die geschriebene Anforderung häufig gegenüber der direkten Kommunikation in den Hintergrund. Umso wichtiger erscheint es, sich nun den anderen Entwurfsverfahren zu widmen.
Kann mir erfahrungsbasiertes Testen da helfen?
Gerade erfahrungsbasiertes Testen ist etwas in dem Tester*innen ihre Stärken ausspielen können, verfügen sie doch häufig über profundes Wissen sowohl in der Testmethodik als auch in der Fachdomäne. Diese beiden Elemente sind die Grundzutaten für erfahrungsbasiertes Testen. Als Testorakel wird eine Anforderung dennoch zu einem bestimmten Zeitpunkt notwendig werden, spätestens wenn beim explorativen Testen die gefundenen Informationen beurteilt werden – am Besten jedoch nicht durch die Tester*innen, sondern durch die Rolle, die geschäftsrelevante Entscheidungen treffen darf, wie z.B. ein Product Owner.
Gerne übersehen wird an dieser Stelle auch, dass sich Vorgehensweisen wie BDD (Behaviour Driven Development) genau hier tummeln. Wir schaffen uns über Beispiele und Geschichten eine formalisierte und abgestimmte Basis, um die Lücke zu füllen, die schlechte oder nicht vorhandene Anforderungen hinterlassen und haben gleichzeitig eine schlanke und lebendige Dokumentation.
Ist das auch was für die klassische Welt?
Schön und gut, das kann ja in der agilen Welt klappen, aber doch nicht in der klassischen. Auch hier ein deutliches Veto! Auch – oder gerade? im klassischen Bereich mit einem hohen Formalisierungsgrad gilt es das Vertrauen in das Produkt zu stärken. Hier kann erfahrungsbasiertes Testen seine Stärken ausspielen, denn Vertrauen in ein Produkt ist mehr als eine etwaige Rot/Grün Statusampel. Weiterhin kann ich die Informationen, die ich hier gewinne auch als Basis für deutliche formalere Tests nutzen.
Es geht also gar nicht so sehr darum, das eine durch das andere zu ersetzen, sondern darum, sich aller Ansätze bewusst zu sein und die Balance zu finden, die für das jeweilige Projekt angemessen ist. Natürlich habe ich dann auch gerne gute Anforderungen, die mich beim Testen unterstützen.
Lieber Axel, mir fehlen die Worte!
„The purpose of the verification process is to provide objective evidence, that the system fulfills its System requirements.”
Testing ist eine von vielen Verifikationstechniken.
Wenn das lese mit erfahrungsbasiertem Testen, dann fällt mir nix mehr ein!
Und wenn das dann noch mit Agilität begründet wird, dann gleich zweimal nicht!
Wonach soll denn getestet werden? Nach „check if it is nice“?
LG Ingo
Moin,
ich antworte mal statt Axel, da ich den Post ja auch geschrieben habe ;)
Die gegebene Definition reduziert Testen lediglich auf die Verifikation, lässt die Validierung komplett außen vor.
Gängige Definition im Feld des Software-Testens (etwa ISTQB oder RST) sind hier deutlich weiter gefasst und schließen diese mit ein.
Vor diesem Hintergrund ist das Verifizieren von Anforderungen wie oben geschrieben nur ein Teilaspekt. Natürlich ist der Post etwas provokant,
dennoch halte ich es für wichtig, auch andere Ansätze zu kennen und nicht kategorisch auszuschließen, da sie je nach Kontext unterschiedliche Relevanz haben.
Und ja, ich bleibe dabei, gerade in agilen Kontexten spielt erfahrungsbasiertes Testen zunehmend eine größere Rolle, da es eben nicht, wie häufig kolportiert, einfach nur wildes Herumklicken und „checking if it’s nice“ ist. Einen ersten Überblick gibt die englische Wikipedia: https://en.wikipedia.org/wiki/Exploratory_testing
Beste Grüße,
Christian
Ein sehr überlegter Beitrag über eine von drei Testentwurfsverfahren. Es ist nichts neues für erfahrene Test-Professionelle, aber ein Weltuntergang für IST-SOLL-Leute. Die Welt ist viel bunter als schwarz-weiß Fotos, die Software ist viel komplexer als Feature+Feature+Feature.
Danke, Christian!