Wozu braucht man explorativen Test?

Stellen Sie sich folgendes Szenario vor: Sie entwickeln für einen Automobilhersteller die Software „CarConfigurator“ zur Konfiguration von Neuwagen. Sie haben bereits alle Regressionstests automatisiert, sowohl Modultests, Integrationstests, Akzeptanztests und sogar die End-2-End Systemintegrationstests. Alles läuft vorbildlich in einem Continuous Integration-Umfeld und wird mit jeder neuen Version automatisch durchgetestet. Eigentlich sollte jetzt sichergestellt sein, dass sich bei Ihnen keine neuen Fehler einschleichen können. Trotzdem zeigen sich im Produktivbetrieb „offensichtliche“ – um nicht zu sagen „dumme“ – Fehler. So wird ein veränderter Text nur zum Teil angezeigt, und ein Button hat derart unpassende Farben, dass die Beschriftung nur schwer erkennbar ist. Dies birgt die Gefahr in sich, dass der Nutzer die schlechte Qualität der Software auch mit einer schlechten Qualität der Neuwagen in Verbindung bringt. Dies können Sie mit explorativem Testen vermeiden: Durch den Test mit der erfahrungsbasierten Brille werden viele offensichtliche, aber auch versteckte und ungewöhnliche Fehler vor der Freigabe gefunden.

Was ist explorativer Test?

Die ISO 29119 nennt exploratives Testen einen Testansatz, bei dem die Tests dynamisch entworfen und ausgeführt werden, basierend auf Wissen, der Erkundung des Testobjekts und den Ergebnissen früherer Tests. Eine leicht verständliche Erklärung zum Explorativen Testen finden Sie in unserem Glossar Video zum Thema Exploratives Testen.

Einen Überblick über die Hauptelemente des erfahrungsbasierten Testens und ihren Kontext finden Sie in nebenstehender Grafik.

Aus den Erfahrungen der Vergangenheit und dem anerkannten Wissen, entwickelt man mit viel Kreativität Vermutungen, wo sich Fehler im vorliegenden Testobjekt verstecken könnten. Wir erkunden im Rahmen einer nachfolgenden Testsitzung, mit viel Neugier ob sich unsere Vermutungen bestätigen oder nicht. Während dem Erkunden gewinnen wir neues Wissen und erweitern die Erfahrungen – damit schließt sich der Kreis.

Beispiel: Stellen Sie sich vor, Sie haben die Aufgabe die neue Version des CarConfigurators zu testen. Eine wesentliche Funktion ist die Preisberechnung des konfigurierten Fahrzeuges. Mit dem neuen Release wird das Feature „Flottenrabatt für Großkunden“ eingeführt. Sie wissen wie sich die Preisberechnung in Verbindung mit diesem neuen Feature verhalten soll. In der Vergangenheit haben Sie die Erfahrung gemacht, dass sich in der Preisberechnung viele Fehler versteckt haben. Sie vermuten daher, dass sich im Bereich der Preisberechnung wieder neue Fehler eingeschlichen haben. Daher planen Sie mit mehreren Experten und Anwendern eine Testsitzung zum Thema Preisberechnung. Gemeinsam erkunden Sie das neue Feature Flottenrabatt für Großkunden.

Am Ende der Testsitzung lernen Sie im Rahmen einer Debriefing-Session, was die Teilnehmenden während des explorativen Testens an zusätzlichem Wissen aufgebaut haben. Sie erkennen, dass Ihre Vermutung erfreulicherweise falsch war, denn es wurden keine wesentlichen Fehler gefunden.

Wie lässt sich der reaktive Ansatz im Softwareentwicklungsprozess integrieren?

Beim systematischen Testen befolgt man den zuvor erstellten Testplan. Bei genauen Plänen kann es passieren, dass zu wenig Freiraum bleibt, um auf neue Erkenntnisse reagieren zu können. Wenn alle Leute nur reagieren, besteht die Gefahr, dass man keiner gemeinsamen Strategie mehr folgt.

