Ich brauche deine Anforderungen nicht, um Testen zu können!

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

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.