Exploratives Testen (Teil 1) – Der Test für Faule oder die Krone der Testschöpfung?

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.

Hand, die eine Glühbirne hält, aus der untereinander vernetzte Punkte aufsteigen
Abbildung: Exploratives Testen – ein intuitiver Testansatz

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.

Alle Beiträge des Autors anzeigen

Mauern einreißen – Wie die Digitalisierung den Fachbereichstest ändert

Digitalisierung und Industrie 4.0 stellen neue Anforderungen an Prozesse und Softwaresysteme in allen Unternehmens- und Geschäftsbereichen. Firmen, die ihre Software extern entwickeln oder einkaufen, haben eine zusätzliche Herausforderung. Die verschiedenen Systeme unterschiedlicher Hersteller müssen für die vernetzte Arbeit im Geschäftsprozess der Unternehmen noch stärker untereinander Daten austauschen. Trotz der Tests der internen und externen Entwicklungsteams, die in verschiedenen entwicklungsnahen Teststufen die Software, bevor Sie an den Kunden übergeben wird, validieren und der anschließenden Abnahme durch die Fachbereichstests, treten beim Zusammenspiel der einzelnen Komponenten Fehler auf. Als Lösung bietet sich hier ein Testcenter mit dem Fokus auf übergreifende Integrationstests an, das aber für seinen Erfolg besondere Anforderungen erfüllen muss.

Kritische Fehler, die erst im Rahmen des Live-Betriebes öffentlich werden, stellen nicht zuletzt eine negative Werbung für ein Produkt und die beteiligten Unternehmen dar. Um dies zu verhindern, ist das Thema „Test“ in der modernen Softwareentwicklung ein grundlegender und integraler Bestandteil. Nur durch eine ausreichende Anzahl an Tests und der zeitnahen Rückmeldung von Ergebnissen lässt sich die Qualität und Reife des Produktes ausreichend genau nachweisen und bestätigen. Im Verlauf großer Softwareentwicklungsprojekte werden oft mehrere hundert neue Funktionen erstellt bzw. existierende erweitert. Entwicklungsteams testen durch Komponenten-, Integrations- und Systemtests die Software, bevor sie an den Kunden übergeben wird. Der Fachbereich nimmt die übergebene Software durch den Abnahmetest ab (siehe Abbildung 1: Testpyramide).

Testpyramide
Abbildung 1: Testpyramide

Es gibt in Unternehmen mehrere Informationssysteme mit verschiedenen Aufgaben für Logistik, Buchhaltung, Vertrieb etc., die mit unterschiedlichsten Technologien erstellt wurden. Diese Informationssysteme tauschen bereits heute untereinander Daten aus. Durch die Vorgaben der Digitalisierung und Industrie 4.0 verstärken sich diese Effekte: Neue Anforderungen wie stärkere Vernetzung innerhalb der gesamten Wertschöpfungskette führen zu einer höheren Anzahl oder einer Erweiterung der existierenden Schnittstellen der Informationssysteme untereinander. Damit steigt die Komplexität des Gesamtsystems, aber auch die Komplexität im Softwarelebenszyklus: Abhängigkeiten müssen von dem Erfassen der Anforderungen bis hin zum Test berücksichtigt werden.

Herausforderungen für den Test mit Digitalisierung und Industrie 4.0
Abbildung 2: Herausforderungen für den Test mit Digitalisierung und Industrie 4.0

Besonders für Firmen, die ihre Software von unterschiedlichen Dienstleistern erstellen lassen, erhöht sich der Aufwand für die integrativen Tests enorm. In den meisten Konstellationen gibt es mehrere externe Softwarehersteller und/oder gegebenenfalls eine interne IT-Organisation, die die Softwaresysteme entwickeln. Die Dienstleister führen bereits mehr oder weniger intensive Komponenten-, Integrations- und Systemtests durch und prüfen für das von ihnen erstellte Informationssystem im Einzelnen, ob die Qualität vorhanden ist. Den Fachbereichen fällt nun die Aufgabe zu, die vernetzten Informationssysteme in ihrem Zusammenspiel zu testen (siehe Abbildung 2: Herausforderungen für den Test mit Digitalisierung und Industrie 4.0).

