Explorativer Test – Mythos und Wahrheit: Was ist überhaupt dieses „explorative Testen“?

Was haben Christoph Columbus, Ferdinand Magellan, Lewis & Clark und Captain Kirk mit explorativen Testern gemeinsam? Auch wenn der heutige explorative Tester nicht in Galaxien vordringt, die zuvor noch nie ein Mensch gesehen hat (hoffentlich zumindest, auch wenn es dem Tester das eine oder andere Mal so vorkommen mag) und er sich nicht Lichtjahre von der Erde entfernt bewegt, so gibt es doch Parallelen. Sie alle sind Entdecker, Explorer! Sie dringen – nur mit ihrem Wissen und dem einen oder anderem Werkzeug ausgestattet – in Bereiche vor, die ihnen unbekannt sind und zuvor meist eher weniger als mehr kartographiert wurden.

Seit Cem Karner in den 1980ern den Begriff des Explorativen Tests (in Folge kurz ET) geprägt hat, sind rund 30 Jahre vergangen. Dennoch herrscht bei vielen Testmanagern immer noch eine verfälschte Sicht auf das Thema.

Für die einen ist ET die Fehlerfindemaschine schlechthin, für die anderen ein reiner unstrukturierter und unmanagebarer Alptraum.

Doch was ist ET wirklich? Welche Spielformen existieren? Wie können wir ET in bestehende Vorgehen integrieren? Wie sollen Verträge und Abdeckungen für ET gestaltet sein? Das und noch mehr werden wir in den folgenden Artikeln genauer beleuchten.

Cem Kaner definierte exploratives Testen 1983 in seinem Buch Testing Computer Software als „Simultanes Testfalldesign, Testdurchführung und lernen“. Damit brachte er drei neue Blickwinkel auf den bisher als linear anzusehenden Testprozess ein:

• Testdesign und Testdurchführung findet gleichzeitig statt. Es gibt keine klar unterscheidbaren Phasen der Testfallerstellung und der Testfalldurchführung.
• Es müssen keine Testfälle erstellt werden (es dürfen aber!).
• Die Betonung auf das Lernen. Karner geht davon aus, dass bei Teststart noch nicht alle Fakten und benötigten Informationen bekannt sind und daher beim Tester auch ein Lernprozess während der Testdurchführung notwendig ist.

ET ist also von der Testfallerstellung unabhängig. Da Testdesign und Testdurchführung zeitgleich stattfinden und keine Zeit in Testfallerstellung investiert werden muss, kann ET sehr kurzfristig eingesetzt werden.

Des Weiteren können Kosten für Testfallerstellung und –wartung wegfallen. Ein erheblicher, aber oft nicht beachteter Kostenfaktor.

Also setzt sich der Tester – kurzfristig für das Projekt angeheuert – mal eben vor den Bildschirm, klickt mal hier mal da, erfasst den einen oder anderen Fehler und die Sache ist erledigt?

Ganz so einfach ist ET doch nicht. Auch wenn es einige Testmanager überraschen mag: ET ist weder nicht messbar noch unstrukturiert noch nicht zu managen – all das ist machbar, vorausgesetzt, man hat den richtigen Zugang.

Denn ET ist keine Methode wie erfahrungsbasiertes Testen oder die Grenzwertmethode sondern vielmehr ein Verfahren, ein Ansatz, eine Geisteshaltung. Der Ansatz schreibt keine Methoden vor, aber erfahrene Tester benutzen auch im explorativen Test Methoden wie Grenzwertanalyse – oftmals intuitiv.

Was meist mit ET gemeint ist, veranschaulicht die „Tester Freedom Scale“ nach James und Jon Bach:

Abb.: „Tester Freedom Scale“ nach James und Jon Bach

Bei der Testdurchführung wird für sehr strukturierte Testfälle (blauer Balken) weniger Erfahrung vorausgesetzt (grüner Balken) als beim „Freestyle ET“.

Spricht man von ET wird aber meist der rechte Teil dieser „Freiheitsskala“ gemeint, also beginnend zwischen fragmentarischen Testfällen und Charters bis hin zum „Freestyle“ – wobei der genaue Übergang fließend ist und von Autor zu Autor unterschiedlich definiert wird.

In der Abbildung sehen wir aber auch, dass exploratives Testen bereits kurz nach dem „lehrbuchmäßigen“ Testen nach konkreten, eventuell grobgranularen Testfällen beginnt. Sobald bei Testfälle die Formalisierung abnimmt – sie nicht mehr Schritt für Schritt und Klick für Klick beschrieben sind wie im blauen Balken dargestellt, lassen sie Freiräume für den Tester, die dieser mit Entdeckungsreisen ausfüllen kann (grüner Balken).

In diesem Sinne hat vermutlich jeder Tester bereits explorativ getestet. Ganz im Sinne von James Bach, der schreibt: „Exploratory software testing is a powerful and fun approach to testing. In some situations, it can be orders of magnitude more productive than scripted testing. I haven’t found a tester yet who didn’t, at least unconsciously, perform exploratory testing at one time or another.“ (James Bach 2008)

The post Explorativer Test – Mythos und Wahrheit: Was ist überhaupt dieses „explorative Testen“? appeared first on ANECON Blog.