Sitzungsbasiertes Testmanagement (SBTM) bietet die Möglichkeit, kurzfristig auf neue Erkenntnisse zu reagieren und gleichzeitig eine gemeinsame Strategie zu entwickeln. Meist wird es englisch Session-Based Testing genannt. SBTM setzt auf die Erfahrung der Mitglieder agiler Teams und geht davon aus, dass diese gut in der Lage sind Vermutungen anzustellen. In unserem Beispiel mit dem Fahrzeugkonfigurator könnte eine solche Vermutung daraus entstehen, dass es schon öfter Probleme mit nicht sichtbaren Texten in den Infoboxen eines Ausstattungspakets gab. Diese Vermutungen werden in klare Ziele für die Durchführung einer Sitzung, den Testchartas verdichtet. Durch Testchartas sind zeitlich eingeschränkte, intensive Testaktivitäten mit klaren Testzielen und daher mit einer eindeutigen Zielrichtung versehen. Testchartas sind Leitplanken für die Tester, welches Testelement sie untersuchen sollen und welche Besonderheiten zu beachten sind. Am einfachsten ist es, die Testcharta mit einem klaren Auftrag für die Sitzung zu vergleichen.

Die Testcharta formuliert in unserem Beispiel das Ziel, neue Textbox-Elemente für Ausstattungspakete im Fahrzeugkonfigurator mit überlangen Texten zu beschreiben. Diese Testcharta übernimmt eine Entwicklerin in der Testdurchführung, die weiß welche GUI Elemente im Framework neu entstanden sind, zusammen mit einem Tester innerhalb eines Zeitraums von 90 Minuten.

Auf diese Weise wird aus dem vermeintlich willkürlichen Ausprobieren am Testobjekt ein gezieltes Experiment (= explorativer Test) in einem vorgegebenen Zeitrahmen (= Testsitzung). Abschließend lässt sich der reaktive Ansatz des explorativen Testens fördern, in dem Testmanager, Entwicklungs-Teammitglieder oder andere interessierte Personen am Ende einer Sitzung gemeinsam in einem Debriefing die wesentlichen Erkenntnisse besprechen und weitere Ideen zur Vorgehensweise entwickeln. Und schon wird aus Erfahrung wieder wertvolles Wissen!

Wie generiert man gute Testchartas?

Mit den folgenden Fragestellungen gelangt man recht schnell an gute Zielstellungen und somit an eine Testcharta:

  • Welche Änderungen wurden im aktuellen Sprint am Produkt vorgenommen?
  • Welche Seiteneffekte auf Bestehende Funktionalitäten könnten die Änderungen haben?
  • Wie nutzen die Anwender das Produkt?
  • Wo tun Fehler besonders „weh“?
  • Wo sind in der Vergangenheit gehäuft Fehler aufgetreten?
  • Über welche Qualitäten wird in der Spezifikation nicht geredet, aber relevante Stakeholder würden sie vermissen?

Allgemein können übliche Kreativitätstechniken helfen, wertvolle Testchartas für exploratives Testen zu formulieren. Um Lücken in der Testabdeckung finden zu können, braucht man immer wieder auch Anregungen für Gebiete, auf denen man selbst Erfahrungslücken hat oder für die gerade die eigene Kreativität fehlt. Checklisten, Testtoure der Fehlerangriffe sind Beispiele für Kreativitätstechniken, die im SBTM gerne genutzt werden.

Was unterscheidet eine Tour von einer Testsitzung?

Genau genommen handelt es sich bei Touren um eine der möglichen Kreativitätstechniken, bei denen man mit Hilfe von Metaphern Testchartas finden kann, um Testsitzungen zu gestalten. Dabei wird beispielsweise die Analogie zur Erkundung einer Stadt gezogen. Mit den Testerinnen und Testern wird dabei durchgespielt, dass sie die Erkundung des Testobjektes wie den Besuch einer unbekannten Stadt angehen. Sie sollen sicher gehen, dass sie wesentliche Sehenswürdigkeiten kennenlernen. Die Testerinnen und Testern beginnen üblicherweise mit einem gemeinsamen Blick auf einen Stadtplan. Die „Reisegruppe“ beschließt, welche Teile der Stadt interessant sind.   Sind die Stadteile festgelegt, so schicken Sie die einzelnen Interessengruppen in unterschiedliche Bereiche.
Am Abend treffen sich die Ausflügler bei einem Getränk und tauschen sich über das Erlebte aus. Davon inspiriert, plant die Gruppe das weitere Vorgehen und überlegt , welche Teile der Stadt als nächstes erkundet, oder noch einmal intensiver betrachtet werden sollen.
Mit Hilfe dieser „Visualisierung“ des Testobjekts als Stadt und Beschreibung der Test-Touren wird es einfach, Erkundungsziele, also Testchartas abzuleiten und sinnvolle Sitzungen für exploratives Testen zu planen.