Die größten Probleme bzw. Fehler mit einem hohen Risiko entstehen aber im Zusammenspiel der Informationssysteme untereinander. Doch speziell die notwendigen übergreifenden integrativen Tests finden in den meisten Unternehmen nicht oder nur unzureichend statt, was zu einer unzureichenden Qualitätsaussage und zu Fehlern im Wirkbetrieb führt. Dafür gibt es verschiedene Ursachen. Ein übergreifender Test auf Entwicklungsebene wird durch die organisatorische und räumliche Trennung der beteiligten Dienstleister verhindert und die Ausführung der notwendigen Tests pro Release ist aus Zeit- und Ressourcengründen durch die Fachanwender oder Tester aus dem Fachbereich nicht möglich. Außerdem fehlt diesen mit den Tests beauftragten Mitarbeitern, die Erfahrung und das nötige Testwissen, um eine optimale Testplanung und Anforderungsabdeckung für Integrationstests umsetzen zu können. Zusätzlich werden durch die räumliche Distanz der verantwortlichen Tester in den verschiedenen Fachbereichen Absprachen und Wissensaufbau erschwert.

Für den Unternehmenserfolg wird es daher immer wichtiger, die notwendigen Tests an dedizierte Tester abzugeben und damit sowohl den in der Testdurchführung erreichten Abdeckungsgrad als auch die Häufigkeit der Testausführung (Regression) deutlich zu steigern. Als Lösung bietet sich hier ein Testcenter an, das den übergreifenden Integrationstest betreut, welcher zwischen den Tests der Dienstleister und dem Abnahmetest des Fachbereiches stattfindet (siehe Abbildung 3: Übergreifender Integrationstest durch ein Testcenter). Das Testcenter prüft dabei das korrekte Zusammenspiel der Informationssysteme und der Fachbereich konzentriert sich abschließend auf die Freigabe seiner gestellten Anforderungen.

Übergreifender Integrationstest durch ein TestCenter
Abbildung 3: Übergreifender Integrationstest durch ein TestCenter

Ein Testteam oder Testcenter aus dedizierten und ausgebildeten Testern bietet dabei verschiedene Vorteile:

  • die Qualität der Informationssysteme ist das Hauptziel des dedizierten Testteams
  • die Testergebnisse werden gesammelt und objektiv an die Beteiligten kommuniziert
  • es gibt einen Testmanager, dessen Fokus auf Qualitätsthemen liegt und der für das Management der Testgruppe zuständig ist
  • der Testmanager stimmt sich mit den Fach- und Entwicklungsabteilungen ab, ermittelt die zu testenden Anforderungen, koordiniert das Testteam, bindet die Tester aus den Fachbereichen ein, kommuniziert mit der Projektleitung und dokumentiert die Ergebnisse in Testberichten

Ein internes Testteam oder Testcenter hat aber auch Nachteile: Bei längeren Releasezyklen oder Verschiebungen in der Bereitstellung der zu testenden Software kommt es zu schwankender Auslastung. Das interne Testteam oder Testcenter erzeugt kontinuierliche Kosten, hat aber nicht immer ausreichend Aufgaben. Aber es kann auch zu Spitzen an Testaufgaben kommen, die nicht oder nur schwer von der bestehenden Mannschaft abgefangen werden können.

Unternehmen, die bereits bei der Erstellung ihrer Software auf Dienstleister zurückgreifen, können auch beim Einsatz eines Testcenters auf einen externen Dienstleister setzen, welcher den Integrationstest als (einen) Service anbietet. Das Testcenter stellt dabei nicht nur eine einfache Ausgliederung der Testaufgaben dar. Ein Testcenter basierend auf einer Testservicevereinbarung stellt eine Lösung dar, deren Aufgaben, Pflichten und Abrechnungsmodell individuell auf den Kunden abgestimmt wurden.

Das externe Testteam oder Testcenter besitzt eine maximale Unabhängigkeit von der Softwareentwicklung, ist hoch spezialisiert und lässt sich durch den Servicegedanken flexibel an den Testaufwand des Kunden anpassen. Damit lassen sich die angesprochenen Nachteile eines internen Testteams oder Testcenters auflösen und das Unternehmen kann sich auf seine Prozesse konzentrieren.

Damit ein Testcenter optimal auf die Wünsche des Kunden reagieren kann, müssen verschiedene Voraussetzungen erfüllt sein. Es darf keine zusätzlich abgesetzte Organisationseinheit darstellen, sondern muss offene Kommunikations- und Informationskanäle zu allen Beteiligten aufbauen. Dabei ist die Nähe zum Kunden besonders wichtig. Aus unserer Erfahrung bietet es sich an, das Testteam beim Kunden oder max. 5 bis 10 Minuten Fußweg entfernt zu platzieren. Damit wird der Wissenstransfer und die gezielte Abstimmung mit den Fachbereichen sichergestellt.

