Exploratives Testen ist wichtig und sollte ein Bestandteil der Teststrategie sein, denn dadurch lässt sich die Wirksamkeit der Tests bewerten, Code-Inkonsistenzen werden aufgedeckt und blinde Flecken, in denen Fehler am ehesten versteckt sind, werden beseitigt.

Sérgio Freire, Solution Architect bei Xray, gibt in diesem Blogpost die besten Tipps, wie man explorative Tests in einer agilen Umgebung durchführt.

Arbeiten im agilen Kontext

Zu Beginn der Entwicklung eines Produkts oder einer seiner Versionen gehen wir davon aus, dass wir alles über das Produkt wissen, was es zu wissen gibt. Obwohl die Erfahrung zeigt, dass es viele Annahmen und Unsicherheiten gibt.

Agiles Vorgehen ist eine Möglichkeit, mit der Komplexität und den Unsicherheiten rund um den gesamten Softwareentwicklungs- und -lieferprozess umzugehen. Bei der Arbeit in einem agilen Kontext wird die Software in mehreren Phasen, den so genannten Iterationen, geliefert.

Die Idee ist, den Arbeitsaufwand zu reduzieren und durch kleine Experimente zu lernen. Anstatt also lange an einer komplexen Funktion zu arbeiten, iterieren wir sie, indem wir Feedback einholen, lernen und unsere Erkenntnisse einfliessen lassen.

All dies bedeutet, dass viele Änderungen auf diese Iterationen zurückzuführen sind, die durch unsere Erkenntnisse und Rückmeldungen ausgelöst werden. Und Änderungen bedingen einerseits Fehler und anderseits veralten dadurch prädefinierte Testsets.

Exploratives Testen und Agilität

Das folgende Modell, das "Learning Lollipop model" (von Sergio Freire), zeigt auf, was beim explorativen Testen passiert.

Es ist eine Möglichkeit, exploratives Testen so zu gestalten, dass wir unser Produkt/unsere Produktideen "probieren" (wie einen Lollipop). Wir beginnen mit Fragen, die uns Ideen für die Gestaltung von Testexperimenten liefern, die wir durchführen und dann analysieren. Aus diesem Prozess lernen wir. Das wiederum wirft weitere Fragen auf, die neue Ideen für Testexperimente auslösen. Dabei bewegen wir uns im unbekannten Gewässern, die alle möglichen Verwendungszwecke für unser Produkt enthalten. Je mehr wir erforschen, desto mehr finden wir.

Anhand eines Beispiels wollen wir zunächst versuchen zu sehen, wie diese tatsächlich zusammenarbeiten. Nehmen wir an, wir arbeiten an einem System mit einer Reihe von Funktionen und möchten mit Hilfe eines agilen Ansatzes eine neue Funktion hinzufügen.