Wer ist an einer Testsitzung beteiligt?

Beim explorativen Test kann idealerweise das ganze Team oder auch Personen außerhalb des Teams mitwirken. Der Fokus liegt hier nicht explizit auf Teilnehmenden mit Test-Knowhow. Dadurch lassen sich im gleichen Zeitraum viele Testchartas verfolgen und alle Teammitglieder lernen die ganze Anwendung auch aus neuen Blickwinkeln kennen. Da Erfahrung gemeinsam besonders gut wächst, ist es sehr bewährt, immer wieder auch zu zweit oder in noch größeren Gruppen die Testchartas zu erforschen.

Gibt es Beispiele für Testchartas?

Der ISTQB Agile Tester Foundation Level Lehrplan listet typische Elemente, die in einer Testcharta zu finden sein könnten:

Eine Beispieltour für den CarConfigurator: Wir versetzen uns in eine Person, die sich mit einer Entscheidung schwer tut. Sie konfiguriert ständig ein Fahrzeug bis zu einem gewissen Punkt und geht dann zurück und startet neu. Und wählt teilweise andere Fahrzeuge. Wie verhält sich die Software in diesem Fall? Werden Ausstattungen von dem einen Fahrzeug ungefiltert auf das andere übertragen? Gibt es die richtigen Fehlermeldungen an der richtigen Stelle? Die Testcharta dient also dem Zweck, möglichst viele Wechsel zwischen den Fahrzeugvarianten zu provozieren. 

Was ist eigentlich bei „normalem“ Testen anders als bei SBTM?

Vergleicht man das klassische Testverfahren mit dem sitzungsbasierten Testen, so fällt folgender Unterschied auf: Im strukturierten Testvorgehen werden die Testfälle üblicherweise aus Anforderungsdokumenten, der sogenannten Testbasis abgeleitet. Dabei kann eine Testabdeckung überwacht werden – sind alle Anforderungen durch einen Test abgedeckt? Oftmals sind diese Testfälle bereits fertig spezifiziert, bevor das Testobjekt überhaupt für den Test zur Verfügung steht. Kommt es dann zur Ausführung der Testfälle, z.B. im Systemtest, besteht die Gefahr, dass die Tests unreflektiert abgearbeitet werden - die Testerinnen und Tester werden oft nicht explizit dazu angehalten oder haben schlichtweg wenig Zeit, links und rechts vom Testfall nach Fehlern zu suchen. Mit anderen Worten: Es wird oft als ausreichend angesehen, das Vorhandensein der geforderten Funktionalität zu überprüfen. Dieses Vorgehen ist typisch für Softwareprojekte, die nach dem Wasserfall- oder V-Modell durchgeführt werden.

Beim explorativen Testen stehen die Testfälle mit dem Beginn des Tests noch nicht zwingend zur Verfügung. Genauer betrachtet gibt es keine Testfälle im klassischen Sinn – die Tester und Testerinnen halten sich an die Idee bzw. den kreativen Ansatz ihrer Testcharta. Durch Ihre Entdeckungen werden unter Umständen die zu untersuchenden Bereiche verfeinert und für die nächste explorative Sitzung eingeplant. Es lässt sich also sagen, dass die „Testfälle“ in den Sessions „reifen“. Zusätzlich werden neue Stellen im Testobjekt entdeckt, die näher untersucht werden sollten. Diese Flexibilität bei der Fokussierung auf ein bestimmtes Ziel, sowie die damit einhergehende Kreativität beim Ausdenken von Testfällen ist ein erheblicher Unterschied zum klassischen Testvorgehen und kann dadurch einen wesentlichen Nutzen generieren.

SBTM eignet sich auch für Testobjekte, für die keine Testbasis (fehlende Ausgangsdokumente) zur Verfügung steht.
Der explorative Test kann insbesondere im agilen Umfeld Mehrwert generieren – wenn Tester und Testerinnen innerhalb eines Sprints eine schnelle Aussage zu der Qualität des Testobjektes treffen sollen. SBTM ist eine optimale Ergänzung zu den Akzeptanzkriterien.

