Ein Widerspruch?

Exploratives Testen mit Struktur

von Markus Gärtner

Trugschluss: Exploratives Testen ist unstrukturiert

Vor einiger Zeit las ich von einer Konferenzpräsentation mit dem Titel “Structured Testing vs. Exploratory Testing”. Titel und Inhalt dieser Präsentation implizieren, dass Exploratives Testen und Strukturiertes Testen gegensätzliche Ansätze sind. Exploratives Testen als unstrukturiert zu bezeichnen, entspricht allerdings nicht meinem Verständnis von und meiner Erfahrung mit Explorativem Testen.

Als Schwimmtrainer habe ich früh schon eine Lektion gelernt: Wenn ich die Kinder und Jugendlichen koordinative Übungen wie beispielsweise „Rückenbeine mit senkrecht aus dem Wasser gehaltenen, gestreckten Armen“ durchführen lasse, dann beschweren sich diese zunächst einmal. Die Übung sei unmöglich und auf keinen Fall zu schaffen.

Im Rahmen meiner Schwimmtrainerausbildung hatte ich allerdings alle Übungen, die ich meinen Schützlingen auftrug, selbst mehrere Bahnen lang geschwommen. Dadurch wusste ich, wie schwer die jeweiligen Übungen waren, und ob sie für das Alter und die Fähigkeiten der Schwimmer:innen angebracht sind. Außerdem wusste ich, dass diese Übungen in der Tat geschwommen werden können und konnte diese im Zweifelsfall auch vorschwimmen. Seitdem weiß ich, dass „das geht nicht“ oder „das ist unmöglich“ in den meisten Fällen „ich weiß nicht, wie das geht“ oder „ich weiß nicht, wie ich das möglich machen kann“ bedeutet.

Diese Lektion gilt auch für Struktur in Explorativem Testen. Wenn ich in einer meiner Schulungen den Satz höre, dass Exploratives Testen unstrukturiert ist, so weiß ich sofort, dass der Teilnehmerin oder dem Teilnehmer eigentlich nur die Struktur im Explorativen Testen fehlt. Aber diese Struktur kann ich im Rahmen der Schulung vermitteln. Zu glauben, dass etwas möglich ist, ist schließlich der erste Schritt, um das Unmögliche möglich zu machen.
Zunächst einmal, was bedeutet das Wort “Struktur” oder auch “strukturiert”? Mein Wörterbuch sagt über Struktur

Struktur, die

  1. räumlicher Aufbau, Konstruktion, Gerüst
  2. innerer Aufbau, Gefüge aus voneinander abhängigen und sich gegenseitig bedingenden Teilen, Anordnung von Einzelteilen eines Ganzen
  3. Oberflächenmuster eines textilen Stoffes oder von Papier

Beim Blick auf das Nomen wird der Aufbau oder auch die Anordnung von Einzelteilen eines Ganzen beschrieben. Doch was sind die Einzelteile im Software-Testen? Testen besteht aus Testdesign, Testdurchführung und einem Lernfaktor, der zukünftige Testfallermittlung in Form von Erfahrung beeinflusst. Traditioneller Softwaretest zerteilt diese drei Schritte sehr streng. Das bedeutet, dass Testdesign, Testausführung und Lernen von unterschiedlichen Personen durchgeführt werden können – zumindest was die ersten beiden Teile betrifft. Die größten Probleme entstehen dabei, wenn Testdesigner:in und Testausführer:in nicht voneinander lernen, weil sie beispielsweise an geographisch unterschiedlichen Orten arbeiten und sich auf Grund des Zeitzonenunterschieds nur selten abstimmen können.

Cem Kaner definierte 1996 Exploratives Testen als eine Form des Software Testens, die die persönliche Freiheit und Verantwortung der einzelnen Tester:innen hervorhebt. Indem Testdesign, Testdurchführung, Testinterpretation und Test bezogenes Lernen als sich gegenseitig unterstützende Aktivitäten behandelt und gleichzeitig während der Projektlaufzeit fortgeführt werden, kann die Qualität der Arbeit der testenden Personen optimiert werden. Die Betonung liegt hier darauf, dass einzelne Tester:innen zwar die persönliche Freiheit bei der Arbeitsplanung genießen, diese Freiheit aber auch mit der Verantwortung für ihre oder seine Arbeit einhergeht. Verantwortung in diesem Zusammenhang bedeutet, dass die Testerin oder der Tester auch dafür Sorge trägt, dass ihre oder seine Arbeitsergebnisse nachgestellt werden können, indem beispielsweise Notizen zu den eigenen Testaktivitäten vorliegen.