Aus der Testperspektive sollte das, was wir hatten (d. h. das Verhalten des System in der vorhergehende Iteration, durch eine Reihe von Kontrollen abgedeckt werden, wobei möglichst viele Testautomatisierungsskripte verwendet werden sollten. Auf diese Weise können wir fast direkt Feedback von der/den CI-Pipeline(s) einholen.

Wir können nicht einfach alles aus der Vergangenheit "von Hand" neu testen. Wir wissen auch, dass Skripte zur Testautomatisierung fehlerhaft sind, weil sie immer nur das testen können, wofür sie fest programmiert sind; sie bieten uns jedoch einen guten Ausgangspunkt.

Wenn wir eine neue Funktion entwickeln, wissen wir, dass wir vorher nicht viel darüber wissen; deshalb gehen wir schrittweise vor. Normalerweise haben wir es mit einer groben User Story zu tun und nicht mit einer umfangreichen, sehr detaillierten Anforderung.

Daher müssen wir unsere ersten Ideen für die User Story testen und Bereiche/Risiken darstellen, die wir im Auge behalten sollten. Es werden viele Fragen auftauchen, zu Beginn, während und nach der Implementierung. All diese Fragen können zu Ideen für Test-Charters werden, die wir mit Exploratory Testing-Sessions untersuchen können.

Berücksichtigt immer, dass in einem agilen Kontext Veränderungen häufig sind, und auch die Risiken können sich sehr schnell ändern.

Exploratives Testen passt perfekt zu einem agilen Ansatz, da es extrem flexibel ist und keine Vorbereitung im Vorfeld erfordert (wie es bei manuellen, geskripteten Testfällen der Fall ist). Außerdem werden Informationen aus früheren Sessions genutzt, um neue Testsessions anzustoßen. Deshalb passt sich die Methode an Veränderungen an, da sie nicht von einem bestimmten Zustand und erwarteten Ergebnissen für das System ausgeht.

Tipps für explorative Tests  

Mockups unbedingt explorativ testen

Bereits mit frühen Mockups sollten explorative Tests durchgeführt werden, und zwar einerseits intern als auch unbedingt mit zukünftigen Anwendern. Diese Tests können dazu beitragen, Ablaufprobleme zu optimieren und die bedeutendsten Herausforderungen herauszustellen.

Explorative Tests sollten auch während Design-Sprints durchgeführt werden.

Im Vorfeld sollten mögliche Aufgaben für explorative Testsessions mit dem Team besprochen werden

Bei regelmässigen Meetings (wie Standups oder Planung) sollten mit dem Team die Test-Charter besprochen werden, das heisst, die Fragen, die während des Tests beantwortet werden sollen. Dies bietet eine Gelegenheit, über Risiken zu sprechen und Einblicke von verschiedenen Teammitgliedern zu erhalten, die Ideen für weitere Erkundungen liefern können.

Es ist immer ein guter Zeitpunkt für explorative Tests

Unabhängig davon, ob nach dem Wasserfall- oder Agile-Prinzip gearbeitet wird: Jeder Zeitpunkt ist gut, um explorative Tests durchzuführen. Wir können niemals alles über unser Produkt oder System und seinen Kontext wissen, aber durch die Umsetzung von explorativen Tests können wir unser Verständnis weiterentwickeln. Zahlreiche Qualitätsattribute können beispielhaft untersucht werden. Reflektieren von Aspekten, die das Team, die Benutzer und das Unternehmen betreffen, um neue Sitzungen einzuleiten. Durch Investition von Zeit in die Erkundung - auch in frühen Entwicklungsphasen - wird eine Grundlage für Wissen geschaffen, um darauf aufbauendes Feedback zu integrieren und das Produkt oder System zu verbessern.

Explorative Tests können dazu dienen, Ideen für Testautomatisierungsskripte herauszuarbeiten.

Features sollten nicht nur mit mit Code geliefert werden, sondern einschliesslich Tests auf Unit- und Integrationsebene und gegebenenfalls sogar Systemtests. Ein Ergebnis explorativer Tests sollen Ideen für Testautomatisierungsskripte sein. Während des explorativen Testens können wir beispielsweise Abläufe, Auswirkungen und Sonderfälle finden, die aufgrund ihrer Relevanz durch "automatisierte Tests" abgedeckt werden sollten.

Dies gilt sowohl für Wasserfall- als auch für Agile-Projekte und ermöglicht es uns, die Testabdeckung durch Testautomatisierung zu verbessern und hoffentlich mehr Zeit zu gewinnen, um uns auf andere Aufgaben zu konzentrieren (z. B. weitere Analysen, Problembehebung usw.).

Durchführung von explorativen Tests bei Feature-Branches

Wenn das Team Feature-Branches verwendet, während die Features implementiert werden, kann und sollte man diese testen. Das bedeutet, dass man mit den Entwicklern zusammenarbeitet, um das Feature iterativ zu verbessern. Möglicherweise führt man eine explorative Testsitzung zu einem bestimmten Risiko, Qualitätsmerkmal oder einer Teilmenge des Features durch. Man kann auch eine Sitzung durchführen, wenn der Feature Branch zur Überprüfung bereit ist; falls man während der Implementierung getestet hat, dann wird die Session zu diesem Zeitpunkt eher eine High-Level-Charter sein.

Explorative Tests nach dem Zusammenführen von Branches können hilfreich sein

Merges können gelegentlich unerwartete Ergebnisse erzeugen, selbst wenn der Feature-Branch automatisierte Tests enthält (sollte). Die Planung eine explorativen Testsession kann dazu beitragen, diese aufzudecken.

Einbindung von Entwicklern und anderen Rollen in explorative Tests

Neben den Testern bietet die Einbeziehung anderer Personen in das explorative Testen eine zusätzliche Perspektive bieten. Gleichzeitig wird so eine qualitätsorientierte Kultur gefördert, die es den Teammitgliedern ermöglicht, die Qualität in Zukunft von Anfang an zu verbessern.

Die Zusammenarbeit mit einem Entwickler, dem PO oder einem Designer ist eine gute Praxis, um nicht nur das System aus verschiedenen Blickwinkeln zu betrachten, sondern auch die Erwartungen der verschiedenen Interessengruppen zu verstehen; ausserdem ist es eine hervorragende mittel- bis langfristige Investition in bessere Qualität.

Exploratives Testen nicht auf Nicht-Regressionstests beschränken

Auch wenn automatisierte Regressionstests bereits vorhandene Funktionen abdecken können, ist es eine gute Praxis, auch für Regressionstests explorative Tests durchzuführen, wenn man die Möglichkeit dazu hat. Die Testautomatisierung kann das Wesentliche abdecken, aber wir wissen, dass viele Dinge diesen Tests entgehen, da sie in Anzahl und Umfang immer begrenzt sein werden. Wenn man mit offenen Augen auf frühere Funktionen zurückblickt, kann man auf Probleme stossen, die in der Zwischenzeit hinzugekommen sind, und auf Probleme, die man nicht aufdecken konnte.

Explorative Tests deiner Testautomatisierung

Schau dir deine bestehende Testautomatisierung an und Suche nach Fehlern (es ist ja auch Code, oder?). Suche auch nach Problemen in Bezug auf Umfang, Ähnlichkeit und Relevanz. Schaue dir deine bestehenden Testautomatisierungsprotokolle an, denn vielleicht liefern sie wertvolle Informationen oder geben zu viele oder zu wenige Informationen preis.

Explorative Tests mit Tools zur Verbesserung der Tests und Steigerung der Effizienz

Tools werden eingesetzt, um bestimmte Aufgaben effizient und konsistent durchzuführen. Beim explorativen Testen werden Tools verwendet, um die Fähigkeiten des Testers zu erweitern, nicht um ihn zu ersetzen. Ein explorativer Tester kann problemlos Tools zur Erleichterung von API-Anfragen und zur Unterstützung bei Leistungstests einsetzen. Mit Tools kann ein explorativer Tester effizienter arbeiten und Qualitätsaspekte abdecken, die sonst nur schwer oder gar nicht zu bewältigen wären.

Explorative Tests auf der Suche nach Lücken und Möglichkeiten zur Verbesserung des Wertes

Beim Testen suchen wir nach Problemen, die sich auf die Qualität und damit auf den Wert aus der Sicht der verschiedenen Interessengruppen auswirken. Beim Testen geht es darum zu verstehen, wie das System in Verbindung mit den Erwartungen der verschiedenen Interessengruppen funktioniert. In diesem Sinne geht es beim Testen auch darum, Möglichkeiten zur Steigerung des Wertes zu finden. Während des explorativen Testens können wir mit unserem Wissen und Hintergrundwissen Wege aufzeigen, wie wir den Wert unserer Produkte verbessern können. Vielleicht geht es dabei darum, die Funktion etwas anders zu gestalten, eine neue Form oder Interaktion auszuprobieren.

Mit explorativen Tests mehr Agilität in Wasserfallprojekte bringen

In Unternehmen, die mit Wasserfallprojekten arbeiten, finden die Tests meist erst statt, nachdem die Funktionen bereits implementiert wurden. Wir wissen, dass in diesem Fall die Kosten für die Behebung von Problemen erheblich steigen.

Normalerweise gibt es anfängliche Anforderungen, die die Implementierung vorantreiben. Diese sehr detaillierten Spezifikationen sind nicht vor Problemen gefeit, im Gegenteil: Oft beruhen sie auf vielen Annahmen und es fehlt das tatsächliche Feedback der Benutzer.

Wir wissen, dass Anforderungen und Spezifikationen im Allgemeinen unvollständig, mehrdeutig und manchmal widersprüchlich sind. Zudem veralten sie schnell.

Als explorative Tester können wir nicht nur Anforderungen und andere Dokumente als Quelle für unsere Tests verwenden; wir kennen auch den Kontext unseres Produkts, wissen über ähnliche Produkte Bescheid und kennen bekannte Heuristiken, die uns helfen können, Probleme durch Testverfolgung und -berichte aufzudecken. Ausserdem können wir unser Hintergrundwissen nutzen, um Risiken und Auswirkungen aufzudecken, die bei herkömmlichen Tests nicht auffallen würden.

In Wasserfallprojekten können wir explorative Tests einsetzen, um Folgendes zu erreichen

• Probleme, Risiken und Lücken aufdecken, die wir vorher nicht erkennen konnten, weil sie nicht in den Anforderungen/Spezifikationen enthalten waren
• Durch Testen während der Implementierung des Features können Möglichkeiten gefunden werden, es zu verfeinern und zu korrigieren, bevor es zu spät ist.
• Um über das Offensichtliche hinauszugehen und Probleme aufzudecken, die wir sonst übersehen würden, ergänzen wir traditionelle Ansätze wie z. B. manuelle und geskriptete Testfälle durch explorative Tests.

Unleash your testing potential with Exploratory Testing

Exploratory testing promotes innovation instead of scripted testing that is centered around specified test cases and attempting to complete a fixed number of tests per day. Exploratory testing encourages us to act role play as the end-user and detects more realistic bugs.

Exploratory testing is highly helpful in agile environments and has several advantages, as seen above. QA teams can successfully use this testing strategy for their own success in the agile development process by knowing its benefits and using reliable test management software like the Xray Exploratory App.

Mit explorativen Tests das Testpotenzial freisetzen

Exploratives Testen fördert die Innovation, anstatt sich nur auf die Anzahl durchgeführter Tests zu konzentrieren, wie es bei geskripteten Tests, die sich auf festgelegte Testfälle konzentrieren und versuchen, der Fall ist. Exploratives Testen ermutigt uns, in die Rolle des Endbenutzers zu treten, und deckt realistischere Fehler auf.

Exploratives Testen ist in agilen Umgebungen sehr hilfreich und hat, wie oben gesehen, mehrere Vorteile. QA-Teams können diese Teststrategie erfolgreich für ihren eigenen Erfolg im agilen Entwicklungsprozess nutzen, wenn sie ihre Vorteile kennen und eine zuverlässige Testmanagement-Software wie die Xray Exploratory App verwenden.

Über den Autor

Sérgio Freire

Sérgio Freire ist der Leiter der Lösungsarchitektur und des Testing Advocacy bei Xray. Er arbeitet eng mit vielen verschiedenen Teams auf der ganzen Welt zusammen, um euch dabei zu helfen, grossartige, qualitativ hochwertige und testbare Produkte zu entwickeln.

‍