Erstmals erwähnt wurde der Begriff “Exploratory Testing” 1988 von Cem Kaner (Professor für Software Engineering am Florida Institute of Technology) – als Gegensatz zu “Scripted Testing”, das in den 80er-Jahren aufkam.
Weitere Test-Experten, die sich dieses Themas intensiv annahmen, waren u.a. James Bach, James A. Whittaker, Elisabeth Hendrickson, Lisa Crispin und Janet Gregory.
Im Jahr 2013 kam in der Reihe “The Pragmatic Bookshelf” ein in Fachkreisen sehr anerkanntes Buch heraus: “Explore It!” von Elisabeth Hendrickson, mit dem Untertitel “Reduce Risk and Increase Confidence with Exploratory Testing”.
Eine Buchbesprechung aus dem Dezember 2013 enthält im Anschluss auch ein Kurzinterview mit Elisabeth Hendrickson, in dem sie u.a. erklärt, warum automatisierte Regressions-Tests in der Regel nicht ausreichen, um potenzielle Fehler in gleicher Weise zu entdecken, wie es beim explorativen Testen möglich ist. (-> Zitat)
Im Buch selbst fordert sie eine Teststrategie, welche die zwei Kernfragen beantwortet:
- Verhält sich sie Software wie vorgesehen unter den Bedingungen, unter denen sie voraussichtlich zum Einsatz kommen wird?
- Gibt es zusätzliche Risiken ?
Die erste Frage lässt sich durch vorab definierte Testfälle beantworten; dazu kann man ein mehr oder weniger feines Netz weben, durch das immer weniger Fehler hindurchschlüpfen können.
Zur Beantwortung der zweiten Frage kommt das explorative Testen ins Spiel – da werden Experimente vorgenommen, die durch das oben erwähnte Netz nicht abgedeckt werden.
Durch Beobachtung und Analyse entstehen empirische Erkenntnisse über die Fähigkeiten und Grenzen der Software. Neu aufgedeckte Fragen suchen neue Antworten. Und so findet man einen Weg durch die nahezu unendlichen Möglichkeiten von Variationen zu den zusätzlichen Risiken – einen Weg, der bei den vorweg geplanten Testfällen verschlossen bleibt.
Um neue Überraschungen zu entdecken, hilft nicht Wiederholbarkeit, sondern Variation.
| Die Message ist: ein guter Test benötigt beides – einerseits das Prüfen, ob die Software das tut, was man von ihr erwartet, und anderseits das Erforschen, ob es zusätzliche Risiken gibt.
Diese Seite soll nicht das komplette Buch wiedergeben – ein Blick ins Inhaltsverzeichnis ist z.B. bei Amazon.com möglich. |
 |
Aber ein typisches Statement einer Arbeitskollegin von Elisabeth Hendrickson soll hier zum Abschluss im Original wiedergegeben werden: “It is so frustrating … no matter how many tests we write, no matter how many cases we execute, we always find the most serious bugs when we go off the script”.
Daher: zur Frustrationsvermeidung besser gleich das explorative Testen mit einplanen!
Weitere interessante Literatur zum explorativen Testen: Exploratory Software Testing von James A. Whittaker; darin wird beschrieben, wie man sich – ähnlich wie bei einer Stadtbesichtigung – bestimmte Touren vornehmen kann, die dann später auch leichter nachvollziehbar sind, z.B. die “Guidebook Tour”, wo man die Software gegen das Benutzerhandbuch testet (u.U. muss dann auch das Handbuch umgeschrieben werden), die “Money Tour”, wo man sich auf die Features konzentriert, wegen derer die Software hauptsächlich gekauft wird, die “Landmark Tour”, bei der man Schlüsselfunktionen der Software in unterschiedlicher Reihenfolge ansteuert, die “Intellectual Tour”, bei der man die Software an die Grenzen ihrer Leistungsfähigkeit bringt und viele andere Touren (siehe eigene Seite mit einer Übersicht der Touren).