Beim Explorativen Testen sind also die drei Einzelteile des Testens per Definition miteinander verbunden. James Bach definiert Exploratives Testen als „simultanes Lernen, Testdesign und Testdurchführung“. [Bach2002] Das bedeutet, dass Exploratives Testen die drei Einzelteile des traditionellen Testens nicht vollständig voneinander trennt. Allerdings gibt es im Explorativen Testen wesentlich mehr Einzelteile als in einem „strukturierten“ Testansatz. Michael Bolton verweist derzeit auf 18 verschiedene Strukturen und Modelle [Bolton2011] – und ich gehe davon aus, dass noch mehr Bestandteile darauf lauern, entdeckt zu werden.
Eine Struktur im Explorativen Testen besteht darin, die Applikation unter verschiedenen Aspekten zu betrachten. Michael Kelly hat hierfür die FCC CUTS VIDS Touring Heuristik [Kelly1996] eingeführt. Die Buchstaben stehen für Features, Complexity, Claims,  Configuration, User, Testability, Scenario, Variability, Interoperability, Data und Structure. Diese stehen für einzelne Touren, die ich als Tester durch die Applikation nehmen kann. Sie geben meiner Testtätigkeit damit Struktur – Einzelteile, die sich zu einem Ganzen zusammenfügen.

Der Test Heuristiken Spickzettel von Elisabeth Hendrickson [Hendrickson] bietet darüber hinaus Ideen für unterschiedlichste Testaspekte. Seien es verschiedene Hinweise zu Datentypen, Web-basierten Tests oder allgemeinen Heuristiken. Wenn ich in einer Testsession einmal nicht weiter weiß, dann bietet mir der Spickzettel Anregungen für weitere Ideen.

Eine weitere Struktur für Exploratives Testen bietet die HICCUPPS Eselsbrücke von James Bach und Michael Bolton.[Bolton2005] HICCUPPS steht für History, Image, Comparable Products, User Expectations, Product, Purpose und Standards & Statutes. Dahinter verbergen sich verschiedene Orakel – ein Prinzip oder Mechanismus, anhand dessen wir feststellen können, ob die Software im Sinne eines bestimmten Anwenders funktioniert.  Orakel helfen dabei, Inkonsistenzen in einem Produkt festzustellen. Wenn sich beispielsweise von der Produktversion 2003 zur Produktversion 2007 von Microsoft Office die Benutzeroberfläche komplett ändert, dann ist sie inkonsistent zur gewohnten Arbeitsweise der Benutzer:innen, der History in der obigen Liste.

Dass die Änderung in Microsoft Office – hoffentlich – mit voller Absicht vorgenommen wurde, verdeutlicht einen weiteren Aspekt von Orakeln: sie sind Heuristiken und können auch mal daneben liegen. Das bedeutet, dass ich als Tester mit Hilfe von Heuristiken weiterhin mein Gehirn benutzen sollte. Denn ein automatisierter Test kann nicht selbständig entscheiden, ob eine Änderung gewollt oder ungewollt ist. Dafür brauche ich immer noch menschlichen Gehirnschmalz – wie leider viel zu viele Teams immer wieder mit Erschrecken feststellen.

Die Heuristiken, Orakel und Touring Modelle, die Bolton bereitstellt, sind verschiedene Strukturen, die wir beim Explorativen Testen einsetzen. Zusammen mit der Struktur von Testnotizen und Debriefings nach einzelnen Testsessions behaupte ich, besitzt Exploratives Testen wesentlich mehr Struktur als so genanntes „strukturiertes Testen“.

Aber was ist mit wiederkehrenden Tätigkeiten wie beispielsweise Regressionstests? Testautomatisierung kann Exploratives Testen genau so unterstützen, wie Exploratives Testen auch Testautomatisierung über neue Tests informieren kann. Die beiden Ansätze bilden gerade in der Agilen Softwareentwicklung eine Symbiose, da sie sich sehr stark gegenseitig unterstützen. Beispielweise kann ich mit Hilfe von Testautomatisierung damit beginnen, um die getesteten Werte herumzutesten. Wenn ich beispielsweise einen automatisierten Test für die Werte 5 und 10 habe, kann ich schnell einen Test mit den Werten 1, 11, 42 und MAXINT durchführen.

