Wir sind Testerinnen und lieben Testmethoden, bei denen die menschlichen Stärken, die Kreativität und die Kollaboration im Vordergrund stehen. Dabei wollen wir aber keinesfalls ohne Regeln bzw. Rahmenbedingungen agieren oder für eine Dokumentationsabstinenz plädieren.
Uns sind bereits einige Vorurteile über das explorative Testen begegnet, daher haben wir uns die Frage gestellt, wie diese zustande kommen. In diesem Artikel gehen wir speziell auf diese Vorurteile ein mit dem Ziel, diese aus dem Weg zu räumen. Doch zuerst betrachten wir das explorative Testen näher.
Was ist exploratives Testen?
Exploratives Testen kann viel mehr als Testfälle stumpf abzuarbeiten: Es fördert das kreative Denken während einer Testsession, sprengt Grenzen auf und befriedigt die Neugier. Gleichzeitig verlangt es Disziplin in Bezug auf das Erreichen des gesetzten Ziels während einer Testdurchführung und im Hinblick auf die Dokumentation.
Das ISTQB (unabhängiges Expertengremium für standardisierte Ausbildung von Softwaretestern) bezeichnet das explorative Testen in seinem Glossar als einen „Testansatz, bei dem die Tests dynamisch entworfen und ausgeführt werden, basierend auf dem Wissen, der Erkundung des Testelements und den Ergebnissen früherer Tests“ (Archivversion 3.4 des ISTQB® GTB Glossary). Anders als beim „klassischen“ Testen mit vorbereiteten Testfällen handelt es sich somit um einen intuitiven Testansatz, bei dem jede vorherige Idee zur nächsten führt. Dabei gibt es verschiedene Hilfsmittel, um einen neuen Ansatzpunkt zu erhalten, Ideen zu entwickeln und mehr Struktur zu schaffen. Dazu zählen bspw. die Test-Charter, die Heuristiken, das Test-Orakel oder auch die Test-Touren.
Zusammenfassend lässt sich sagen, dass die Testerin oder der Tester die Tests durch Erfahrung, Intuition, Neugier und strukturiertes Vorgehen erstellt. Trotzdem ist diese Art des Testens nicht nur für erfahrene Testerinnen und Tester sondern auch für Projektneulinge gut geeignet, die das Testobjekt und/oder das Vorgehen erst kennenlernen. Um die Person dabei an die Hand zu nehmen, sollte ein Ziel definiert oder ein Überblick des Objekts geschaffen werden. Dies kann entweder im direkten Austausch per Pair Testing erfolgen oder in Gruppen über den Ansatz des Mob Testings.
Vorurteile gegenüber dem explorativen Testen
Aber welche Vorurteile gibt es nun, gegen die sich das explorative Testen behaupten muss?
Exploratives Testen ist oft als strukturlos, nicht nachvollziehbar, nicht quantifizierbar – schlicht und einfach als „Ich-klick-da-mal-so-rum-und-schau-was-passiert“ – verschrien. Die Aussage obsoleter Dokumentation erschwert es zusätzlich, das explorative Testen in Kundenprojekten in Rechnung zu stellen. Das ist ein nachvollziehbarer Grund, wenn davon ausgegangen wird, dass exploratives Testen dokumentationsfrei und somit die Testleistung nicht nachvollziehbar ist. Schnell kommen somit auch die Aussage sowie das Totschlagargument zustande, dass für diesen Test keine Zeit zur Verfügung steht.
Im Folgenden werden wir die eben dargelegten Behauptungen sowie weitere negative Aussagen genauer betrachten und dazu Stellung nehmen.
Vorurteil Nummer 1: “Exploratives Testen ist nicht nachvollziehbar.” / “Explorativ getestete Inhalte kann ich nicht erneut testen.” / “Wie soll ich da einen Bug-Retest machen?” Diese Aussagen haben uns neugierig gemacht. Auf die Frage, was unter explorativem Testen verstanden wird, erhielten wir oft die Antwort, dass es für das spontane Herumklicken im Testobjekt genutzt wird. Es soll das Kennenlernen des Testobjekts fördern oder weitere Varianten testen, die bei der vorherigen Testfallerstellung nicht beachtet wurden. Und somit wird es nebenbei ungeplant sowie unstrukturiert durchgeführt. Eine Dokumentation wurde nicht erwähnt. Somit erklärt sich, wie das Vorurteil zustande kommt, diese Testmethode sei nicht nachvollziehbar und Tests sowie Bugfixes könnten schwer nachgetestet werden. Es ist absolut richtig, dass explorative Tests die spontane Testdurchführung unterstützen. Jedoch muss darauf geachtet werden, die Testschritte, erwartete Ergebnisse oder auch Abweichungen stets zu dokumentieren und die Tests somit nachvollziehbar zu machen. Wie die Dokumentationstiefe dabei aussieht, muss durch die Rahmenbedingungen eines jeden Projekts einzeln definiert werden. Wir halten fest: Exploratives Testen bedeutet nicht, nicht zu dokumentieren.
Um dem ersten Vorurteil entgegenzuwirken und Struktur in das explorative Testen zu bringen, kann man das Session-basierte Testmanagement nutzen. Während einer Session wird das Testobjekt mit größtmöglicher Flexibilität und Freiheit geprüft. Dabei werden die Rahmenbedingungen mithilfe eines definierten Standpunktes und einer Charta (Ziel und Ablauf für eine Session) gesetzt. Dies beinhaltet neben einigen anderen Komponenten auch eine Dokumentation durch Session-Reports, in denen die durchgeführten Testschritte, Abweichungen, das Testobjekt und weitere Informationen festgehalten werden können. Diese können je nach testender Person oder Projekt angepasst werden. Im Internet lassen sich verschiedene Beispiele für Session-Reports finden.
An dieser Stelle sei ein spezieller Anwendungsfall erwähnt: Exploratives Testen im regulierten Umfeld. Hier nimmt die Dokumentation eine zentrale Rolle ein. Das Vorurteil hier: Exploratives Testen ist im regulierten Umfeld unmöglich oder nur sehr schwer umsetzbar, aufgrund der regulatorischen Vorgaben. Wie man es trotz Vorgaben umsetzen kann, werden wir in einem weiterführenden Artikel aufzeigen.
Vorurteil Nummer 2: “Für exploratives Testen haben wir keine Zeit” / “Erst einmal müssen wir unsere vorbereiteten Testfälle abarbeiten, bevor wir explorativ testen können.“
Um die explorative Testmethode aktiv im Projekt umzusetzen, muss man bereit sein, das bisherige Testvorgehen anzupassen und den Vorteil der Zeitersparnis zu erkennen. Denn sieht man den explorativen Test nur als Ergänzung, ohne eine Angleichung der bisher genutzten Teststruktur, wird dieses Vorgehen nur als Belastung oder als ein lästiger Zusatz gesehen, wodurch das Keine-Zeit-Vorurteil zustande kommt. Erfolgt allerdings, wie beim explorativen Testen vorgesehen, die Testfallerstellung gleichzeitig zur Testfalldurchführung, entfällt die nun überflüssige Erstellung von Testfällen, die zum Schluss nicht durchgeführt werden und somit Zeitverschwender darstellen. Die gewonnene Zeit ermöglicht es der Testerin oder dem Tester, neue Testideen zu entwickeln und somit das Testobjekt intensiver zu testen. So können z. B. Debriefings durchgeführt werden, um die gewonnenen Erkenntnisse mit den anderen Teammitgliedern zu teilen. Auch kann diese Zeitersparnis genutzt werden, um die Testautomatisierungsquote zu erhöhen.
Vorurteil Nummer 3: “Dokumentation schön und gut, aber exploratives Testen ist nicht ausreichend.”:
Diese Aussage ist richtig, wenn damit gemeint ist, dass exploratives Testen für sich stehend als vollumfänglicher Testansatz gelten soll. Neben den explorativen Tests sollten mindestens automatisierte Tests definiert und ausgeführt werden (z. B. Unit-, Integrations- und GUI Tests). Wenn das Projekt einen hohen Automatisierungsgrad besitzt, ist es sogar durchaus möglich, das manuelle Testen rein explorativ durchzuführen. Alternativ kann die explorative Methode als Ergänzung zum klassischen Testansatz genutzt werden, um das manuelle Testen leichter, flexibler und freier gestalten zu können. Wie viel exploratives Testen in einem Projekt angewendet wird, muss stets sorgfältig geprüft werden. Nicht immer ist es möglich, alle manuellen Tests explorativ zu gestalten. Das kann an unterschiedlichen Faktoren liegen z. B. an einem zu niedrigen Automatisierungsgrad oder auch an fehlenden Skills der Testerinnen und Tester. Sie sollten aus unserer Sicht Skills wie Kreativität, Gewissenhaftigkeit, Eigeninitiative, Eigenverantwortung, Verständnis von Qualität sowie soziale Aspekte wie Kommunikations- und Teamfähigkeit mitbringen.
Fazit
In diesem Beitrag haben wir die Vorteile des explorativen Testens aufgezeigt und Argumente zusammengetragen, welche die vorhandenen Vorurteile demgegenüber entkräften sollen. Aus unserer Sicht lohnt es sich, das bisherige Testvorgehen zu überdenken und sich auf das explorative Testen einzulassen, um dessen positive Effekte zu nutzen. Natürlich sollte jedes Projekt für sich betrachtet und die Möglichkeiten zum explorativen Testen ermittelt werden – ohne dieses jedoch von Vornherein komplett auszuschließen. Negative Aussagen oder Erfahrungen sollten ggf. hinterfragt werden. Bei der Wahl der Methode und ihrer Ausführung sind immer auch die Skills der Testerinnen und Tester zu betrachten. An dieser Stelle möchten wir noch einmal besonders darauf hinweisen, dass die Dokumentation auch beim explorativen Testen essenziell ist.
Dieser Beitrag wurde verfasst von:
Katharina Warak
Katharina Warak arbeitet als Senior Softwaretest Engineer bei der ZEISS Digital Innovation. Sie ist für die Automatisierung auf API- und GUI-Ebene zuständig. Außerdem hilft sie den Kunden in den Projekten mehr über die kollaborativen Testmethoden zu erfahren und diese Methoden zur Verbesserung ihrer Arbeitsweise einzusetzen. Dieses Wissen teilt sie auch gerne auf internationalen und nationalen Konferenzen.