Soll exploratives Testen immer Bugs finden?

Auf jeden Fall sollen Bugs gefunden werden! Wenn die entsprechenden Sitzungen über einen längeren Zeitraum vernachlässigt wurden, sind die Listen von offensichtlichen Fehlern, die durch explorative Tests aufgedeckt werden, manchmal erschreckend lang. Aufgrund der relativ breiten und kreativen Ausrichtung der Testchartas auf Themenfelder, in denen Risiken vermutet werden, führen explorative Testsitzungen häufig zu unklaren Ergebnissen. Ob der Befund dann einen Bug, einen (bislang nicht spezifizierten) Feature Wunsch oder nur die eigene Voreingenommenheit des explorativ Testenden aufzeigt, sollte in diesen Fällen nach der Testsitzung in einem gemeinsamen Debriefing geklärt werden. Es gibt die Möglichkeit Überblickssitzungen zu halten, die sich von vorneherein mehr auf die Generierung von Erfahrung, als auf die Findung von Bugs konzentrieren.

Was soll ich tun, wenn für SBTM schlicht die Zeit fehlt?

Exploratives Testen ist der entscheidende „Sanity Check“, der verhindern kann, dass andere – ebenfalls wichtige – Testansätze aus der Spur laufen. Es sollte daher nicht die Frage gestellt werden, ob Session-Based-Testing berücksichtigt wird.

Vielmehr muss gefragt werden, ob der Mix aus „klassischem“ und Session-Based-Testing gut gewählt ist. Wollen Sie SBTM einführen, so kann das vielleicht zunächst nicht „on top“ geschultert werden. Gibt es Bereiche, bei denen Sie weniger klassischen Testaufwand benötigen, wenn Sie SBTM einführen? Dann wäre dies ein Ansatz, sich Zeit für SBTM zu schaffen. Demo-Termine mit den Abnehmern könnten beispielsweise mit Hilfe von SBTM strukturiert werden – am Ende wollen die meisten sowieso das System selbst bedienen können, weshalb es nahe liegt die Teilnehmenden einfach direkt mit einer Testcharta auf eine Erkundungsmission zu schicken.

Wie führe ich SBTM ein, wenn ich damit keine Erfahrung habe?

Die Frage ist, was fehlt genau? Im Folgenden ein paar Anregungen:

  • Fehlen grundlegende Kenntnisse über die Bestandteile des SBTM, so kann ein erfahrener Coach in der Anfangszeit unterstützen.
  • Der Einsatz von Coachings und Schulungen, wie beispielsweise Agile Tester – Exploratives Testen sind hilfreich für eine gewinnbringende Nutzung
  • Wenn Sie sich fragen, wie Sie zu weiteren Checklisten kommen: Checklisten sind niedergeschriebene Erfahrung. Sie können sich zum Beispiel die Frage stellen, was in der Vergangenheit schon mal „schief“ gegangen ist.
  • Das Wissen über klassisches Testvorgehen ist auch bei SBTM hilfreich, so helfen ISTQB Trainings bei Problemen hinsichtlich Testdesign.
  • Beim Domänenwissen hilft es oft, Domänenexperten zeitweise mit einzubinden.
  • Haben Sie unerfahrene Testerinnen und Tester im Team? Lassen Sie das Experiment von zwei Testenden gemeinsam durchführen: Pairing überträgt Erfahrung und baut neue auf.

Wie hilft Ihnen imbus beim explorativen Test?

imbus unterstützt Sie durch Trainings, in denen wir Ihren Teammitgliedern die genannten Techniken verständlich und praxisnah beibringen.

Wir können Sie auch im täglichen Doing unterstützen, indem wir ihrem Team einen erfahrenen Quality Engineer zur Verfügung stellen, welcher diese explorativen Tests vorbereiten und deren Durchführung koordinieren kann.

Möchten Sie die Themen lieber selbst angehen, dabei aber von einem erfahrenen Coach angeleitet werden?
Sprechen Sie uns an!

Jetzt Termin vereinbaren!

Das könnte Sie auch interessieren