Die Abstimmung mit dem Kunden bzw. mit dem Fachbereich erfolgt über die Servicemanager und Testmanager. Der Servicemanager stimmt mit dem Kunden die Planung der Testservices ab. Dazu gehört die Definition der Inhalte der Testservices und Aufgaben des Testcenters. Da jeder Kunde andere Anforderungen und Prozesse besitzt, ist auch für jeden Kunden eine Abstimmung und Durchführung einer individuellen Transition zur Übernahme der Testaufgaben notwendig. War die Transition und damit die Übernahme der Testaufgaben erfolgreich, stimmt sich der Testmanager für jedes Testrelease mit dem Fachbereich bzw. der Testkoordination beim Kunden über den Testzeitraum, die operativen Testinhalte und die Testfälle ab. Die Kommunikation ist aber nicht nur auf diese beiden Rollen beschränkt. Die Testexperten im Testcenter und der Fachbereich benötigen für die optimale Neuerstellung, Anpassung und Review der Testfälle sowie die Abstimmung beim Aufdecken von Abweichungen direkten und intensiven Kontakt.

Das Ergebnis der Tests ist maßgeblich von dem Wissen der Tester abhängig und dieses muss mindestens drei Aspekte beinhalten: Zum einen das fachliche Know-how der zu testenden Applikationen und zum anderen ein umfangreiches Wissen zur Testmethodik. Dadurch ist gewährleistet, dass eine optimale Anforderungsabdeckung, sowohl fachlich als auch im Rahmen der Testfallermittlung erreicht wird. Zusätzlich müssen die Tester aber auch Wissen über die Arbeitsweise der Entwickler besitzen. Dadurch können sie Fehler besser identifizieren, analysieren und in einer optimalen Weise an die Softwareentwickler kommunizieren.

Abstimmungsaufgaben der Service- und Testmanager
Abbildung 4: Abstimmungsaufgaben der Service- und Testmanager

Auf der anderen Seite muss sich das Testcenter mit den externen Dienstleistern und der Entwicklung austauschen. Ziel der Abstimmung ist zum Beispiel der Abgleich der Inhalte der bereits gelaufenen Tests mit den nachgelagerten Integrationstests, um so die Lücken in den Tests oder ggf. Redundanzen aufzudecken. Darüber hinaus wird gemeinsam mit dem Kunden die Auslieferung neuer Softwarereleases auf die Testsysteme geplant und die Analyse und Nachverfolgung von Abweichungen besprochen.

Zusätzlich zur Planung und Durchführung der Testaktivitäten des übergreifenden Integrationstests kann das Testcenter die technische Unterstützung der Tests des Unternehmens übernehmen. Das wären zum Beispiel Aufbau und Wartung der Testinfrastruktur und Testumgebungen, sowie der Aufbau eines übergreifenden Testdatenmanagements. Wichtig ist dabei, dass auf den Integrationstestumgebungen alle zu testenden Softwaresysteme aufgesetzt werden, so dass der komplette Geschäftsprozess übergreifend geprüft werden kann.

Ein weiterführender Aspekt des Testcenters ist die fortlaufende Optimierung der Testprozesse. Neben der Verbesserung der bereits eingeführten Arbeitsschritte gehören dazu weitere Punkte. Das sind zum Beispiel die Einführung und Betreibung von Testautomatisierung, die Auflösung von existierenden Abhängigkeiten innerhalb und zwischen den Teststufen, sowie die frühzeitige Prüfung von Entwicklungsständen der Softwareentwicklungsdienstleister durch sogenannte Vorintegrationstests.

Dazu werden neben den Testumgebungen für die übergreifenden Integrationstests weitere Testumgebungen aufgebaut. Auf den Vorintegrationsumgebungen stellen die Dienstleister Vorreleasestände der Software bereit und geben so dem Vorintegrationsteam des Testcenters die Möglichkeit, in Zusammenspiel mit den anderen Applikationen frühzeitig Tests durchzuführen. Die Vorintegrationstests dienen damit der schnelleren Aufdeckung von möglichen Abweichungen zwischen den verschiedenen Informationssystemen der einzelnen Dienstleister.

Für Unternehmen, die ihre Software von unterschiedlichen Dienstleistern erstellen lassen und trotzdem komplexe und vernetzte Systemlandschaften besitzen, bietet ein externes Testcenter eine schnelle und gründliche Qualitätsaussage über alle Softwaresysteme. Ziel des externen Testcenters ist die Etablierung eines integrativen Testprozesses, welcher nicht nur die Zusammenschaltung der Testsysteme beinhaltet, sondern auch eine vernetzte Testorganisation und vernetzte Testprozesse. Damit begegnet das Testcenter den Anforderungen der Unternehmen nach stärkerem integrativen Testfokus und Flexibilität durch Skalierbarkeit, Kommunikation und geballter Testexpertise.