Michael Bolton und James Bach beschreiben Exploratives Testen als einen Testansatz, der sich mit anderen Techniken verbinden lässt. Dabei ist jede Form von Testen explorativ zu einem gewissen Grad, und gleichzeitig vorbestimmt oder gescripted. Sich wiederholende Testtätigkeiten überlässt man dabei besser der Automatisierung und setzt den Faktor Mensch gezielt dort ein, wo er einen wesentlichen Beitrag liefern kann: beim Lernen und beim kreativen Designen von Testfällen auf Basis von bereits ausgeführten Testfällen. Denn genau dafür ist das menschliche Gehirn geschaffen.

Literaturtipps und Organisation

Sie wollen weiterlesen?

Referenzen

 

Dr. Wolf-Gideon Bleek

Über den Autor

Wolf-Gideon Bleek

Wolf-Gideon Bleek promovierte zum Thema Software-Infrastruktur-Entwicklung. Er ist Ende der 90er-Jahre zuerst mit agilen Methoden in Kontakt gekommen. Sein Interesse gilt dem Zusammenspiel zwischen Technik, Prozess und Organisation. In Publikationen und auf Konferenzen gibt er seine Erfahrungen weiter.

Veröffentlichungen (u.a.):

Übersetzungen:

E-Mail:Twitter:LinkedIn:

Mehr von Wolf-Gideon Bleek

Unser it-agile Lagerraum

Möchten Sie mehr erfahren?

Tauschen Sie sich mit unseren Expert:innen aus und lassen sich zu Schulungen, Coaching oder Wissensthemen beraten.

 

+ 49 40 4135 848-0    info@it-agile.de    Online Termin buchen

Agile Coaching von it-agile

Kennen Sie eigentlich schon it-agile?

Die Expert:innen zu agiler Arbeit und agilen Methoden

Kund:innen wollen begeistert werden. Mit innovativen Produkten, durch Schnelligkeit, Transparenz und auch Verlässlichkeit. Unsere erfahrenen Agile Coaches sorgen gemeinsam mit Ihren Teams und Führungskräften dafür, auch in komplexer Umgebung Ihre Ziele nicht aus dem Auge zu verlieren und implementieren die richtigen agilen Methoden für nachhaltige Veränderung.

  • Wir integrieren Pragmatismus mit Idealismus
  • Wir befähigen Sie nachhaltig ohne Abhängigkeit von uns
  • Wir erzeugen Kundenfokus mit wirkungsvoller Agilität
agile review Magazin

agile review

Unser Kundenmagazin 

In unserem Magazin stellen wir Artikel rund um agiles Arbeiten für Sie zusammen. Das Spektrum reicht von methodischen Themen wie Scrum und Kanban über Agile Leadership bis hin zu technischen Aspekten wie agilem Testen und flexiblen Architekturen.

  • Als Abo oder Einzelausgabe erhältlich
  • Digital oder Print
  • Einzelne Artikel sofort digital verfügbar

Wissens- und Lesenswertes

Das könnte Sie zu Agiler Arbeit auch interessieren

Agile Teams

Ein Haufen abhängiger agiler Teams ergibt noch kein agiles Unternehmen. Die übergreifenden Themen führen zu extremen Overhead, schlechter Vorhersagbarkeit und langsamer Time-To-Market. Diese Probleme…

Agile Teams

Wir hören immer mal wieder, dass Entwickler:innen Scrum hassen - wegen der vielen Meetings. Was steckt dahinter?

Agile Entwicklung

DORA (DevOps Research and Assessment) ist ein wissenschaftliches Studienprogramm, das unser Kollege Andreas Havenstein zur Weiterentwicklung von Teams angewandt hat.

it-agile Newsletter

Sichern Sie sich regelmäßige Neuigkeiten, Inspiration und Tipps zu agiler Arbeit, Konferenzen, aktuelle und neue Termine für unsere Schulungen sowie vieles mehr.


* Benötigte Angaben